By Daniel R. Miessler
Eventually, if you get interested enough in information security or start hosting services on your network, you are going to wonder what a DMZ is and why you should or should not have one. DMZ is an acronym that stands for demilitarized zone, and in the ‘real’ world it is the location between two hostile entities such as North and South Korea. In the world of information security community, however, it’s a separate, untrusted network where any machines serving public services (web, email, gaming, etc) should be placed. It’s a buffer zone between a completely unsafe network (like the Internet) and a relatively trusted network (like your private LAN). The primary purpose for this separation is so that a compromise in your DMZ does not automatically result in a compromise of your private network as well.
I’ll be discussing two main ways to implement a DMZ. The first is using three NICs in a single firewall machine as follows:
- NIC1 for the WAN : Your gateway to the Internet; everything comes and goes through this NIC
- NIC2 for the LAN : Behind this NIC is where you have all your private assets, i.e. file servers, domain controllers, questionable media collections, etc.
- NIC3 for the DMZ : This is where you put any machine that you want to allow people on the Internet to connect to, i.e. web servers, ftp servers, mail servers, game servers, etc.
This is one method of creating a DMZ, but it is not the best way. This configuration allows the security of both your DMZ and your LAN to lie in one system. If your machine that has all three of those NICs in it is compromised, so is your DMZ and your private network as well. Basically, you are allowing the Internet to touch the very same machine that determines how secure your internal LAN is, and this is not ideal.
The better way to do this is with three completely separate networks and two firewalls – one on the border of your WAN (which handles your connection usually) – and one on the border of your internal LAN. This design makes it so that two separate devices must be compromised in order to get to your internal LAN, and as you will see later – it’s no an easy thing to do.
We’re going to proceed with the second and more secure configuration which is often referred to as a ‘sandwich DMZ’ due to the use of two firewalls (the servers in the DMZ are the meat). Let’s say you have two firewall devices available to you – a broadband router such as a Linksys, and a Linux-based firewall like an Astaro or SmoothWall box. You start by placing your Linksys on your border (right behind your modem), and connecting the LAN side of that router to a hub or switch. To that hub or switch (your DMZ hub/switch) you connect your bastion hosts/public server(s). These machines run the services that you want people to be able to connect to from the Internet. This may be a web site, an FTP server, a mail server, or a multiplayer game box like WCIII or Counterstrike. You want this machine to be hardened as much as possible, meaning that it is completely patched, not running any unnecessary services, and is tightened down as much as possible in terms of configuration.
Now, to that same hub (the DMZ hub) you are going to attach another network cable that goes to the external interface of your internal firewall (your Linux firewall). It is important to note that you want your strongest firewall closest to your LAN; or, putting it another way, you want your least powerful firewall on your border. This may seem counterintuitive but it’s usually best. Basically, you want the most powerful and most configurable firewall protecting your LAN – not your DMZ. Then connect another cable from the internal interface of your Linux box to another hub (your internal hub). All of your LAN machines will connect to that.
If that was confusing, think of it this way:
Internet -> Modem
Modem -> Router
Router -> DMZ Hub
DMZ Switch -> Web/Mail/FTP/Game Servers
DMZ Switch -> Linux Firewall External NIC
Linux Firewall Internal NIC -> LAN Hub
LAN Hub -> LAN Systems
Ok, so let’s take a look at the added security that is offered by this setup. First off, at the border you have NAT translation that passes only the ports that you need to in order for people on the Internet to access the servers in your DMZ. Let’s say, for example, that you’re running a web server, an FTP server, and a game server for a game called Foo. On your border router/firewall you pass ports 80, 21, and 10050 (the Foo server port). All attempted connections to your external, WAN IP address that aren’t on those ports drop dead at your router; only those three ports are allowed through because of NAT. The nature of NAT as implemented on most SOHO routers dictates that only two types of traffic can pass from the outside of the router to the inside: return traffic (traffic that’s part of a connection that originated from the inside of the NAT device, and any incoming traffic to ports that are defined as ‘passed’ in your NAT configuration. All packets traversing the device are compared to a table inside the device that is similar to a firewall policy, and if a given packet doesn’t fall into one of the two categories above, it gets put on the floor. This side effect of NAT, while not its original or main goal, is a fairly powerful security feature, and it makes up our first layer of defense on the border. Of course, if your device supports packet filtering of any sort in addition to NAT then you can further lockdown your perimeter by using that functionality as well.
This first border layer, while being good, is just one layer of the shielding offered by this configuration. The real beauty of this setup lies in what happens if someone is able to compromise a machine in your DMZ. Imagine that you have the setup I laid out above, but unbeknownst to you there is a major, undiscovered vulnerability in your Apache or IIS server. While you’re out and about thinking all is well, someone launches the zero-day exploit at your box and takes it over. Now what?
Now nothing. Your second and more powerful firewall (the one that they are still outside of) – does not pass ANY traffic from the DMZ to the LAN. In fact, you should have your internal firewall configured in such a way that it won’t even reply at all to any DMZ machines – no ICMP, no port scans, nothing. And now, rather than being able to bounce around on your juicy internal LAN like they planned, they are stuck in the middle of a completely untrusted, isolated network that doesn’t have anything on it other than what you intended for public viewing anyway.
This is a DMZ.
Even if they did know the IP of the internal firewall, it wouldn’t even consider passing connection attempts from the DMZ. This internal layer of protection is NAT’d just like your first layer, only there are no ports being passed inside like from the Internet to the DMZ. Due to the NAT table, and your lack of ports being passed, your second firewall actually has no idea what to do with packets that are designed to initiate new connections with it, so it just drops them. The only traffic that is going to make it through that firewall is traffic initiated from the inside, i.e. when you go to /., it will allow the web content to come back to you so you can view the page, but if someone tries to initiate a new connection to you, they get dropped. Both NAT and stateful packet inspection (an advanced firewall technology that’s built into modern Linux firewalls) afford this protection to you – each in different ways.
So, to sum it all up, imagine you have your network setup the way we have talked about above, and someone with a zero-day exploit is scanning around looking for web daemons to tear up and they find yours. So, they connect to it, check the version you are running to confirm that you’re vulnerable, and then scurry to fire up their new exploit tool that someone else wrote. What they probably don’t know is that they are actually connecting to a ‘non-routable’ IP in your DMZ. It has no ‘real’ IP address as far as the Internet is concerned, and if you hadn’t passed that port on your router they wouldn’t have seen anything at all with their scan.
But let’s say they do see your web daemon because you are passing port 80 through to your web server, and it turns out it’s vulnerable. They run their exploit and get complete control of your box. This, of course, causes them tremendous joy, and they hurry to tell all their buddies because they think they’re starring in Hackers now. The thing is, they have little to celebrate. All they have is a barebones server with nothing of value on it – no vital info, no browsing history, no personal information, nothing.
In fact, all the attacker has access to is content that you wanted the public to see in the first place! (which is also safely backed up, of course).
They proceed to poke around in your DMZ only to find that there isn’t anything there that they couldn’t have seen from the other side of the planet with a web browser. The odds are that at this point they’ll either load some trash onto your system in order to use it as a server or an attack zombie, or they’ll just deface and/or destroy it. Either way it doesn’t matter. The moment you detect what has happened (see Snort, Tripwire, etc) you simply pull the plug, reinstall the box, and restore the backup. Within a few minutes you have a brand spanking new system ready to go back online, and at no point during the process was your private LAN in danger. This is the benefit of running a true DMZ.
Things To Keep In Mind
There are a couple of things worth mentioning about DMZs that I’d like to cover. First of all, there are many SOHO appliances on the market that advertise themselves as having a DMZ. Be weary of these. Some do actually have a true DMZ interface that can be used in the triple-homed configuration and combined with packet filtering, but many just have a port that all traffic gets forwarded to when you enable the ‘DMZ’. This is a horrible perversion of the word, and it offers very little, if any, security. What that basically does is pass all ports from the external interface to the box that you connect to the DMZ port. If security is a priority, don’t do that. This is nothing but another example of manufacturers catching onto buzzwords and inserting them into their marketing. Rule of thumb: it’s not a true DMZ interface unless the product gives you full control of what gets passed back (via NAT) to machines connected to it.
There is also some debate on whether to use hubs or switches for connectivity within your DMZ and LAN, due to security concerns associated with hubs. I used the word ‘hub’ in the paragraphs above for the sake of simplicity, but it’s important to consider the performance and security implications of using each. On the security side, many people say not to use a hub because it would be possible for someone with access to a compromised machine (and the right tools) to run a sniffer and watch all of the traffic going between the Internet and DMZ to the private LAN. This is potentially a concern, but anyone who is going to sniff your internal traffic in order to launch a sophisticated attack later is going to know how to sniff across most switches as well. It is trivial enough to do this that it’s arguably permissible to use a hub in the DMZ if you have a good reason to. I do so in order to allow my IDS machine in the DMZ to be able to see all traffic on that network. Switches with mirror ports are still a bit too pricey (but I’m watching ebay for 2950s)
Last but not least, a DMZ is not an impenetrable defense vs. attacks. It’ll stop the vast majority of people that the average person running services would come upon, but if a highly skilled cracker wanted spend a whole lot of time and effort, he/she could still be successful. Nothing is worse for your security than thinking you are completely secure.
For questions and/or feedback, I can be reached at firstname.lastname@example.org.
‘cat knowledge | grep understanding’