DMZ Implementation Methods

The demilitarized zone (DMZ) is a common element of most perimeter modules. In concept, the DMZ is pretty simple: you need to place a barrier between your internal network and any external hosts that ensures that no requests that originate from the external network can be directly passed to your internal network. In practice, however, the DMZ can be a rather complex component of your network, because a number of different types of DMZ implementation methods can be used. We are going to look at the pros and cons of the following DMZ designs:

Multi- homed firewall
Dual firewall

In addition, we ll take a look at an often raging debate in the security world: the use of virtual local area networks (VLANs) for your DMZ.

Using a Multi-homed Firewall for Your DMZ

Using a multi-homed firewall to create your DMZ architecture is a relatively common DMZ implementation. It is sometimes known as a DMZ on a stick. Figure 11-1 illustrates how it functions.

Traffic can pass to and from the DMZ and the Internet. Traffic can also pass to and from the DMZ and the internal network. Finally, traffic can pass from the internal network to the Internet. The most important point, however, is that no traffic can pass directly from the Internet to the internal network. Instead, those requests must all pass to a proxy in the DMZ, and the proxy can then issue the request against the internal resources on behalf of the external client. Figure 11-1 illustrates this with dotted lines representing the direction in which traffic can be initiated. Reply traffic is assumed to be allowed and is not indicated on the diagram. An excellent example of this would be using a Simple Mail Transfer Protocol (SMTP) proxy for passing Internet-based e-mail to your internal e-mail services. This buys you the protection of ensuring that external traffic can never directly access internal hosts and resources.

An often overlooked aspect of DMZ filtering is the application of filtering at the external router. By implementing filtering at an external router, you can add a layer of security, ensuring that the firewall needs to concern itself only with traffic related to the services and resources being offered at the DMZ. You should implement filtering at the external router for all DMZ designs.

While Figure 11-1 shows only a single DMZ, you can create additional DMZs by simply adding more interfaces to the firewall. This would allow you to create task-specific DMZs ”for example, having one DMZ exclusively for VPN and remote access connections and another DMZ for Internet-based traffic and requests (such as SMTP or HTTP traffic). The only real limitation on the number of DMZs that you can have is the number of interfaces your firewall supports.

Figure 11-1: Multi-homed firewall DMZ without redundacy

The next progression of the DMZ on a stick design is to introduce redundancy into the design. The objective of redundancy is to ensure that no single failure will cause a loss of functionality. This design specifies that you have multiple firewalls, switches, and routers that connect to separate Internet service providers (ISPs). By simply ensuring that both firewalls have a connection to the switch in the DMZ, you gain the full benefits of the DMZ regardless of which firewall is functioning. Figure 11-2 illustrates a multi-homed firewall DMZ with redundancy.

Figure 11-2: Multi-honed firewall firewall DMZ with redundancy

The benefits of this type of DMZ design are as follows :

Simplicity The design is pretty simple: you add an interface to your firewall and configure it accordingly .
Cost This design does not require as much additional hardware as other DMZ design solutions.

One Step Further

If possible, you should use separate providers for the local loop and keep power for the primary and secondary loops on separate uninterruptible power supplies (UPSs) and power grids.

The primary drawback of this type of DMZ design is that you are relying on a single device, in this case the firewall, for handling all of the traffic. If the firewall can be compromised, your internal network could be left completely unprotected . Even with this drawback, the DMZ on a stick design is a good design for a cost-conscious company.

One Step Further

When implementing firewall failover using in- band heartbeat (the heartbeat is sent via the network instead of a dedicated failover cable), you may need to change the design slightly to account for latency in the heartbeat network. This is especially true in cases where the DMZ spans multiple buildings or locations, where the loss of heartbeat could cause a failover due to faulty cabling.

Using Dual Firewalls for Your DMZ

