Monday, August 16, 2010

Secure your rackspace cloud server

OK, so I've went round and round trying to figure out how my rackspace server was compromised and have come to the conclusion it was an inside job, but nobody's fessing up. I can see what sort of package was used to compromise my box and I may come back to trying to poison that package, but there isn't enough time in my life to continue to school folks who are hell bent on screwing with other people's property.

Instead, I'll give folks a quick primer one how to have a little better security if you choose to use rackspace with ubuntu 10.04.

#1 make sure your rackspace console password is secure... some basic rules: 10 chars, no dictionary words, upper and lower case letter, 2 number, at least one special char.
#2 Once you get your root password emailed to you, log in via the secure console, and disable both network interfaces. I'm not sure what the 10.* interface is for, I'll figure that out later, but I'm assuming it's some sort of rackspace backchannel.
#3 Change the root password to something secure (NOT your console password).
#4 Disable root login via ssh
#5 reenable networking.

At a minimum, someone must now guess a user account, a user password, AND the root password. to get root access to your machine (assuming you don't do something really stupid like installing random linux rootkit because your "friend" said it was kewl warez).

This should get you to a reasonably safe place to start with.

Note, if you want to ssh directly to your box, create a new user account (with a secure password) and you can do direct ssh and still be fairly secure. Adding user to sudoers has the effect if giving root with 1 password (although it is theoretically still more secure if you have a difficult to guess userid).

Saturday, August 7, 2010

Cloud Computing Gotchas part II

I finally had time to site down and actually analyze what happened to my box. It was certainly compromised by a script kiddie, but I'm not 100% sure if it was an inside job or not. In any event, I stored off the broken image and re-imaged the machine back to my "last known good" configuration.

I subsequently added the account that I thought was used for the attack setting the password back to what it was when the machine was originally compromised, but limited login to the rssh shell. This has been running for almost a week with no problems now. I've had a couple of sniffs of folks trying to connect to my machine as root, but no solid hits.

Some initial observations:

First the default install of Ubuntu Server on rackspace's cloud accounts enables root login via ssh. This is very strange now that I think about it. Ubuntu, by default disallows this (for very good reasons), and I think rackspace should seriously consider a change to their default build.

Second, the root password is emailed to customers. Again, really bad idea, not only is email really insecure, but there is certainly a more convenient method. Only display the password on the ssl admin console and push the responsibility of maintaining a good password policy to the customer.

Third, Not only should the root account ssh login be disabled by default, but users should have an option to have the initial boot of the system start the network interfaces disabled. I really would like to build a secure image, but it's nearly impossible when the server is started with network interfaces enabled.

So at this point, Rackspace's cloud accounts are exposing their customers to multiple attack vectors with zero chance of allowing the customer to secure their machine BEFORE an attacker has already breached their system. These are actually pretty minor changes to policy and configuration that have serious implications for security.