An introduction to network defense basics

This is the next step in my series on system security hardening and network security. Please check out the previous article on 3 quick ways to reduce your attack surface on Linux. 

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 are in the same IP scope, with no firewalls or routers between them: Your laptop can see your TV, your TV can see your phone with no barriers.

Flat networks have benefits. They’re simple, and all of your hosts can 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, database server, and enterprise resource planning (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 code or plugging in a configuration with no pesky firewalls in the way. The process is just simpler and everything can talk to everything else, which is what a network is for, right?

Well yes, but in today’s world of cybercrime, and espionage, a flat network means your network is vulnerable. Those networks usually have a firewall at the edge, which is like putting a wall 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, maybe they fought their way past your guards, or 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, intruders have a good chance of getting from that supply truck over to your food supply, treasury, or armory, all because you’re focused on the wall around the castle.

This castle analogy is very much like a perimeter firewall. Sure, having one 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 inside 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 action would be like arming all of your citizens inside your castle and posting more guards at the entrance of 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 solution 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 this approach even further, you can split up your network and put internal firewalls between those smaller networks. We call this tactic network segmentation. The idea is simple: You group systems together based on their security levels or based on their purposes.

Consider your web server, which runs a web application that many users access all day long. That’s a pretty low-trust system, therefore, you trust this server the least. Behind the web server, there’s probably a database server. Put that in its own isolated network, since no one should be reaching it directly: All requests to the database server are first handled by your web application.

Now, maybe all of your database servers sit right next to each other, or maybe they don’t. You might have highly sensitive data on one database server (for that ERP), and not-so-sensitive data on another. If this is the case, put the ERP database in another, even more secure network. What you end up with is walls between your systems. If your webserver gets popped, the bad guys might have a foothold there, but they can’t just waltz into your database server since there’s a firewall between this web server and your database server, and they may have no access at all to your ERP database. To go even further, you could also limit access to systems on the hosts themselves. Take our example with the web server, the database server, and the ERP database server. Say that your database server has its host-based firewall set up so that only the webserver 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 your ERP database, 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 (DiD). 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, so your goal is to make your services more difficult so an attacker gives up, and goes off to find an easier target.

Wrapping up

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.

[Need more on networking? Download the Linux networking cheat sheet.]