The use of dual firewalls is the natural progression of the router and firewall DMZ design. Through the use of dual firewalls, all of the drawbacks of the router and firewall design are mitigated. In addition, the use of dual firewalls provides even more security than any other design through the use of two different firewall vendors products, ensuring that in order to access internal resources, someone would need to compromise both types of firewall. Figure 11-3 depicts a dual-firewall DMZ.

Figure 11-3: Dual-firewall DMZ

As you can see in the figure, the DMZ is bordered by two firewalls. The first firewall protects the DMZ and internal network from Internet-based threats. The second firewall protects the internal network not only from Internet-based threats, but from any potential threats that originate from the DMZ as well. This type of system is commonly implemented with faster packet filtering or hybrid firewalls at the Internet side and more advanced application proxies or application-level gateways at the internal network side. This facilitates access to DMZ resources from the Internet while requiring a more thorough examination of data attempting to pass through to the internal network.

Like all of our DMZ designs, you can implement redundancy to provide fault tolerance, as shown in Figure 11-4.

Figure 11-4: Dual-firewall DMZ with redundancy

The primary benefit of this type of DMZ design is security. The primary drawback is cost. As a result, dual-firewall DMZ is commonly implemented in environments where security is critical at any cost ”for example, in banking and finance organizations.

One Step Further

Many people think that because resources that reside in the DMZ are frequently accessed by Internet-based hosts, the resources must use real IP addresses, but this is not correct. You can implement Network Address Translation (NAT) at the firewall or routers in front of the DMZ and use private addresses on your DMZ. At that point, you can simply advertise the DMZ resources on the firewall using routable IP addresses and map those addresses back to the private addresses that the DMZ hosts are using. In fact, this is generally the recommended approach to use.

Heads Up

Using a router in place of a firewall in the DMZ design is a common occurrence. The drawback of this approach is that your router isn't a firewall and generally speaking should not be used as a firewall. This type of DMZ design should not be used and should be replaced in your environment if it is in use. If you must use it, however, you should harden your router as if it was a firewall and include, but not be limited to using, a firewall software feature set.

VLANs and DMZs

A discussion of the use of VLANs in DMZs frequently results in a heated debate. The logic is pretty sound: You have a relatively big switch and you are not using all the ports on it. You also need a few ports to create a DMZ. You have two options ”you can either buy an additional switch, which takes power, connectivity, and rack space, or you can simply create a VLAN on the switch for the ports that you want to use for the DMZ.

No good answer exists as to which solution is the best solution because best is a subjective term . Let s take a look at some of the pros and cons, though, so that you can be better informed on which solution will work in your environment. Using VLANs is advocated because you can use equipment that already exists on your network. The biggest argument against using VLANs for your DMZs is that traffic can inadvertently pass from one VLAN to another in some circumstances. Many of the vulnerabilities that exist with VLANs is covered in depth in a whitepaper at http://www.sans.org/rr/papers/38/1090.pdf.

I can make one recommendation, however: you should never implement VLANs on the same switch for networks with differing security levels. For example, you should never VLAN a switch between your DMZ and your internal network. This will ensure a few things. First, someone won t accidentally plug internal resources into the DMZ and vice versa, because the ports are on the same device. Second, if there is a chance that the traffic can be passed inadvertently between the VLANs, someone at a lesser security level won t potentially be able to gain access to resources that they shouldn t. Third, there isn t a chance that the switch gets configured incorrectly, inadvertently putting the wrong device in the wrong VLAN. Last is the administration considerations. While VLANS aren t incredibly complex, if you have a 48-port switch with 18 different VLANS in it, it can get messy. This increases your odds of a misconfiguration, which could result in a security risk. It also makes troubleshooting much more difficult down the road if something needs to be reconfigured or upgraded.

When I consider whether or not to use VLANs, I tend to keep one thing in mind: the goal of a DMZ is security. Consequently, I don t want to do anything that could possibly be a security vulnerability for something for which I require stringent security. Therefore, I don t recommend using VLANs. The only way that VLAN vulnerabilities can be exploited is if you use VLANs. With the low cost of many switches today, I can t justify the security exposure for the savings that using an existing switch might provide.