Network Security on the Cloud Part II Defense in Depth

by Karl Tatgenhorst on August 24, 2010

Last week I tried to bring to light some of the special network security challenges pertaining to moving your operations onto the cloud.This week I’ll start to cover some core concepts and how to implement those suggestions. This will not be the typical tutorial however, as I am going to focus on the conceptual and leave the reader to use available tutorials for now (I will be posting some technical tutorials to go along with this soon).

The first area of focus for us in securing our cloud servers (or any server for that matter) is that of access. We need to control who can access what (and perhaps when) to start to think about security. This portion of access control is going to highlight network access and some application access, we will not be tackling user access (authentication) yet.

How is my blog accessed

When a user types in the browser, a chain of events is initiated.

  1. The computer sends to it’s resolver (DNS Server)
  2. The resolver sends back the IP Address of (
  3. The browser sends an http get request to for the files
  4. the server sends back the files
  5. The browser uses libraries on the computer to render the page

That’s more technical than you need, but it’s good to think it through at level a time or two. A similar chain is followed for FTP, SSH or any other access granted. The thing you need to think about is who needs to access these services?

Web Server

Your web server is probably the heart of what you do and if you are an internet marketer of some sort, you probably want that wide open. Due to the fact that I recommend using Firewalls that drop connections as a default, I suggest that you write a rule to allow this. I will demonstrate using Linux iptables

iptables -A INPUT -p tcp -i eth0 –dport 80 –sport 1024:65535 -m state –state NEW -j ACCEPT

This rule allows NEW connections to port 80 (web) on interface number 0 (usually the external) from a high order port (1024 – 65535) on a remote machine.

If you have an “internal” interface, you probably don’t need that advertising that you have a web server for those in your data center to find. If you choose to go with a default deny policy, you don’t need to do anything about that. However, if you use a default accept policy then you need a rule to drop these connections.

iptables -A INPUT -p tcp -i eth1 –dport 80 –sport 1024:65535 -m state NEW -j DROP

MySql and SSH

If you have a single server then chances are that your MySQL server doesn’t need to take connections from the outside. If however you have two servers (webserver and a database server) you might need to grant access to one address. The iptables rule for that would look like this:

iptables -A INPUT -p tcp -i eth0 –dport 3306 -s –sport 1024:65535 -m state –state NEW -j ACCEPT

This rule allows the machine at IP Address to access MySQL on this server.

This rule can be easily changed to use to allow your home IP Address to access the SSH server

iptables -A INPUT -p tcp -i eth0 –dport 22 -s –sport 1024:65535 -m state –state NEW -j ACCEPT

As you see, the thing here is to think of all the ways that your server actually NEEDS to communicate and explicitly allow them and deny all others. Better yet, deny and log all others. These two rules would accomplish that (they can be cleverly combined).

iptables -A INPUT -i eth0 -m state –state NEW,ESTABLISHED,RELATED -j LOG
iptables -A INPUT -i eth0 -m state –state NEW,ESTABLISHED,RELATED -j DROP

Some people like to use REJECT instead of DROP as that is more proper by the RFC. The problem is, that this gives an attacker more information. If I try to scan an SSH server and get an immediate answer of “not permitted” I know there is an SSH server there. However, if I scan it and I get no response and finally a time out I don’t know anything about the SSH server.


I debated not using any examples as I feel they muddy the points. If this confused you, try reading without looking at the iptables rules. I will be monitoring comments and would love for you to turn your confusion into OUR conversation. I have not tried teaching this before and may well need to redo this post. I am fine with you asking for that. Network security is a lot like SEO, in that it should be viewed as a process and not a task. I look forward to helping you incorporate this process into your online life.

Have fun!

About the author

Karl Tatgenhorst wrote 31 articles on this blog.

Previous post:

Next post: