Security Advisor

Dump Your DMZ!

Many DMZs aren't as secure as you might think -- here's how to determine if yours have outlived their usefulness.

• By Joern Wettern
• 07/01/2005

DMZs (short for demilitarized zones) have been a standard component of network design ever since firewalls were invented. A DMZ is a network segment that contains all resources, such as Web servers and mail servers, accessible from the Internet. Implementing a DMZ allows you to limit network traffic from the Internet to these resources in the DMZ, while preventing any network traffic from the Internet to your internal network. As a general rule, a DMZ server should never contain any valuable data, so even if someone managed to break into a server in the DMZ, the damage would be minor.

Things get more complicated when you need to allow some traffic between the DMZ and other servers. You may have SMTP relay servers in your DMZ that need to communicate with internal mail servers or a Web server that gets its data from an internal database server. Unfortunately, implementing a DMZ-based solution that allows for such communications often leads to an inefficient or ineffective DMZ.

I believe that DMZs can give you a false sense of security. If you do a thorough assessment of your security architecture, you may well decide you'd be better off just dumping it.

Even considering such a move may seem like a sacrilege, but bear with me as I explain why DMZs, in most cases, are outdated security structures. The idea of a DMZ is so ingrained that it may be hard to shake it loose, but doing so may just strengthen, rather than weaken, your security infrastructure.

Common DMZ Designs
To illustrate the problem with DMZs, it's helpful to closely look at some of the most common DMZ designs. A type of DMZ often used by smaller organizations is the three-legged layout, shown in Figure 1. With this design, a single firewall controls the entire flow of network traffic. This includes connections from the Internet to the DMZ and from the DMZ to the internal network.

Figure 1. Known as the "three-legged DMZ," this configuration is common in smaller networks. (Click image to view larger version.)

Operating Exchange with a firewall highlights the problems of such a design. Many network administrators have used a front-end/back-end topology to allow Exchange to send and receive e-mail, and to allow users to access their e-mail remotely. The firewall rules allow network traffic between the Internet and the front-end server over TCP port 25; incoming client traffic may also be allowed over port 110 for POP3 or port 443 for Outlook Web Access (OWA).

Because the front-end server has to be a domain member and communicate with the back-end server and domain controllers, you have to allow further traffic between the DMZ and the internal network. This traffic includes protocols such as Kerberos, Lightweight Directory Access Protocol and Remote Procedure Calls. It's difficult to restrict the number of ports used by these protocols, but even if you succeed in narrowing down the range, you still end up with a large number of ports in your firewall.

You can improve the security of your firewall by using a second firewall to implement a back-to-back design, shown in Figure 2. With this design, an external firewall controls the traffic between the Internet and the DMZ. A separate internal firewall controls the flow of traffic between the DMZ and the internal network. Using two firewalls eliminates the single point of failure in the three-legged design. In a three-legged design, a hacker who can bypass the firewall can gain access to the internal network. With a back-to-back design, the internal firewall protects the internal network even if hacker has managed to bypass the external firewall. However, using two firewalls still doesn't solve the fundamental problem of using port-based control of traffic between security zones.

Figure 2. This dual firewall design, a typical DMZ configuration, is more secure than the one in Figure 1, but still isn't the optimal setup for security. (Click image to view larger version.)

Why DMZs Don't Work
The DMZ concept relies on firewall rules that allow network traffic to move between different security zones based on IP addresses and ports. Some firewalls add inspection of application-layer filtering to the mix, inspecting application protocols like HTTP. For communications between the Internet and your publicly accessible servers, you have to rely on addresses to define firewall rules; because there is currently no technology that can reliably authenticate computers on the Internet, you have no control over what's out there. A good security design compensates for this lack of authentication by severely restricting and carefully monitoring any traffic from the Internet, because you can't trust any computer you don't control.

Communications between computers in the DMZ and your internal network are different. A DMZ design assumes a certain level of trust between computers in the internal network and computers in the DMZ. Many DMZ designs use firewall rules that allow domain communications from the DMZ to internal domain controllers. For instance, communications from the IP address of a Web server in the DMZ may be allowed to an internal SQL server that contains customer data, and Exchange front-end servers in the DMZ may be able to freely establish connections to an internal back-end server and all internal domain controllers. Firewall rules that allow such traffic are routinely based on IP addresses and ports alone.

The problem with IP addresses is that they can lie. They're easily spoofed, and logon requests to a domain controller that appear to originate from your mail server's IP address may instead have come from a computer that's been taken over by an attacker. Similarly, ports aren't reliable indicators of the type of network traffic. For example, port 80 is most often used for Web communications, but there's no guarantee that it isn't used by an attacker to transfer confidential data out of your internal network to a computer in the DMZ controlled by this attacker.

A final problem with DMZ servers is that they often pass on Internet traffic without significantly changing it. When a Web server in the DMZ queries a SQL Server in the internal network, it may pass along legitimate queries from the Internet along with SQL injection attacks. Having a DMZ gives you the impression that the SQL traffic into your internal network originates from the DMZ, but in reality it is traffic from the Internet that was simply converted to a different format by the Web server, then forwarded to the SQL Server. As you can see, moving beyond IP addresses and ports is an important part of overcoming the limitations of using a DMZ to keep your network secure.

