The Best Damn Firewall Book Period

Before we get into an in-depth discussion of DMZs and firewalls, we need to go over some definitions of the components and a brief history of the DMZ and the philosophy that has led to the implementation of the technologies for protection. To begin, we define some common terms that we will use throughout the book as we discuss DMZs. Table 3.1 details and defines these terms.

DMZ use has become a necessary method of providing the multilayer approach to security that has become a popular method of providing security. The use of DMZ structures was developed as evolving business environments required the provision of increasing numbers of services and connectivity to accomplish the desired tasks for the particular business. New technologies and designs have provided a higher level of protection for the data and services we are charged with protecting.

Planning for network security requires an evaluation of the risks involved with loss of data, unauthorized access to data, and information compromise. The plan must also consider cost factors, staff knowledge and training, and the hardware and platforms currently in use, as well as helping with the estimations of future need. As we will see, the DMZ plan and concept provide a multilayered security capability, but as with anything that involves multiple components, administration costs and equipment costs increase with the complexity of the system.

It should be understood that no security plan is ever a final plan. Instead, we work continuously to revise and update the plan in an ongoing effort to provide the best possible coverage that minimizes the risk of intrusion and damage. Of course, before we can provide a meaningful and effective evaluation of the areas we need to protect, we must understand the components that have to be protected.

Originally, firewalls were used to divide a network into two: the trusted network (your enterprise network) and the untrusted network (usually the Internet or some other public network). Figure 3.1 shows the original firewall concept.

Figure 3.1: Original Basic Firewall Configuration

Since then, we've greatly expanded the role of our network infrastructure and our resources to provide information in response to both public requests and those of our employees and customers or partners. Additionally, the freely available tools and relative ease with which spoofing attacks and other attacks can be mounted against us have increased the requirements that we isolate our networks and protect the information that is contained on them. This is where we begin to consider the use of the DMZ concept, allowing us to better segregate and divide our networks. Figure 3.2 demonstrates a generic DMZ configuration.

Figure 3.2: Generic DMZ Configuration

One of the reasons for this shift in coverage is our need to provide services to some employees and others outside of the local area network (LAN) environment when we might not want to allow those services to be available to everyone. A single-method protection option (firewall, NAT, packet filtering) requires the administrator to completely allow or block a service or protocol to all connections and doesn't have granularity or flexibility in its operation. This inflexible arrangement meant that the third part of the triad, availability, was not always possible.

The addition of the extra layer of filtering provided by the second firewall (or more) in the control environment allows us to more finely control access to the data and servers hosting that data. This in turn allows us to more fully implement the second part of the triad, integrity. If we can control these access points more closely through access control lists (ACLs) and user accounts, for example, it is much more likely that we will succeed in maintaining the integrity of the data and keeping it in a protected and undamaged state. This gives the DMZ design flexibility and contributes greatly to the administrator's ability to provide good security and still provide services to those who need them.

DMZ Concepts

The use of a DMZ and its overall design and implementation can be relatively simple or extremely complex, depending on the needs of the particular business or network system. The DMZ concept came into use as the need for separation of networks became more acute when we began to provide more access to services for individuals or partners outside the LAN infrastructure. One of the primary reasons why the DMZ has come into favor is the realization that a single type of protection is subject to failure. This failure can arise from configuration errors, planning errors, equipment failure, or deliberate action on the part of an internal employee or external attack force. The DMZ has proven to be more secure and to offer multiple layers of protection for the security of the protected networks and machines. It has also proven to be very flexible, scalable, and relatively robust in its ability to provide the protection we need. DMZ design now includes the ability to use multiple products (both hardware- and software-based) on multiple platforms to achieve the level of protection necessary, and DMZs are often designed to provide failover capabilities as well.

When we are working with a DMZ, we must have a common ground to work from. To facilitate understanding, we examine a number of conceptual paths for traffic flow in the following section. Before we look at the conceptual paths, let's make sure that we understand the basic configurations that can be used for firewall and DMZ location and how each of them can be visualized. In the following figures, we'll see and discuss these configurations. Please note that each of these configurations is useful on internal networks needing protection as well as protecting your resources from networks such as the Internet. Our first configuration is shown in Figure 3.3.

Figure 3.3: A Basic Network with a Single Firewall

