Note: This was originally posted on Red Hat’s Enable Sysadmin blog.

This is the next step in my series on hardening and network security.  Please check out the previous article on Lowering your Attack Surface by Disabling Unnecessary Services.

Flat Networks

There was a time when all networks were flat.  A flat network is similar to your standard home network today.  All of your hosts are neighbors to each other. All in the same IP scope, no firewalls or routers in between them.  Your laptop can see your TV, your TV can see your phone, no barriers, flat.  

Flat networks have benefits.  They’re simple, and all of your hosts are able to reach each other without you having to think too hard about how to enable access.  If you’ve got an enterprise network instead of a home network, you might have your web server, your database server, and your ERP all running on this network.  When your web application has to integrate with the ERP, or get data from the database, it’s just a matter of writing up some code, or plugging in some configuration, no pesky firewalls in the way.  It’s just simpler, everything can talk to everything else, which is what a Network is for, right? 

Well yes, but in today’s world of cyber crime, and espionage, it means your network is vulnerable.  Those flat networks usually have a firewall at the edge. It’s like putting a wall up around your castle.  The only way in is through the gate, and the gate has guards that don’t let anyone in. So you’re safe inside your castle right?  Sure you are, until someone gets past your guards. Maybe they found the servant’s entrance to the castle, maybe they fought their way past your guards, maybe they snuck in with a wagon of supplies.  The point is, once they’re inside your castle walls, if you don’t have any other protection, they’ve got a good chance of getting from that supply truck, over to your food supply, or into your treasury, or armory.  Because you’re focused on the wall around the castle. 

This castle analogy is very much like a perimeter firewall.  Sure, it makes it hard for attackers to get into your network.  But once they’re in, you’ve got no other defenses to stop them from hopping from system to system, until they find whatever it is they’re looking for.  Maybe they compromise your web server through a bug in your web application that lets them execute a remote shell. That shell tunnels out to their system, and now they’ve got a terminal on a server in your network.  From there, they do some scanning. Because your network is wide open inside of the firewall, they can see everything in there. They notice the database server, and the ERP, and start attacking those systems FROM your web server.  

There are a few ways to solve this problem.  You could keep your flat network, and implement host based firewalls on all of your hosts.  This would be sort of like arming all of your citizens inside your castle, and posting some more guards at the entrance to the treasury, and the armory.  An attacker might still sneak in on your supply wagon, but when he climbs out and heads for the treasury, he’s got to deal with a guard at the door before he can walk in and steal your gold.  This isn’t perfect, and it can be hard to manage, but it’s certainly a decent option, and it’s better than having a wide open network.  

Network Segmentation

To take it even further, you can split up your network, and put internal firewalls between those smaller networks.  We call this network segmentation. The idea is simple, you group systems together based on their security level. Or maybe based on their purpose.  Say, your web server, where users have to hit all day long. That’s a pretty low security level, you have to have it open to the right people, and because of that you trust it least.  Behind the web server there’s probably a database server. Put that in its own isolated network, no one should be reaching it directly, all requests to it are first handled by your web application.  Maybe all of your database servers sit right next to each other, maybe they don’t. Maybe you have highly sensitive data on one database server (for that ERP), and not so sensitive data on another. Put the ERP database in another, even more secure network. What you end up with is walls between your systems.  If your web server gets popped, the bad guys might have a foothold there, but they still can’t just waltz into your database server, there’s a firewall between this web server and your database server, and maybe no access at all to your ERP database.  

To go even further, you could also limit access to systems on the hosts themselves.  In our example above, with the web server, the database server, and the ERP database server.  Say your database server has its host based firewall setup so that ONLY the web server can reach it on the database port, and the ERP database server has a similar rule so that ONLY the ERP application can reach it..  Then say they’re in the same network segment. Now, if someone pops your web server, and jumps from there to your database server, even though they’re in the same network as your ERP database, they STILL can’t access it, because the host based firewall on the ERP database doesn’t allow it. 

And all of this, my dear sysadmin, is what we call defense in depth!  Because like ogres (and parfait), well architected services have layers.  When an attacker gets past one layer, they have another line of defense to deal with, and another, and another.  It’s impossible to have an unhackable service, your goal is simply to make your services more difficult so an attacker gives up, and goes off to find an easier target. 

I hope you’ve learned a bit about defense in depth!  Next time we’ll be talking about validating all of this complexity and breaking out the port scanner!