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