You may have heard the acronym DMZ before, but do you know what it means? And more importantly, do you know how a DMZ can benefit you in your home or business network?

The acronym DMZ stands for demilitarized zone, which was a narrow strip of land that separated North Korea and South Korea. This strip was wide enough that soldiers on either side could stand and be out of range of each other’s gunfire, and if anyone ventured into the DMZ, he most likely was shot.

Stepping into a network DMZ is not likely to get you shot. In fact, it is encouraged. A network DMZ is a buffer between the Internet and your internal network. No, DMZ is not another fancy word for a firewall, but it does provide a similar kind of protection—just in a different way.

The firewall is merely a block; a hardware device or software package that stands between the Internet and your personal computer or network. The firewall uses specific rules to determine what packets are allowed in or out of the firewall, which ports are available to the public, and so forth.

A DMZ doesn’t do this. In fact, a DMZ should be placed behind a firewall, taking advantage of the protection that a firewall provides. The true benefit of a DMZ comes when you see how one is implemented. A DMZ is nothing more than a segment of your network that is isolated from the rest for the purpose of public use. Let’s look at an example to illustrate the concept more clearly.

A traditional network
A typical home network, and many small to medium-size networks as well, will consist of one point of entry to the Internet; this may be via cable, DSL, ISDN, or any other high-speed connection. This Internet connection is usually reached via a single system or hardware router. This system or router typically contains a firewall, which is used to protect the internal network from the external.

One choice system administrators sometimes make is to house their own Web site or other publicly accessible service (FTP, CVS, etc.) behind the firewall. The firewall will typically forward ports to the system providing the public services, thus providing protection to that machine. Typically, however, the system that provides publicly accessible services resides on the local network.

How does this impact the local network? Despite the fact that the system is protected by the firewall, the possibility exists that the software used to provide the service, for example a Web server, could be compromised. Breaking in through this service does not require any additional ports open for the attacker to successfully penetrate the machine, as they can do this using the available ports. Once an attacker has accessed your local network, it should be assumed that it is only a matter of time before that attacker can make his or her way further and begin penetrating specific systems and services unless you take immediate steps to secure the system.

The reason for this is because your public-access system is on the same network as your local intranet. To minimize the impact of a break-in to your public-access systems, you should make your local intranet unknown to your servers by putting the servers on another network segment, which is basically what a DMZ does.

Protecting your network with a DMZ
Using a DMZ will protect your servers from the local intranet and your intranet from your publicly accessible servers. This is done by making each portion of your network sit on different IP networks. Let’s take a look at two examples. The first is my own home network setup.

I have two publicly accessible systems that provide Web hosting services, FTP access, an IRC server, and so forth. Both systems are extremely public in the services they run. My local LAN, which consists of three Linux desktop machines, one Linux laptop, and a Windows98 system, is separated from my two servers, which are in a DMZ.

The two servers each have their own static IP addresses that are Internet IP addresses. My local LAN uses a Class C IP network with an address range of 192.168.1.1 to 192.168.1.254. I have a number of static IP addresses from my ISP, but I only use three of them: two for the public servers and the other as the gateway for my LAN. My ADSL connection comes in and is connected to a 10/100 switch. My two servers, each with their own IP address, are connected to the switch, giving them straight access to the Internet. Each server is protected by its own software firewall. The third static IP address is assigned to a firewall/router appliance that is connected to the switch. Connected to the router is another 10/100 switch to which my LAN computers are connected.

What this does is allow straight traffic through the ADSL modem to and from my two servers. The router provides firewall and NAT services to the local LAN. This means that although my two servers are within 20 feet of my desktop computers, my desktop machines consider them as external Internet hosts—the same as they would any other remote Web site. The two servers know absolutely nothing about my internal network, and any connections to my own Web sites are seen as coming from just another IP address that has been allotted from my ISP.

Because of this, if one of my servers is compromised, the attacker will have no easy access to my local network. There are no straight paths from the servers to the LAN, and the only accessibility to my LAN is still through the hardware firewall/router. If the attackers were to attempt to use my servers to obtain access to the LAN, they would have the exact same obstacles to overcome as if they were trying to gain access directly from their own system. There are no back alleys to my personal data.

Let’s take another example. I chose to use a hardware firewall as a middle ground between my LAN and my DMZ, but you may choose to use another method that will work as well. Say for instance that you currently have a Linux system acting as your firewall and router for your LAN. The firewall routes incoming packets for mail and Web services to a machine in your LAN for the publicly accessible services. It has two Ethernet cards installed, one to connect to the Internet and another to connect to your LAN.

To DMZ-ize your current setup, you would need to add another network card to your Linux machine, so you have eth0 connected to the Internet, eth1 connected to your LAN, and eth2 connected to your DMZ. Take your existing server or servers from your LAN and connect them to eth2 on your router system instead of eth1.

Next, you need to configure eth2 and your servers to use another network. Let’s assume that your static IP address for the Internet is 191.17.252.12, and you use the 192.168.1.x IP address for your LAN, and your servers use the 192.168.1.x IP addresses. Now you must choose another IP network for your DMZ. Let’s use the 192.168.100.x IP network.

