May 102011
 

A lot of recent talks about “securing the cloud” but let me give you my take on it.

I am in the cloud, businesses are in the cloud, but which cloud?  Is any one cloud environment more secure than the other?  Let me give you a few things I have learned about the cloud….cause this might seem rather alarming to some or most.

Treat all cloud environments as a hostile environment.  Treat it like a wide open door to your business infrastructure, matter of fact, treat it like something blew 2 of the 4 outer parameter walls off of your business along with half of the roof coming down.  Rethink what you consider secure, how you secure services and applications, and treat it like you just handed everything to a blackhat hacker.

Almost every cloud environment I have used or tested offers a “private ip address” but is it really private?  If you dig around, you will find that it is not.  Matter of fact, it seems that others with those private ip addresses believe they have their own vlan switch of private ip address ranges segregated from everyone else….but fact is, you share your data on your private ip address range with many other clients on the same private ip address range.  Why?  Because you are all sharing a cut of the cpu, memory, network cards, etc of the same physical server.  Even though you might secure your forward facing applications, you would be surprised how many applications within the private ip addresses are not secured.  Why?  Because people automatically think of it in terms of “our local network or private lan”.  Why?  Because its in the same ip range as a private network.

See EXAMPLE 1 below

And because people treat it like a private lan network, they do the craziest things like “unpatched apache or other insecure software”, how about mysql root without a password on the private lan for ease of administration, or what about using the private lan to send critical confidential customer (or patient) records across to another failover server on the private lan….unencrypted.  You see where this is going??

See EXAMPLE 2 below

And then lets talk about pre-made cloud environments…..

So, you host in the cloud with abcd.com and they provide a pre-configured operating system containing what?  Did you ever audit that cloud container like a physical server?  You should.  I have seen everything from basic minimal installations, to fully configured lamp/lemp stacks outdated on the day they were deployed, to full blown installations complete with X (albeit not able to startx) and nearly all services set to startup.  Granted these environments allow you to quickly deploy and do “rapid expansion” of your existing cloud infrastructure, but at the cost of what?  Security!

 

# nmap -sP 192.168.160.1-254
 
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2011-05-10 14:31 EDT
Host 192.168.160.3 appears to be up.
Host 192.168.160.4 appears to be up.
Host 192.168.160.6 appears to be up.
Host 192.168.160.7 appears to be up.
Host 192.168.160.8 appears to be up.
Host 192.168.160.11 appears to be up.
Host 192.168.160.13 appears to be up.
Host 192.168.160.16 appears to be up.
Host 192.168.160.18 appears to be up.
Host 192.168.160.20 appears to be up.
Host 192.168.160.22 appears to be up.
Host 192.168.160.30 appears to be up.
Host 192.168.160.31 appears to be up.
Host 192.168.160.32 appears to be up.
......snip
Nmap finished: 254 IP addresses (153 hosts up)
Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2011-05-10 14:51 EDT
Interesting ports on 192.168.
Not shown: 1678 filtered ports
PORT     STATE SERVICE
22/tcp   open  ssh
3306/tcp open  mysql
 
Interesting ports on 192.168.
Not shown: 1678 closed ports
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
 
Interesting ports on 192.168.
Not shown: 1679 filtered ports
PORT    STATE  SERVICE
631/tcp closed ipp
 
Interesting ports on 192.168.
Not shown: 1679 filtered ports
PORT   STATE SERVICE
22/tcp open  ssh
 
.....snip

Final Recommendations

Any back-end communications over the private ip address range needs to be done over a secure method such as tunnels, ssh, etc.

All cloud environments need to be treated like physical servers.  They need to have unnecessary services disabled, unnecessary packages removed, hardened, fine-tuned, and then a snapshot of your final baseline configuration made before any application or services are installed.  If you want quick deployments, then clone your snapshot image and install via some other method (self created pre-configured packages work well).

Treat the cloud just like a hostile environment where everyone on the network is a hacker with wide open access to the data.  Use encryption when any network communication is done over the private ip address space, use encryption on anything forward facing, use encryption on backups (yea, I already know, that makes incremental backups a pain in the butt…..so also use snapshot features of your cloud environment when you can….after validating they are encrypted in some way.).

Just because your cloud operating system is in a luks encrypted filesystem does not mean the data on it is safe.  All a person needs to do is compromise any open port or service on the container where they then have free rein over the unencrypted data on the disk.  The encrypted disk is really only protecting you from what?  Nothing!

  One Response to “§ê¢µrïñg †hê ÇlðµÐ”

  1. […] This is part 2 of Securing the Cloud. […]

This site uses Akismet to reduce spam. Learn how your comment data is processed.