In Figure 3.3, we can see the basic configuration that would be used in a simple network situation in which there was no need to provide external services. This configuration would typically be used to begin to protect a small business or home network. It could also be used within an internal network to protect an inner network that needed to be divided and isolated from the main network. This situation could include payroll, finance, or development divisions that need to protect their information and keep it away from general network use and view.

Figure 3.4 details a protection design that would allow for the implementation and provision of services outside the protected network. In this design, it would be absolutely imperative that rules be enacted to not allow the untrusted host to access the internal network. Security of the bastion host machine would be accomplished on the machine itself, and only minimal and absolutely necessary services would be enabled or installed on that machine. In this design, we might be providing a Web presence that did not involve e-commerce or the necessity to dynamically update content. This design would not be used for provision of virtual private network (VPN) connections, FTP services, or other services that required other content updates to be performed regularly.

Figure 3.4: Basic Network, Single Firewall and Bastion Host (Untrusted Host)

Figure 3.5 shows a basic DMZ structure. In this design, the bastion host is partially protected by the firewall. Rather than the full exposure that would result to the bastion host in Figure 3.4, this setup would allow us to specify that the bastion host in Figure 3.5 could be allowed full outbound connection, but the firewall could be configured to allow only port 80 traffic inbound to the bastion host (assuming it was a Web server) or others as necessary for connection from outside. This design would allow connection from the internal network to the bastion host if necessary. This design would potentially allow updating of Web server content from the internal network if allowed by firewall rule, which could allow traffic to and from the bastion host on specific ports as designated. (There is more on that topic later in the chapter.)

Figure 3.5: A Basic Firewall with a DMZ

Figure 3.6 shows a generic dual-firewall DMZ configuration. In this arrangement, the bastion host can be protected from the outside and allowed to connect to or from the internal network. In this arrangement, like the conditions in Figure 3.5, flow can be controlled to and from both of the networks away from the DMZ. This configuration and method is more likely to be used if more than one bastion host is needed for the operations or services being provided.

Figure 3.6: A Dual Firewall with a DMZ

For example, Figure 3.7 shows a multiple DMZ environment with Web servers, e-mail relays, and FTP servers on the first DMZ leg (DMZ 1), and services such as VPN and dial-in user access on a second DMZ leg (DMZ 2). This setup separates the functions of the DMZs. DMZ 1 supports services that are publicly available over the Internet, such as the company's Web site. DMZ 2 supports remote users accessing resources on the internal LAN via a dial-in or VPN. By making remote users traverse the firewall, we make the internal LAN environment secure because rules can be set up to restrict remote user access. Adding DMZ legs helps keep the firewall rule sets manageable, especially when each DMZ has different access requirements. It also isolates any errors in configuration because a change on an ACL for one DMZ will not affect the ACL of another DMZ interface. You can add redundancy by adding a secondary firewall, similar to the redundant traditional "three-legged'' firewall design.

Figure 3.7: Multi-DMZ Infrastructure

The previous designs are ideal for standard, multipurpose DMZ environments, but the internal/external firewall design (see Figure 3.8) is intended for the specific purpose of supporting an e-commerce site for which various levels of security are required. Large e-commerce sites separate the servers' functions into three components, consisting of a Web server cluster, an application server cluster, and a database cluster, which is most commonly known as a three-tier design. In this design, Internet users accessing an e-commerce site only interact with the Web servers on DMZ 1. The job of the Web server is to be the front-end GUI for the e-commerce site. The Web servers will in turn call upon the application servers on DMZ 2 to provide content. The application server's job is to collect the information the user is requesting and provide content back to the Web server for the user to view.

Figure 3.8: An Internal/External Firewall Sandwich

The application server requests information by making SQL calls to the database servers on DMZ 3, which houses the site's data. Each component has different security requirements, which only allows necessary communication between DMZ 1, 2, and 3. The external firewall will only allow users to access the Web site on DMZ 1 via HTTP or HTTPS (SSL-enabled HTTP). The user community will not need to access any other part of the site, because the Web server will serve all the necessary content to the users; therefore, access is restricted to DMZ 1. The external firewall will allow the Web servers to make requests only to the application servers on DMZ 2 for content. DMZ 2 is located between the internal and external firewall sets with a Layer 3 switch acting as the default gateway for DMZ 2 as well as routing traffic though this environment. The internal firewall only allows the application servers to send SQL requests to the database servers located on DMZ 3. The internal firewall also allows administrators on the internal LAN to manage the e-commerce environment. For simplicity, Figure 3.8 does not show redundancy, but the internal and external firewalls can be set up with failover. With the layered security approach, this solution provides a highly scalable and secure design that makes it difficult for hackers to compromise.

Traffic Flow Concepts

Now that we've had a quick tour of some generic designs, let's take a look at the way network communications traffic typically flows through them. Be sure to note the differences between the levels and the flow of traffic and protections offered in each.

Figure 3.9 illustrates the flow pattern for information through a basic single-firewall setup. This type of traffic control can be achieved through hardware or software and is the basis for familiar products such as Internet Connection Sharing (ICS) and the NAT functionality provided by digital subscriber line (DSL) and cable modems used for connection to the Internet. Note that flow is unrestricted outbound, but the basic configuration will drop all inbound connections that did not originate from the internal network.

Figure 3.9: Basic Single-Firewall Flow

Figure 3.10 reviews the traffic flow in a network containing a bastion host and a single firewall. This network configuration does not produce a DMZ; the protection of the bastion host is configured individually on the host and requires extreme care in setup. Inbound traffic from the untrusted network or the bastion host is dropped at the firewall, providing protection to the internal network. Outbound traffic from the internal network is allowed.

Figure 3.10: A Basic Firewall with Bastion Host Flow

Figure 3.11 shows the patterns of traffic as we implement a DMZ design. In this form, inbound traffic flows through to the bastion host if allowed through the firewall and is dropped if destined for the internal network. Two-way traffic is permitted as specified between the internal network and the bastion host, and outbound traffic from the internal network flows through the firewall and out, generally without restriction.

Figure 3.11: A Basic Single Firewall with DMZ Flow

Figure 3.12 contains a more complex path of flow for information but provides the most capability in these basic designs to allow for configuration and provision of services to the outside. In this case, we have truly established a DMZ, separated and protected from both the internal and external networks. This type of configuration is used quite often when there is a need to provide more than one type of service to the public or outside world, such as e-mail, Web servers, DNS, and so forth. Traffic to the bastion host can be allowed or denied as necessary from both the external and internal networks, and incoming traffic to the internal network can be dropped at the external firewall. Outbound traffic from the internal network can be allowed or restricted either to the bastion host (DMZ network) or the external network.

Figure 3.12: A Dual Firewall with DMZ Flow

As you can see, there is a great amount of flexibility in the design and function of your protection mechanisms. In the sections that follow, we expand further on conditions for the use of different configurations and on the planning that it done to implement them.

Networks with and without DMZs

As we pursue our discussions about the creation of DMZ structures, it is appropriate to also take a look at the reasoning behind the various structures of the DMZ and when and where we'd want to implement a DMZ or perhaps use some other alternative.

During our preview of the concepts of DMZs, we saw some examples of potential design for network protection and access. Your design may incorporate any or all of these types of configuration, depending on your organization's needs; for example, a simple firewall configuration that may occur in the case of a home network installation or perhaps with a small business environment that is isolated from the Internet and does not share information or needs to provide services or information to outside customers or partners. This design would be suitable under these conditions, provided configuration is correct and monitored for change.

In the network design where a bastion host is located outside the firewall, the bastion host must be stripped of all unnecessary functionality and services and protected locally with appropriate file permissions and access control mechanisms. This design would be used when an organization needs to provide minimal services to an external network, such as a Web server. Access to the internal network from the bastion host is generally not allowed, because this host is subject to compromise.

A screened subnet incorporates the first of the actual DMZ designs. In this type of design, the firewall controls the flow of information from network to network and provides more protection to the bastion host from external flows. This design might be used when it is necessary to be able to regularly update the content of a Web server, or provide a front end for mail services or other services that need contact from both the internal and external networks. Although better for security purposes than Figure 3.2, this design still produces an untrusted relationship in the bastion host in relation to the internal network.

In the next section, we profile some of the advantages and disadvantages of the common approaches to DMZ architecture and provide a checklist to help you to make a decision about the appropriate use (or not) of the DMZ for protection.

Pros and Cons of DMZ Basic Designs

Table 3.2 details the advantages and disadvantages of the various types of basic design discussed in the preceding section.