Building Yourself a DMZ

Eventually, if you get interested enough in information security, 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 De-Militarized Zone, and in the ‘real’ world it is the location between two hostile entities such as North and South Korea. In the Security community, however, it is a separate, untrusted network where boxes serving public services should be placed.

It’s a buffer zone between a completely untrusted network (like the Internet) and a relatively trusted network (like your private LAN). The primary reason for implementing a DMZ is to keep your public and private assets separated so that a compromise in the public area does not automatically result in a compromise of your private assets as well.

Options

There are two main ways to implement a DMZ for personal use. The first is using three or more NICs, as follows:

1. 1 NIC for the WAN (your gateway to the Internet; everything comes and goes through this NIC)
2. 1 NIC for the LAN (behind this NIC is where you have all your private assets, i.e. file servers, domain controllers, questionable material collections, etc.)
3. 1 NIC 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 preferred method. 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 while the risk is pretty low, it’s not the ideal situation.

The Sandwich

The better way to do this is with three separate networks – the Internet, your DMZ, and your LAN. This is accomplished by using two firewalls – one on the border of your WAN (which handles your connection usually), and one on the border of your internal network. Let’s say that you have a broadband router (like Linksys, Netgear, Dlink, or whatever) and an OSS-software-based firewall (like Astaro, M0n0wall, etc).

What you do is you put your router on your border (right behind your modem), and you connect the LAN side of that router to a hub or switch. To that hub or switch (your DMZ hub/switch) you use one of the ports to connect your bastion host/public server(s). This machine (or machines) run the services that you want people to be able to connect to from the outside. This may be a web site, an FTP server, or a multiplayer game like WCIII or Counterstrike.

You want this machine to be hardened (preferably very well), meaning that it is completely patched and is running as few services as possible. As a general rule though, you want anything put in the DMZ to be resistant to attacks from the Internet since public access is the reason that you are putting it out there in the first place. How to harden the servers you put in your DMZ is outside the scope of this article, but suffice it to say that you want to lock them down – no services running that don’t need to be, all updates applied, etc. Now, to that same switch (the DMZ switch) you are going to attach another network cable that goes to your internal firewall (your Linux/BSD firewall).

It is important to note that you want your strongest firewall closest to your LAN; or, putting it another way, you want your weakest firewall on your border. This may seem counterintuitive but it’s usually the right way to do things. Basically, you want the most powerful and most configurable firewall protecting your LAN – not your DMZ.

As for your internal firewall, it’s going to have two NICs in it – one for the DMZ side and one for the private LAN side. Connect the cable coming from your DMZ switch to the DMZ side of the internal firewall (the external interface), and on the other side of the firewall (the private LAN side) you connect a cable to another hub/switch that all of your LAN computers will connect to.

If that was confusing, think of it this way:

Internet -> Modem
Modem –> Router
Router –> DMZ Switch
DMZ Switch –> WEB/FTP/Game Server
DMZ Switch –> Firewall External NIC
Firewall Internal NIC –> LAN Switch
LAN Switch –> LAN Systems

What This Gives Us

So let’s take a look at the Security that is offered by this setup. At the border you have NAT translation going on that passes only the ports that you need to in order for the public to use the servers in your DMZ. Let’s say you are running a web server, an FTP server, and a game server for a game called FooAttack. On your border router/firewall you pass ports 80, 21, and 5347 (the FooAttack server port). All other attempted connections to your external IP address drop dead at your border; only those three ports passed above are allowed through because of NAT.

The nature of NAT dictates that only return traffic (traffic is part of a connection that originated from the inside of the NAT device) will be allowed back into the NAT’d network. This side effect of NAT, while not its original or main goal, is a fairly powerful Security feature. If your border device supports filtering of any sort in addition to NAT then you can further lockdown your network by restricting who can and cannot connect to the hosts in your DMZ.

That first border layer, while being good, is just one piece of the overall DMZ Security posture. The real beauty of this setup lies in what happens if someone *does* get a hold of a machine in your DMZ. Imagine that you have the setup like I laid out above, but unbeknownst to you there is a major vulnerability in the web server you are running. So here you are offering web content to the entire Internet and someone runs the proper exploit vs. your machine and roots it. 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 inside to the LAN. (In fact, you should have it where it won’t even respond to ICMP from DMZ machines, so the odds are they won’t even know it’s there.) 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 and unprivileged 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 where the internal firewall was it wouldn’t even entertain the notion of 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. 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 that you specifically request be allowed through by talking to a machine outside of that firewall, 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 SPI afford this protection to you, each in different ways.

Conclusion

So, to sum it all up, imagine someone is scanning around looking for web daemons to tear up and they find yours. Many inexperienced attackers would assume that you are running something on your public IP address, as if you have your main workstation is sitting right on the Internet and it is running a web daemon. So, they connect to it, get a web page, and then scurry to dig up their favorite HTTP exploit tool that someone else wrote. What they don’t know is that they are actually connecting to a private IP in your DMZ.

It has no ‘real’ IP address as far as the Internet is concerned. If you didn’t pass that port at the border device then 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 DMZ host running a web site, and it turns out it has a vulnerability in it. They run their exploit and get root on your box. This causes them tremendous joy, and they hurry to tell all their buddies because they think they’re Alan Cox.

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 you have on there is content that you wanted the public to see in the first place (which is also safely backed up on your internal network and/or removable media).

So, they have root on the machine and ping around in your DMZ and soon find that there isn’t much there. If they are smart they will do an ifconfig (or ipconfig if you swing that way) and find out they are on a private subnet – but this gains them nothing. The odds are that from there they’ll either load some trash onto your system or try and destroy it.

Either way, it doesn’t matter. The moment you detect what has happened (tripwire, snort, whatever…) you simply pull the plug, reinstall the box, and restore the backup. Within a few minutes you have a brand-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 DMZ.

Hopefully this basic description of the general concept has been helpful to someone. If you have any questions about DMZs or any other Security topics, feel free to contact me.:

[Originally published in March of 2003 at NewOrder]