An unflattering commentary on Rackspace cloud server security

I recently needed a new server instance for some testing. Normally I would go back to AWS as I've had problems with Rackspace in the past. Being open minded and assuming things have changed in the last couple years I thought I'd go back and try out Rackspace cloud for my testing (for reasons I will not name here).

My first and most shocking revelation is that they have NOT fixed a key security problem. I'm going to outline this right now and hopefully somebody can fix it

Problem #1: Login as root via ssh

Guys...guys...guys(or gals)... It is baffling to me that you still allow this. Yes I get that you have a wonderful "Blacklist the my server ip when something goes wrong" and "then disable access to my console to fix" routine going on to protect your network if MY machine gets compromised due to your silly lackadaisical security. Wait, that's actually a negative thing too :) please stop, I'm not going to use you as a provider until you fix this. In the interest of fairness I'll say, you DO generate a nice, secure, random looking password... but that isn't really good enough in my book. At a minimum, generate a random password for a random (or hell even let me name a user) userid, disable remote root access, and I MIGHT consider using your service, except for the next problem.

Problem #2: No firewall protecting the machine by default

So let's ignore the root access problem... well, ok we won't... Now we have an aggravating problem... BEFORE I even have an opportunity to do ANY hardening of the server, it's spun up and connected to the internet listening on ssh. While I get that in your book this isn't probably the end of the world, I'm quite "not thrilled" by this. I suppose this problem is mitigated by the fact that I need to install all my services manually, but I'm still not happy. Why wouldn't I get access to firewall rules (Like I do in AWS) to limit the attack profile on my server (like to only allow ssh from my network)?

Rackspace, come on guys, I just can't believe you're still doing this, it's been a couple years now, you should learned by now! I can't imagine this is an expensive proposition, hell, problem #1 was already fixed by the ubuntu team by default, you actually had to do work to defeat their efforts.

If your philosophical stance is that "This is an acceptable risk for my customers" well then, good luck to you, glad you made that decision for me, I'll be moving on to other providers that care about my business.

Comments

Anonymous said…
I host on both for redundancy... When I spin up a server, I would rather have a vanilla Rackspace install, otherwise I'm going to rip all the preconfigured crap out anyway... In addition, it makes for a more efficient/speedy Chef deployment. "I'll be moving on to other providers that care about my business." Really? So childish.
Mike Mainguy said…
I guess it was a childish comment, but I'm the customer so THERE!

Oh wait, that wasn't much better was it?

From my perspective, this issue was pointed out almost two years ago to them and it hasn't been resolved. Perhaps the nature of what you host doesn't have very strict security requirements or you've got preconfigured images that are already locked down, or maybe you just don't perceive what I've pointed out as a serious problem...

Ironically enough, there is a post by someone at Rackspace recommending the use of key pairs, but they don't follow their own advice.
Anonymous said…
It's called "Infrastructure" as a Service for a reason.

Bring your own Image... or pay for managed service.

The PermitRootLogin thing is not half as insecure as you make it out to be. It is still infeasible to gain access.

I think you really have no idea what you are talking about and just rebroadcast opinions.
Mike Mainguy said…
Anonymous,
I guess rackspace disagrees with you http://www.rackspace.com/knowledge_center/article/rackspace-cloud-essentials-3-basic-cloud-server-security I'm just contending that the steps recommended in their knowledge center be performed on the images ahead of time... in particular because clueless newbies won't know to do these things and compromised servers hurt us all.

BTW, this is my blog, of course it's my opinion LOL.

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

MACH TEN Addendum: for companies wanting to use MACH platforms