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.
August 26, 2013 at 2:19 AM
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.
August 26, 2013 at 7:56 AM
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.
August 26, 2013 at 10:10 AM
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.
September 20, 2013 at 7:53 AM
Post a Comment

Popular posts from this blog

Please use ANSI-92 SQL Join Syntax

-
Image
Way back in 1992, a standard was published for SQL. In it, the syntax for specifying joins in SQL Database was finally standardized. This was a good thing because (for folks who've been doing this a while), trying to decode the vagaries of how various Databases handled outer joins could drive you bonkers yielding different results depending on the parse order of things in the from and where clauses. Unfortunately, some DBMS vendors took a while to adopt this standard (Oracle didn't support it until 2001), but at this point if you're using a major RDBMS and NOT using it, you're probably mired in a tradition or habit that bears changing. As an example of what I'm describing, here are some examples of what I mean. Old School (no standard syntax + implementation and evaluation of predicates varied by vendor [and query]): select * from customer, order where customer.customer = order.customerid ANSI way (agreed to standard, predicate evaluation has some rules ...
Read more

The difference between Scalability, Performance, Efficiency, and Concurrency explained

-
I thought I'd give some explanation of the difference between scalability, performance, Efficiency, and concurrency. To make things more accessible (and because I'm watching a cooking show on TV) I'm going to use a baking metaphor to help explain the differences. In our case, the system in question is baking cookies for consumers. Scalability, is how well something responds to adding more resources. If we can double our capacity by doubling the number of resources, we've got linear scalability. In our baking example, if we add more ingredients, we can scale to a larger number of cookies. To contrast with our other metrics, this doesn't actually increase the performance of creating a single cookie (they still take 10 minutes to bake), and the efficiency is the same (we just have more capacity). We also cannot bake more cookies in a fixed time period, but over a larger time period we can produce more cookies. Performance is how fast something can get done, u...
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa...
Read more