11.1 DMZ Network Design

Traditionally, the DMZ network design was done at the router level. A separate interface was added to the router, and a network segment was set aside strictly for the public servers. This network segment is connected directly through a router interface, and none of the traffic destined for the servers is routed through the firewall (Figure 11.1).

Figure 11.1. A traditional DMZ design: The DMZ network terminates at the router, and none of the DMZ servers are protected by the firewall

The problem with this traditional design is that it does not adequately take into account the security needs for these public servers. The only protection, aside from the security precautions taken for any server, afforded the servers in the DMZ would be the router ACL. In most instances, this would clearly not provide the desired level of security.

A second solution is to segment the DMZ on the firewall. Rather than terminate the network to the router, terminate it at a second interface on the firewall. This is shown in Figure 11.2. This type of DMZ makes a lot more sense. The servers can be protected by the firewall, and certain traffic can be allowed through the firewall, to the servers. In most cases, allowing traffic destined to the web server IP address on Ports 80 and 443, the DNS server IP address on Port 53, and the mail server IP address on Port 25 is sufficient.

Figure 11.2. A DMZ design using the firewall as the terminating point for the network. The firewall secures and isolates the DMZ traffic, which travels within a separate VLAN from the private network.

Another benefit to this solution is that it allows administrators to make use of the existing network infrastructure, rather than having to create a whole new one. On the private side of the firewall the traffic to the servers will be isolated to a single VLAN, preventing information from being shared between the DMZ and the rest of the network.

There are still problems with this design. The most notable is that there is no way to securely update information on the servers. There are also no facilities in place to secure the database transactions between the web server and the database server, or any of the backend servers. The common resolution to this problem is to put secondary network cards in the servers and assign them IP addresses from the private network. The servers can be plugged into the switch and connected to the private network through the backend, allowing updates from the private network through the secondary interfaces. This is shown in Figure 11.3. It also has the negative consequence of destroying any security put in place by the firewall.

Figure 11.3. A switch is used to facilitate communication between the public and private networks, creating a large security hole, and negating the purpose of the firewall and DMZ

Think about it. The purpose of the DMZ is to isolate the network. Rather than isolate the network, this design joins the two networks, making it very easy for an attacker to gain access to the rest of the network. A big red X should go through Figure 11.3 so it is never implemented.

A better way to enhance the security of the DMZ and facilitate communication between the machines in the private network is to add a second firewall. This is where some of the debate starts, although the premise is fairly simple:

1. Create a DMZ off the primary firewall for the public servers.

2. Add a second network card to the public servers. The second network card terminates to a secondary firewall, which allows access from the internal network to the servers, and from the web server to the database server, or any other specific queries that are required.

The debate originates in how this design should be implemented. There are two ways it can be done. The first method is to create an isolated network, as in Figure 11.4. The first firewall is connected to the edge routers on the public side.

Figure 11.4. Increase network security by adding a second firewall and creating a DMZ that is truly isolated from the network

Only the public servers exist on the private side of the first firewall. Each server has two network interface cards as well. The public interface connects to the first firewall, and the private interface connects to a secondary one.

The secondary firewall connects to the private interface of the public servers and to the private network. The two firewalls have different purposes. The front firewall provides access to the public server, but is very restrictive otherwise . The secondary firewall is even more restrictive. It allows certain types of queries from the public servers to the private network, and it acts as a gateway for the private network. It also allows the private network to communicate with the public network in a secure fashion.

What this creates is an additional layer of network security. An attacker has to go through two firewalls to get to the private network. Even if the target is a server on the public network, the information gathered on the public network is relatively limited, unless the attacker can get through two firewalls as well as the security precautions set up on the server.

NOTE

Most security experts recommend using two different types of firewalls for the DMZ; if an attacker is able to exploit a security hole in one firewall, the secondary firewall will most likely not be susceptible.

In some ways, this makes managing security policy less complicated. If a DMZ contains just a web server, the first firewall has to allow through-only traffic destined for Port 80 or 443. All other traffic can be droppedunless the request originated from behind the firewall. The second firewall is even more specific. It only needs to allow traffic from the web server to the database, or application, server on the private network. Because the same administrator controls both servers, a very precise hole can be punched into the firewall.

A second way in which this design can be accomplished is to have the secondary firewall back up to a management network. This is shown in Figure 11.5. The front firewall is configured in the same manner as Figure 11.2, with the DMZ and private networks being assigned different interfaces on that firewall. The secondary firewall connects to a management network, rather than directly to the private network. The management network, detailed in Chapter 17, is a separate private network used only by administrators to manage servers.

Figure 11.5. This network uses a firewall to segment the public and private networks, and a secondary firewall to secure data exchange between the two networks

Connecting the secondary firewall to a management network, rather than the primary private network, removes the advantage of the multiple-layer firewall design. It compensates for the loss, but it simplifies the firewall rule sets even further, making it easier to manage the firewalls.

Unlike the previous design, the secondary firewall only needs to allow certain traffic to the private interfaces of the server. The secondary firewall does not have to worry about general Internet access, as it will not be used for that purpose. This allows administrators to tighten the security on that firewall and severely limit the amount of traffic that is passed through. Alternatively, rules can be put in place to allow server management to the public interfaces of the servers. This is not recommended, but it can serve to increase the security on the second firewall even further.