[LRUG] Dedicated servers in the UK?

[John Arundel]

On 2 Jul 2012, at 22:04, Jason Green wrote:
> What's the insecurity in configuration of their load balancer if you don't mind me asking. Was considering them for a recent project


It's not the load balancer itself, but the way that you have to configure your servers behind the load balancer to allow the Rackspace automation to work. To explain that, I have to explain how I usually configure SSH access on machines.

There are three simple and very effective measures you can take to increase the security of your servers, all in the SSHd config file:

* Disable root logins ('PermitRootLogin no')
* Disable password authentication ('PasswordAuthentication no')
* Allow only named users to log in ('AllowUsers alice bob')

The root account is an obvious target for crackers, and you should never need to log in remotely as root anyway. Log in using your own account and SSH key, and use sudo to gain root privileges for commands that need them. This has the added benefit of creating an audit trail of all root commands and who ran them. This only applies to SSH logins, so you'll still be able to log in as root on the console (assuming you have out-of-band console access to your machines, which a decent hosting provider will give you)

Disabling password authentication (so you need an SSH key to log in) makes you safe from dictionary attacks, which can consume a lot of your bandwidth and compute resources and constitute an effective denial-of-service attack even if no accounts are actually compromised. If you have made the elementary security mistake of connecting your server to the Internet, and you see hundreds or thousands of failed login attempts in your logs, try this option. Also, passwords can be written down or sent in email or stuck to monitors with Post-its. I never saw anyone write an SSH key on a Post-it.

Allowing only named users also helps prevent brute-force attacks - there are usually several administrative accounts which need to exist for UNIX reasons, but which don't actually need to log in. You probably run your app or web server as a limited-privilege account which doesn't need to log in. It also helps prevent the class of attack where crackers simply run through the baby name book from Aaron to Zachariah trying every possible account.

Now, when you spin up a new Rackspace cloud instance behind their load balancer, their automated config tool needs to log in to the box as root, so you have to enable root logins. It can't use an SSH key, so you have to enable password logins. It needs to be added to the list of allowed users, and the username is always the same for all customers, so it's a known account that can be dictionary attacked. Of course you can close down all these security holes after the machine is configured, but if your own build is automated (you might be using a well-known configuration management tool which I've written a short monograph on) you need to jump through extra hoops to do this, and it's yet more steps which can fail and jam the build process.

It's not like Rackspace's infrastructure couldn't be easily fixed to avoid these problems. It just hasn't happened.

Regards,
John
-- 
Bitfield Consulting: we make software that makes things work
http://bitfieldconsulting.com/