Trust No One
Another weakness of using a DMZ is the antiquated idea of assigning different levels of trust to different network segments. You can't trust computers simply because they're part of your internal network--there may be employees who snoop around the network and computers infected with worms and viruses. In the same vein, computers in your DMZ shouldn't automatically trust each other, because each of them accepts different connections from the Internet and is potentially subject to attacks from the outside. Most of all, computers in your internal network should never trust a computer in the DMZ, since it could well be compromised.

The worst case of misplaced trust is to put a member of your internal domain in your DMZ. This requires opening a large number of channels to domain controllers on the internal network. An attacker who's gained control over a domain member in the DMZ can use these channels to freely communicate with internal servers, including domain controllers. This means that your firewall design provides little--if any--extra protection over a design that allows direct connections from the Internet to your internal network. Placing an Exchange front-end server into the DMZ is one of the most common reasons for making this mistake, but it's not the only one. Using a firewall to separate domain members adds complexity to your network design, but it rarely adds security.

Network designs that don't recognize this problem with assigning trust give you a false sense of security, and fail at what they're designed to do--ensure that internal servers only talk to specific computers in the DMZ. When DMZs became popular, IP address and port restrictions were all that was available to control network traffic. Today there are better tools to confirm the identity of a trusted computer. Implementing such authentication along with application-layer filtering provides a higher level of security than most traffic controls I've seen implemented on firewalls today. Once you start using such technologies for communications between your servers you're likely to find that having a DMZ no longer provides any value and needlessly complicates things. At that point you're probably ready to dump your DMZ.

What You Can Do
DMZs have been a standard component of network design for a long time. Replacing them requires assessing the exact nature of network traffic between computers. Here are some general guidelines to use:

• Keep it simple. The first recommendation applies to all aspects of network design and security. Unnecessary complexity inevitably leads to security risks. As you're evaluating the design, ask yourself whether each element really accomplishes its purpose. If not, drop the unnecessary element.
• Challenge your assumptions. Just as having a firewall doesn't automatically make your network bulletproof, implementing a DMZ doesn't solve your security challenges. If you're using a DMZ, think hard about its purpose and then analyze whether it really helps accomplish your goal.
• Avoid shortcuts. I've seen many cases where network administrators took shortcuts to handle implementation problems, and as a result created new security problems that were even worse. For example, some network administrators create VPNs between Exchange front-end and back-end servers, or put domain controllers into a DMZ when they weren't able to configure their firewall to permit communications between a domain member in the DMZ and an internal domain member. That defeats any traffic inspection at the firewall and can give an attacker easy access to a domain controller.
• Use host-based protection. Using a firewall to control traffic between two computers in different security zones doesn't protect against attacks from within the same security zone. Configuring packet filters on your servers and using the Windows Firewall included with Windows XP and Windows Server 2003, Service Pack 1, can often achieve the same port-based traffic control between servers as a firewall. It can also prevent unwanted access from within the same security zone.
• Use IPSec. IPSec, available with Windows 2000 Server and later, is used to provide security for IP packets. It can provide three functions: mutual authentication, packet integrity and encryption. Mutual authentication deals with the inadequacy of relying on IP addresses and ports for authenticating network traffic. When using IPSec, a computer only trusts IP packets from another computer if they were signed using a certificate from a trusted certification authority. Packet integrity ensures that packets haven't been altered in transit. Encryption can defeat eavesdropping attacks, but it also prevents traffic inspection by firewalls or intrusion detection systems. Because of this potential risk, you need to know exactly when to use IPSec for authentication and integrity checking only, and when to use it to encrypt network traffic.
• Use smart firewalls. Old-style firewalls that filter based on IP addresses and ports have lost much of their usefulness. This doesn't mean, however, that there's no role for firewalls today. Today's firewalls, which are able to inspect application-layer protocols, can be an important component in controlling network traffic between publicly accessible servers and the resources they depend on (see my May 2005 Security Advisor column, "Picking the Right Firewall," for more on firewalls).

When To Keep Your DMZ
While there are often good reasons to dump your DMZ, there are still some situations where using one makes sense. The most common one is for servers that accept connections from the Internet but don't need to communicate with your internal network, such as a simple public Web server. Also, if you're using simple protocols and require no computer authentication, DMZs can provide the level of security you need. For example, SMTP relay servers that send and receive e-mail messages but don't store or process them are perfect candidates for placement in a DMZ.

No Ideal Solution
After using the example of an Exchange front-end/back-end design to point out the problems of DMZ configurations, I'm often asked to recommend a better solution. There is no ideal solution, and the specifics depend on an organization's requirements, but the design shown in Figure 3 is appropriate for many networks. This design includes two firewalls to provide redundancy, with at least one of the firewalls being smart enough to perform inspection of the application-layer protocols allowed into your network. ISA Server 2005 is one example. Also, such a design should incorporate tight control of network traffic between internal servers.

Figure 3. This design uses two firewalls, but doesn't expose computers in a DMZ, providing your network more security than a standard DMZ configuration. (Click image to view larger version.)

For more protection, implement intrusion detection at several points in the network and use IPSec policies to control which network traffic is allowed between the servers and client computers on the internal network.

Just Re-Do It
No matter what your final network design ends up being, make sure that you carefully look at whether it really accomplishes what it's designed to do. If it doesn't, it's time to dump your DMZ and replace it with other types of protection, or to redesign it to make it do what it was designed to do.