Your firewall is currently configured to have eth0 assigned the 191.17.252.12 address. The eth1 device is configured to be 192.168.1.1, as it is the LAN’s gateway to the Internet. You would configure eth2 to be 192.168.100.1 and to act as the DMZ’s gateway to the Internet.

If you have two servers that were 192.168.1.12 and 192.168.1.23, you could change their IP addresses to be 192.168.100.10 and 192.168.100.11, respectively, or any other IP address in that IP network that you choose. Instead of using 192.168.1.1 as the gateway address, you would configure your servers to use 192.168.100.1 as the gateway address.

On the router machine, you would configure routing so that all packets coming in from eth2 would reach the Internet, as well. For the reverse, you would tell your firewall rules to route the packets to 192.168.100.10 instead of 192.168.1.12, so all packets coming in from the outside would get sent into the DMZ. Alternatively, you may configure your firewall to merely forward some specific ports to your public servers (i.e., forwarding port 25 for SMTP services) instead of routing the packets themselves. Finally, configure your firewall rules to deny all incoming packets to the eth1 device unless they originate from that device. You will also want to deny any packets coming from eth2 and destined for eth1 (unless they originate from eth1). You want to do this because you do not want any special preferences for your DMZ systems. Remember, the whole point is to make your own servers behave as if they were across the world (as far as your LAN is concerned). This means they should not know anything about your local LAN, including IP addresses or even the IP network they reside on. As far as the servers in the DMZ are concerned, your LAN should not exist.

Now you have a Linux firewall/router system with three Ethernet interfaces. Any packets coming in for your publicly accessible services will be forwarded to the third Ethernet device (eth2). All incoming packets not originating from your own LAN will be rejected on the LAN interface, or the second Ethernet device (eth1), regardless of whether they come from the DMZ or the Internet.

Sound a little complicated? It isn’t very complex, just a bit time-consuming to configure. However, the security this provides your LAN far outweighs any time considerations involved in setting it up.

The benefits of DMZ
Right now, the benefits of utilizing a DMZ should be fairly obvious. By isolating your public servers from the rest of your LAN, you increase the security of your LAN considerably. If someone hacks in to one of your public systems, you don’t have to assume that your LAN is compromised.

It also doesn’t afford any easy route to your LAN. Crackers sitting on one of your servers would have as much difficulty breaking in to your LAN as if they were attempting to do it directly from their own system or sitting on another compromised server elsewhere on the Internet. Considering that no sensitive information should be sitting on your public servers, you can rest a little more comfortably knowing that if your public systems are compromised, the sensitive information that should be restricted to your LAN will not be stolen or viewed.

The drawbacks of DMZ
Like any good thing, using a DMZ has its drawbacks. It has been said that the only way to achieve complete security is to make usability nonexistent. The more secure something is, the more difficult or painful it will be to use, and this is also true with a proper DMZ.

By having your Web server sitting in a DMZ, isolated from your local LAN, your employees will not be able to mount Web directories via Samba or NFS and directly modify Web pages or other files. They will have to use an FTP client to upload and download pages. This can be quite tiresome, especially knowing that the Web serving system is in the next room.

Access to the public servers is also much more restricted when it is isolated in a DMZ. If you used to have your public services combined with private services (for example, your Web server also doubled as a file and print server for your LAN), you will need to reconfigure your network and possibly purchase another system to handle the private services because you will not be able to print to a system in the DMZ. I don’t think this should be much of a concern because you really shouldn’t be combining public with private services on the same system. However, if you have done this, it will be another hurdle to jump as you reconfigure your network, which would be a good thing to do regardless of whether or not you are considering a DMZ.

Finally, if you are running a Web site that uses a database back end like MySQL, you may have to reevaluate how that information is retrieved. For example, if you previously had your Web server pull information from a central database on your LAN, you may have to set up another database server either on the Web server itself or on another system that also sits in your DMZ. Some people are uncomfortable with having a database sitting on the same system as the Web server, so you may need to obtain another computer to host the database. This computer should also be in the DMZ, but you should configure your firewall to not allow any outgoing or incoming connections from that system via the Internet. You should configure the database system to permit access only from the IP address of the Web server. This will protect your database and still allow you to maintain a proper DMZ. Again, you will have limited access to the database unless you physically sit behind the computer and log in to it or do so via the Web server computer.

Conclusion
Determining whether or not to use a DMZ requires some thought and careful planning. It can be an excellent benefit to your home or business network and properly configured, it can enhance the security of your local network. However, you have to weigh the consequences of setting up a DMZ in terms of usability of your servers.

I believe security should come first, and the inconveniences of using a DMZ are minimal compared to the potential consequences of not using one. To be honest, I have never had a system compromised by not using a DMZ, nor have I had one compromised after switching to a DMZ system. I am far more comfortable, however, knowing that I have another layer of protection in place.

Firewalls are excellent tools, but they are only one of many levels you can and should utilize. You should consider using a DMZ because it puts one more level of defense between a potential cracker and your sensitive information. The more levels of security you have in place, the more protected your information is.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays