Happy new year to all visitors, users and readers of alpha-labs.net!
All the best from me! 🙂
I like XenServer. It’s a rock solid (albeit basic) virtualisation platform that’s not only open-source but can handle any OS you throw at it. Management is a bliss and in my many years of using it both professionally and privately I yet have to encounter a (non-hardware related) crash or other issue with it.
Installation is a breeze. All you need is the ISO, burn it an install it on some hardware you have lying around (it works even inside VirtualBox for a Test-drive; and yes: It also works inside XenServer. Xenception.). The hardware specifications are based on what you are going to do with it. From basic testing to high end computing with several hundreds of cores– no problem there.
The other piece of software I totally like is pfsense, a software based firewall distribution. With some minor tweaking you can get a real neat setup working.
Those two are just screaming to get together and have party. Bring the party hats!
I recently bought a Lenovo S21e notebook. I wanted something light, thin and before all: cheap. The usage of a notebook is restricted on doing stuff on the balcony or garden; “stuff” being puppet code, general server management and light web applications. For that the tiny S21e for a mere 180€ at amazon (note: the price actually increased since I bought it) seemed good enough. Sharp display, full size keyboard and no fans or other moving parts. It has no SSD either; the mass storage is an embedded 64Gb flash card which speed is in between a native spinning hard disk and a SSD. The soldered 2gb ram seemed enough for it’s task and the quad core Celeron; well, it’s a Celeron.
It came with Windows 8 & Bing pre-installed. I always boot into the pre-installed system at least once to test the hardware for defuncts. Later on you can’t tell if it’s a hardware or software problem. A practice that sure helped me…
It’s hardening time again.
Following up on my post “DNSSEC, SSH and keys.” this is another post in the series of hardening your SSH server and your server in general. Are you using password login or public keys?
Indeed. Why not both? And I am not going to recommend you that should put a password on your ssh keys (which is nice) but rather recommend real two-factor authentication: Public Key and a Password. What does it do?
If you are using WordPress then you undoubtedly have noticed an ever increasing number of login attempts on wp-admin.php. There are botnets out there that do nothing else but try to login to (any) WordPress Backend site. The reason is simple and not what you think; they are not going to defacing your site but rather looking for mailservers in good standing. Once “hacked” into your wp-admin, they most commonly infect a theme and call that theme to send tens of thousands of Spam mails to the point where your server can no longer send email due to the fact that it’s blocked on most rbl’s out here. This is in fact so common, that removing malware from WordPress themes is a (near)fixed task at work.
But even if you have chosen a good, strong password combined with a non-standard username there is still the matter of exploiting bugs and glitches which might even bypass authorization altogether.
The solution is simple, place a htaccess-protection in front of it. A htaccess protection is plain stupid from a technical point of view – not much can break, not much can be bypassed. By adding another layer of authentication you effectively protect your wp-admin and all current and future bugs and exploits.
But this would mean having to log in twice. Yuck.
And don’t think about using the same username and password combination for both locks.
How I am doing it and how I recommend it: Run nginx (it does work with apache, too!) and always serve tls pages which is a best practice and good for your seo on google. I am assuming you already have a working nginx setup and your site is already being served out of nginx. So edit your nginx configuration add add these lines to enable tls:
If you are reading this blog, odds are you are an System Administrator or at very least someone with technical skill and Linux knowledge. Following this train of thought, giving our connected world, leads us to the fact that you have used ssh at some point. And chances are you seen this prompt:
The authenticity of host 'mx1.alpha-labs.net (126.96.36.199)' can't be established. RSA key fingerprint is 50:88:9e:56:e9:2a:2f:d7:7f:e7:a9:3d:0f:23:9e:52. Are you sure you want to continue connecting (yes/no)?
Be honest: Did you ever really read this passage? I wager you typed “yes” to get on with the job at hand. This however, is a major security concern. You see, encryption is only awesome if you talk to the right person. What use is the most sophisticated encryption if you encrypt with your enemy?
You need to be sure you talk to the right guy, or in this case the right server. The fingerprint printed above should be checked against a trusted source, be it written, given in person or phone call. No one does this, period. So everyone is just typing yes — or even worse: Disabling this check altogether (please don’t).
Do you know DNSSEC? With a fully trusted path coming from the root name servers “.” across the tld registries (.net) all the way down to the local system administrator on fqdn level (alpha-labs.net) or even lower (mx1.alpha-labs.net).
So most of you are running (some sort of) a web-server. Mostly this is the usual LAMP stack, consisting out of
and there is nothing wrong with that. Built on top of a Centos 6 machine yields a pretty fast and stable server. Yet, with the default setting and repositories of CentOS 6 this would yield with a mod_php run Apache Server featuring a whooping PHP 5.3. To remedy the version issue and switch to fastcgi yields in a modern set-up that’s lighting fast on top.
I will show you how to build a LAMP stack with stack apache, mod_fastcgi and a current PHP 5.6.
Let’s get down to business.
I am using Alfresco as a personal document archiving system for all my personal things. Everything that gets (snail-)mailed to me get scanned with my document scanner, which does OCR, page cutting, rotating and optimizing, and then uploaded to alfresco with pretty much one click. Well, one button (scanner), then I need to supply a file-name and finally the document is added via drag&drop to Alfresco. This system works great, even my wife uses it (frequently). The only thing that’s kept on paper are important documents like insurance policies and things like that.
As this is obviously a critical piece of our “digital lives”, it needs to be stable and somewhat up-to-date. I opt-out of going after every update and I seem to upgrade Alfresco only once a year, which works well for me. My Alfresco installation in shielded from the internet, that is, it’s on my private (non-internet connected) server, so bugs and exploits are of no concern here.
Now installing and running Alfresco is straightforward, consisting out of downloading, running and doing the setup and configuration wizard, period. But as some point, you do want to upgrade it. And this is where the fun starts.
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache License. It uses the only widely adopted open protocol for instant messaging, XMPP (also called Jabber). Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
Most distribution bring openfire packaged and somewhat up-to-date, but to be on the safe side you should install the .deb or .rpm files from the developers homepage. Installation is pretty straightforward as configuration is done via the web-interface. You only need an up and running mysql (or mariadb) server and off you go. I will not go into installing said packages in this article, I assume you are able to get things running for yourself. If not, the remainder of this article is not for you – yet.
Issues start however getting a good grade over at xmpp.net:
The Domain Name System Security Extensions (DNSSEC) is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.
– Wikipedia entry for DNSSEC.
Implementing DNSSEC itself is fairly easy, there are a lot of good howtos out there. The trick is to make it work with puppet and several dns servers at once. I don’t want any hassle with the DNSSEC part at any time. If I change a dns zone in my puppet manifest, the change has to be made public on the dns servers, which in turn have to handle the signing by themselves. But if you manage the zones with puppet the signed zonefiles will get wiped. So that was the tricky bit.
Plus I host several other domains whose admins want to enjoy DNSSEC without any hassle. With my current implementation of puppet and dns — it works! \o/
DANE enables the administrator of a domain name to certify the keys used in that domain’s TLS servers by storing them in the Domain Name System (DNS). DANE needs DNS records to be signed with DNSSEC.
– Wikipedia on DANE.
DANE was rather easy once DNSSEC was online. As the zones are trusted (by verifying the signatures) the TLSA records are trusted, too. It’s a shame that most browsers do not yet support DANE. Youcan add TLSA/DANE suport by installing and addon.
See for yourself: