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.

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 three-legged DMZ.
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. Dual firewall design.
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. More security than a standard DMZ configuration.
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.

comments powered by Disqus

Reader Comments:

Mon, Oct 11, 2010 Dave Cape Town

This article is pretty daft. Two firewalls in series? What does that achieve other than more cost, effort and latency? Typical consulting here, long on blah blah, no useful real world solutions.

Thu, Apr 2, 2009 Anonymous Anonymous

This is an example of why no one takes Microsoft engineers seriously.

Thu, Apr 2, 2009 Anonymous Anonymous

This is an example of why no one takes Microsoft engineers seriously.

Fri, Sep 12, 2008 Anonymous Anonymous

I have an issue with the author's concept fo a DMZ. By using his concept in figure 3, you have essentially created a DMZ between the two firewalls. Worse yet, if you were to implement OWA access in that scenario, you would eitehr have to give the Internet direct access to your core or have rules on internal firewall to allow the ISA (acting the external firewall) to communicate with the Excahgne infrastructure... which brings us back to the problem the author was making about allowing DMZs access into your core.

Wed, Jan 23, 2008 Luís Portugal

I second the first anonymous. I allways like to read this kind of articles.

Fri, Jan 11, 2008 Anonymous Anonymous

It's nice to read articles from people who actually take the time to think about the implications of a design strategy and keep an open mind to alternatives. Well done!

Tue, May 9, 2006 Jason Connelly Illinois

Regardless of the OS, you also have to also figure in the responsibilities you may have depending on the organization that you are a part of. While solutions like App firewall and other third generation firewall products have a place in the industry, there are still requirements such as the Payment Card Industry Data Security Standard which require a DMZ without exception. Organizations that serve bank applications (Office of Thrift and Savings), and HIPAA have similar requirements. To make the statement that this author has made and not state that industry requirements may prohibit removing your DMZ, is highly irresponsible.

Thu, Feb 16, 2006 JMM Texas

I take that back. We recently switched to openBSD, which has helped us practically eliminate many of the security holes found in Microsoft. Not only is it more secure, but it has helped us revive some of our older hardware, as it runs much more efficiently than our Win 2000 server.

Sat, Oct 15, 2005 JMM Texas

Linux is a real OS? Yeah . . so mature. Let me recompile my kernel every two or three weeks . . yeah . . thats much better. Comments like that are meaningless to this discussion.

Thu, Aug 11, 2005 Anonymous Anonymous

why not just format c:\ and install bsd/linux and not worry so much about this stuff? all this is from a microsoft pov, so just eliminate the big hole in your setup, and get a real OS

Thu, Aug 11, 2005 Anonymous Anonymous

its not the inbound traffic you have to worry about anymore, its what worms are in your network trying to get out, and do damage

Thu, Aug 11, 2005 Anonymous Anonymous

The author argues that DMZs should be dumped because:

1. A lot of ports need to be opened between DMZ and internal network in a Windows domain architecture

2. Traditional frewalls don't inspect application layer data

3. The firewall becomes a single point of failure if DMZs are present.

4. IP addresses can be spoofed.

It does not follow from the above arguments that DMZs should be dumped. Here's why:

1. DMZs enable us to contain the extent of damage when publicly facing servers are compromised, even if several ports are opened between the DMZ and the internal network. Yes, it's unfortunate that Windows protocols require several ports to be opened, but a firewall still limits traffic to just those ports and between those IPs.

2. Firewalls do not protect against application layer attacks on the ports the firewalls allows. That is not the firewall's goal, anyway. The objective is to block traffic to other ports that could have been broken into. DMZs strengthen that.

3. The firewall is a single point of failure, irrespective of whether DMZs are present or not. The solution is to design for failover, not dump DMZs.

4. A tcp connection that traverses the firewall cannot be spoofed. And anyway, that has little to do with DMZs :-)

The article finally presents the "new" recommended architecture. Interestingly, it has two single-points-of-failure instead of one, after dumping the DMZ.

Wed, Aug 10, 2005 Matt Australia

Whilst I do like many of the points you raise in this article, I would like to comment on a couple.
Firstly, using a DMZ will not help when you use a poorly designed (from a security perspective) product in both the DMZ and Internet network, such as Exchange front-end.
Secondly, having two firewalls in a row is NO better than having one in terms of reliability. In fact it is worse, twice as unreliable due to the fact that if one fails, the other is useless.

Wed, Aug 10, 2005 Anonymous Anonymous

Good article. Put me think again of our companys email systems. I think we are going to move away from Exchange to something better suitable for internet use.
Maybe IBM, Apple or Novell has an answer...
It's good to shake old structures sometimes. Keeping something just because all the others has the same, is rarely the best solution.

Thu, Jul 21, 2005 anonymous us

while i do find the article interesting i cant help but think its another case of 'its easier for us'.
although i should probably shut my mouth and take a back seat to the true experts here
for my 02, i would say the dmz should be in its own domain, my prefered would be virtual instances of ms running on linux clusters, with drag and drop replacment of the ms stuff as its compromised, tied to a physical key, such as an unplugged network connection and or one way cat 5.
i like the ideal of only stand alone servers in the dmz but with certain products its just not going to work. also the vast majority of this "stuff" is the fault of the software vendors...

Thu, Jul 14, 2005 Anonymous Anonymous

Accurate summary? 1) Require all centralized data sources to have certificate based authentication (IPsec?), 2) Use an empty back-to-back DMZ configuration, 3) Dual home any server/ data source that communicates with the Internet while dramatically restricting port and IP access on the quasi public interface, 4) Use the best layer 7 firewalls (or two) and configure with maximum control. 5) Require VPN for all mobile wireless access to corporate assets including OWA, Intranets, and leverage IPsec & cerficates security as well. 6) Turn on all personal firewalls and manage via security policy (ISA 2004? actually proxies VPN access until the security policy on the remote connection (VPN client) is up to snuff. VERY powerful stuff to prevent inadvertant network bridgeing.

Wed, Jul 13, 2005 Anonymous Anonymous

The Exchange front-end server in the DMZ example is daft, as not even a half decent admin would do it that way. The correct way is to put a reverse proxy in the DMZ with application layer filtering and only allow standard ports (i.e. 80, 25, 443) between specified hosts in the DMZ and Internal network. The same goes with DB back-end web servers. Never ever put a domain member in the DMZ, period.

Mon, Jul 11, 2005 Anonymous Anonymous

With today's technology, if using one firewall with virtualization, you can accomplish whatever you want, even the design with external and internal firewalls

Sat, Jul 2, 2005 Anonymous Anonymous

What do you guys think about using dmz's to protect wireless? I like to put wireless clients in there own dmz than allow them to vpn into the internal network.

Thu, Jun 30, 2005 Anonymous Anonymous

Interesting article, tnx!

Add Your Comment Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.