`markdown

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

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).

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 -> ModemModem –> RouterRouter –> DMZ SwitchDMZ Switch –> WEB/FTP/Game ServerDMZ Switch –> Firewall External NICFirewall Internal NIC –> LAN SwitchLAN 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?

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.

Unsupervised Learning — Security, Tech, and AI in 10 minutes…

Get a weekly breakdown of what's happening in security and tech—and why it matters.

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]