Network Security on the Cloud for New Media Professionals (et… al)

by Karl Tatgenhorst on August 18, 2010

I’ve been thinking lately about a lot of things, social media, technology and above all my own outlook etc… Recently, my boss played into this when he talked to me about the security of his network. I had started doing social media at work and decided that was where my heart was. My boss however had hired me based on my skills in Unix and my passion for network security. This talk provoked a LOT of introspection, what was I doing? What do I want to be doing? Finally, what do people expect me to be doing?

The question isn’t too hard when I listen to comments people make to me and about me. A technical situation arises and a close friend will say… “You should call Tat!”. I stumble onto a technical problem and people take no notice of it…. “He can figure that out”. People think of me as a technologist, plain and simple. I think of myself as a problem solver and a connector. My problem is that I need to connect what people think of me with what I think of myself. So it hit me, I will use my tech savvy to solve real world tech problems that people in the “New Media” field can expect to encounter and use my blog as a platform to convey solutions.

This week I am starting a short series on securing a “cloud based” server or data center, as the cloud has been interesting me for a while. This is my first attempt at teaching security and it is my first social media teaching attempt, so while it may sting I do look forward to your comments. Enjoy!

Special Security Concerns on “The Cloud”

When you decide to move some or all of your operations onto the cloud, an important thing to realize is that every server exists wholly on the internet. There is no “DMZ”, no “internal network” there is only “the internet”. I know, you’re thinking “Karl, my cloud server has an external and an INTERNAL interface. So, you’re wrong.”. I assure you, I am not wrong and will guide you to my way of thinking with haste. Your “internal” interface does not traverse a switch in YOUR data center… that alone makes it an external interface with an RFC 1918 private IP address. Further, the “switch” might be a switch or a router or a virtual switch. The switch will be sharing this “internal network” among hosts owned by other companies. Your data is vulnerable to sniffing attacks on the infrastructure and you have no LEGAL way to find out if the infrastructure is secured from such attacks. This means infrastructure security MUST be performed at the host level.

An example of the type of problem this network poses is if you have a machine to host your blog and put your database on another machine. These two machines communicating in the clear will pass any potentially private data unencrypted on a switch with strangers on it (from a security standpoint, I assume I am trustworthy and no one else is). So, we need to look at a way of identifying outbound communications and encrypting them. This means we must plan our server well before we decide to build it. This does not mean, that we should scrap the idea. This is completely within our grasp, if it is too complex ask someone for help but rest assured the goal is achievable.

Another example of a problem unique to the cloud is the fact that all exposed ports are exposed to the whole internet and the firewall must be host based. If you use SSH, you should use a firewall or wrappers to restrict access to trusted IPs only (also do this for any service) your firewall should deny by default and log denied packets.

A final point to consider about this type of network is that you have no ability to monitor at the switches etc… Your’ ingress/egress points are as close as your’ network interface. You need to consider a host based system of protection and monitoring.

Adapting a secure posture

The points above get you thinking about protecting access to your data or its’ confidentiality but there is more to security than that. The ISC2 certifies individuals as CISSP (Certified Information Systems Security Professional) and they list three main areas of concern in the adaptation of a secure posture and those are: Confidentiality, Integrity and Availability. Confidentiality involves the access to the data, don’t let it be seen by those who don’t need to. Each piece of data has its’ own scope of audience often we only think of PII (person identification information) as private, but what about configuration information, passwords these are all data points and deserve their own consideration. Integrity, configuration files etc… should be monitored for changes this prevents a hacker from making unnoticed changes to your system or an unskilled admin from making a change without others knowing.  Availability? Yep, security minded pros should be monitoring availability. If your site drops for an hour and comes back is that a coincidence or did someone just hack you? You won’t know if you don’t know.

Where can you go?

This post was meant to get you thinking about the dangers of having your data on the cloud. As I said, you can do this safely and I’m going to help  but I want you to think about these things for a while. In the mean time, if you are looking to encrypt data between your’ servers before I post about it, try stunnel or SSL or even port forwarding via SSH. Looking to build a great firewall, use IPTables or at least TCP Wrappers. Curious about host based intrusion detection, check out Samhain. If you are patient enough, check back here next week to learn about iptables and encryption.


About the author

Karl Tatgenhorst wrote 31 articles on this blog.

  • Anonymous

    Very interested to hear what people think about this post, please leave your feedback here! Thanks

  • Richard

    This is an extremely important thing to point out to those who don’t know better. I know my first big move from 1 to 2 slices on Slicehost so I could have my mySQL separate from my apache server freaked me out when I started thinking about what was actually happening with the internal interface. This was even freakier when I started playing with memcache which is just open, no authentication. Some ssh tunnels later and things were better but still feels like a really dirty hack but lots of things seem to be going that way.

    The one thing I have thought about doing was some OpenVPN stuff to help make basically a real private network between all my slices but haven’t made that jump quite yet as I’m still only at 3 total slices and 3 other remote locations (2 homes and Amazon S3) so right now it’s not really a big deal. Once it grows more I may do it just to save myself some of the extra work thinking about each channel that they are communicating on.

  • Pingback: Tweets that mention Network Security on the Cloud for New Media Professionals (et… al) — Karl Tatgenhorst --

  • Anonymous

    Hey, thanks for reading this! SSH tunnels are a great way to handle the traffic. Their big drawback is the amount of work the proc does for them. MySQL supports SSL encryption, also stunnel is a little lighter weight.

  • Richard

    Sorry the tunnel was for memcache, not mysql. Not using the memcahce server that much so the extra overhead really isn’t an issue at moment.

Previous post:

Next post: