DMZ Design Fundamentals | The Best Damn Firewall Book Period

DMZ design, like security design, is always a work in progress. As in security planning and analysis, we find that a DMZ design carries great flexibility and change potential to keep the protection levels we put in place in an effective state. The ongoing work is required so that the system's security is always as high as we can make it within the constraints of time and budget, while still allowing appropriate users and visitors to access the information and services we provide for their use. You will find that the time and funds spent in the design process and preparation for the implementation are very good investments if the process is focused and effective; this will lead to a high level of success and a good level of protection for the network you are protecting. In this section of the chapter, we explore the fundamentals of the design process. We incorporate the information we discussed in relation to security and traffic flow to make decisions about how our initial design should look. Additionally, we'll build on that information and review some other areas of concern that could affect the way we design our DMZ structure.

Note

In this section, we look at design of a DMZ from a logical point of view. Physical design and configuration are covered in following chapters, based on the firewall solution you are interested in deploying.

Why Design Is So Important

Design of the DMZ is critically important to the overall protection of your internal network—and the success of your firewall and DMZ deployment. The DMZ design can incorporate sections that isolate incoming VPN traffic, Web traffic, partner connections, employee connections, and public access to information provided by your organization. Design of the DMZ structure throughout the organization can protect internal resources from internal attack. As we discussed in the security section, it has been well documented that much of the risk of data loss, corruption, and breach actually exists inside the network perimeter. Our tendency is to protect assets from external harm but to disregard the dangers that come from our own internal equipment, policies, and employees.

These attacks or disruptions do not arise solely from disgruntled employees, either. Many of the most damaging conditions that occur are because of inadvertent mistakes made by well-intentioned employees. Each and all of these entry points is a potential source of loss for your organization and ultimately can provide an attack point to defeat your other defenses.

Additionally, the design of your DMZ will allow you to implement a multilayered approach to securing your resources that does not leave a single point of failure in your plan. This minimizes the problems and loss of protection that can occur because of misconfiguration of rule sets or ACL lists, as well as reducing the problems that can occur due to hardware configuration errors. In the last chapters of this book, we look at how to mitigate risk through testing of your network infrastructure to make sure your firewalls, routers, switches, and hosts are thoroughly hardened so that when you do deploy your DMZ segment, you can see for yourself that it is in fact secure from both internal as well as external threats.

Putting It All Together: A Business Case Study

If a DMZ is correctly planned and designed, it will make simple the tasks of implementing, maintaining, and supporting the DMZ infrastructure. It is important to note that a DMZ cannot be properly designed without a clear vision of what the DMZ will support. Will the DMZ environment contain a handful of servers that provide the enterprise with basic services, and therefore does not require much performance or resiliency? Or will the DMZ environment contain major services that the enterprise needs to be productive and profitable and therefore will need to be in operation at all times? Alternatively, will it be somewhere between these two scenarios? There is only one way to determine the category your DMZ infrastructure will fit into: You need to understand the business, the role the DMZ will play, the type of traffic the DMZ will support, the performance required, and plans for future growth.

As the network architect for the company, you are given the task of supplying the infrastructure to support the new Web site. The company already has Internet connectivity via a broadband connection, and you are protecting your network using a low-end firewall that was easy to install and worked well but does not have the ability to support a DMZ. Now you realize that you must upgrade the entire Internet infrastructure in order to host the new Web site. It is now time to gather the information and requirements so you can design and build a DMZ infrastructure that will be able to support the new Web site for its launch and into the future.

You need to begin gathering information, starting with the facts and requirements:

The facts are that the company is making a strategic move to offer its customers a new method to purchase auto parts as well as to attract new customers.
The site is important to the growth of the business.
The Web site will start out small but could grow as sales over the Internet increase.
The site will be a scalable server environment with a single Web/application server and a database server.
A DMZ will need to be built on site to support the new web site.
The infrastructure currently in place is not capable of supporting the new Web site.
The site is estimated to reach 10,000 hits and 1000 transactions a day at first, and then grow steadily.

You next ask questions so you can be informed of data that was missing so you can move on to designing a solution:

How much Internet bandwidth is required to support the site?
What kind of security is needed? Will there be a need for both Web traffic and SSL traffic?
Does the site require high availability?
What are the connectivity requirements among the internal network, the Web/application server, and the database server?
What is the budget for the DMZ infrastructure?

After you asked the questions, the developers and business managers come back to you with their answers. They tell you that since the site will only receive 10,000 hits and 1000 transactions a day, they initially need two T1s; as the site grows, they will add bandwidth. Since the site will be processing credit card transactions, both Web traffic (TCP port 80) and SSL (TCP port 443) need to be allowed to access the Web/application server from the Internet. The database should only be accessed by the internal LAN and should respond to Web/application server requests for information.

All Web servers and switches are 100Mbps full-duplex capable devices. Even though the servers can be a single point of failure, the DMZ infrastructure should be built with redundancy. The DMZ infrastructure should be built with scalability in mind, with close attention to the budget—in other words, do not over-engineer the infrastructure.

From this information, you can now start to develop your solution. Analyzing the requirements, you decide that the multileg DMZ with redundant firewalls offers you the most secure and scalable solution that fits your budget. The multileg DMZ allows you to separate the Web/application server into separate DMZs to allow for greater security.

DMZ 1 will contain the Web/application server, and DMZ 2 will contain the database servers. Because users will only access the Web/application server, the firewall rules will be configured so it only accesses the server on DMZ 1 via the Web port (TCP port 80) and SSL port (TCP port 443). DMZ 2 will allow no connectivity from the Internet; it will only respond to requests made for data by the Web/application server or by the internal LAN for management. Separating the Web/application server and the database servers into different DMZs allows for greater security in the event the Web/application server is compromised by an intruder. Since the Web/application server is directly accessible by the Internet, it is always the most vulnerable. Furthermore, the design allows for the addition of a redundant firewall that will take over for the primary should the primary go offline.

Designing End-to-End Security for Data Transmission between Hosts on the Network

Proper DMZ design, in conjunction with the security policy and plan developed previously, allows for end-to-end protection of the information being transmitted on the network. The importance of this capability is explored more fully later in the chapter, when we review some of the security problems inherent in the current implementation of TCP/IPv4 and the transmission of data. The use of one or more of the many firewall products or appliances currently available will most often afford the opportunity not only to block or filter specific protocols but also to protect the data as it is being transmitted. This protection may take the form of encryption and can use the available transports to protect data as well. Additionally, proper use of the technologies available within this design can provide for the necessary functions previously detailed in the concepts of AAA and CIA, using the multilayer approach to protection that we discussed in earlier sections. This need to provide end-to-end security requires that we are conversant with and remember basic network traffic patterns and protocols. The next few sections help remind us about these and further illustrate the need to design the DMZ with this capability in mind.

Traffic Flow and Protocol Fundamentals

Another of the benefits of using a DMZ design that includes one or more firewalls is the opportunity to control traffic flow into and out of the DMZ much more cohesively and with much more granularity and flexibility. When the firewall product in use (either hardware or software) is a product designed above the home-use level, the capability usually exists to control traffic that is flowing in and out of the network or DMZ through packet filtering based on port, and often to allow or deny the use of entire protocols. For example, the rule set might include a statement that blocks communication via ICMP, which would block protocol 1. A statement that allowed IPsec traffic where it was desired to allow traffic using ESP or AH would be written allowing protocol 50 for ESP or 51 for AH. (For a listing of the protocol IDs, visit www.iana.org/assignments/protocol-numbers.) Remember that like the rule of security that follows the principle of least privilege, we must include in our design the capability to allow only absolutely necessary traffic into and out of the various portions of the DMZ structure.

DMZ Protocols

Protocol use within a DMZ environment is always problematic. We should be well aware of the potential risks associated with protocol use in various implementations and those that are frequently and actively attacked because of the vulnerabilities that exist. Table 3.3 briefly overviews some of the known issues with various protocols. This table is not intended to be all-inclusive; rather, it is indicative of the fact that the DMZ designer must be aware of these limitations when designing a plan for DMZ structure and access both into and out of the DMZ.

Table 3.3: Protocols with Known Weaknesses
Protocol	Basic Weakness
Asynchronous Transfer	No authentication or encryption, subject to spoofing and _Mode (ATM)interception
Internetwork Packet Exchange (IPX)	Designed for LAN use, doesn't scale well for wide area network (WAN) operations, high bandwidth usage with SAP broadcasts, aging protocol
Internet Protocol (IP)	No default data protection of packets, subject to many attacks, needed for connection to Internet
Kerberos	Vulnerable to buffer overflow attacks, replay, and spoofing to gain privilege and discover passwords, allowing potential for breach of service
Lightweight Directory Access Protocol (LDAP)	Some implementations are subject to buffer overflow and DoS attacks, with possibility of privilege elevation
Simple Network Management Protocol (SNMP)	DoS and buffer overflow attacks are possible, as are security risks posed by administrators who leave the community names and other information in default configurations; some conditions can result in privilege escalation and compromise
Secure Shell (SSH)	Privilege escalation, system compromise when code run under SSH credential, DoS attacks

Designing for Protection in Relation to the Inherent Flaws of TCP/IPv4

The current implementation of TCP/IPv4 contains a number of well-documented flaws that affect the design of both your security plan and your DMZ. Some of these problems were corrected in IPv6, but since implementation of this technology isn't on the immediate horizon, we must accommodate the weaknesses of the existing protocols when implementing the design of our DMZ. We must therefore plan for certain known problems:

Data, including passwords not protected by the operating system, are sent in clear-text in TCP/IP packets
SYN attacks, a DoS condition resulting from overflow of the wait buffer
IP spoofing, allowing the attacker to pretend it is another host
Sequence guessing, allowing reassembly or delivery of forged packets
Connection hijacking, allowing man-in-the-middle attacks
Lack of authentication capability in the protocol

You can find a good discussion of the problems with TCP/IPv4 and a more complete discussion of the flaws and improvements made in TCP/IPv6 at www.linuxsecurity.com/resource_files/documentation/tcpip-security.html. The design that we create for our DMZ structure will accommodate the weaknesses of the TCP/IP protocol and will provide the protection that is needed to stymie these types of attacks and their resulting potential for breach. To accomplish that goal, as we design we need to consider the various problems and design the working protections into the configuration of rules and ACL settings and consider the use of other protocols such as IPsec and L2TP to protect the data on the wire.

Public and Private IP Addressing

One of the primary reasons why the DMZ concepts have been so useful is that network administrators have a greatly expanded capability to use public and private addressing. As you will recall, the initial TCP/IPv4 implementations were based on class, with default subnet masks that limited to some degree the ability of network administrators to achieve true flexibility in their network designs. With the advent of classless addressing and improvements provided with the acceptance of that concept, much greater utilization has been made of functions such as NAT to provide addressing for the internal network without exposing that network to the dangers of the public network. The DMZ design must incorporate the methods and equipment being used for address translation and routing, and it becomes a method of hiding internal addresses from unwanted contact.

We also must plan for and use the ability to subnet within the private IP addressing ranges, which are shown in Table 3.4.

Table 3.4: Private IP Address Ranges
Private IP Range	CIDR Mask	Decimal Mask
10.0.0.0–10.255.255.255	/8	255.0.0.0
172.16.0.0–172.31.255.255	/16	255.255.255.0
192.168.0.0–192.168.255.255	/24	255.255.255.0

This allows us much greater flexibility in the segregation of the DMZ and assuring that the network addressing and contact between the protected network, the buffer (DMZ), and the outside world are more difficult for would-be attackers to penetrate.

Ports

Ports used in network communication become an extremely important tool in our ability to filter access levels and establish ACL functions on devices and in software implementations used to protect our assets. Recall that ports 0 through 1023 are reserved for specific uses and that all other ports are functionally available for use by applications. Registered ports include those from 1024 through 49151, and dynamic and/or private ports (used by applications for communication and session maintenance) are those from 49152 through 65535. The entire port list can be found at www.iana.org/port-numbers.

That means, of course, that the DMZ design must incorporate rules that block all traffic that is not necessary for the function of the DMZ or communications that must be carried through that area. Generally, this involves creating a rule set for the ACL that restricts or blocks all unused ports on a per-protocol basis to assure that the traffic is actually stopped. These rules become an integral part of the DMZ defense. The design is often started from two "all or nothing" configurations: all ports open, closing as problems occur (bad), and all ports closed, opening as required (good, but requiring a great deal of administration and learning in a new network that has not been fully documented). Either method can be considered in your design, although the latter provides much more security as you begin your quest to shut down intrusion.

The SANS Institute (www.sans.org) recommends the following port actions at a minimum as you design your DMZ and firewall blocking rules from external networks, as shown in Table 3.5. (The table is adapted from Appendix A of the SANS Top 20 list, which can be found at www.sans.org/top20.)

Table 3.5: Common Ports to Block
Service Type	TCP Port(s)	UDP Port(s)
Login Services	Telnet: 23, ; SSH: 22, ; FTP: 21, ; NetBIOS: f139, ; rlogin: 512, _513, 514	N/A
RPC and NFS	Portmap/rpcbind: 111, NFS: 2049, ; lockd: 4045	Portmap/rpcbind: 111, ; NFS: 2049, ; lockd: 4045
NetBIOS in Windows NT	135, 139, 445(W2K and XP)and XP)	135, 137, 138, 445 (W2K and W2K and XP
X Windows	6000 through 6255	N/A
Naming Services	DNS: Block zone transfers (TCP 53) except from external secondaries
LDAP: 389	DNS: Block UDP 53 to all machines that are not DNS servers
LDAP: 389
Mail	SMTP: 25 to all machines that are not external mail relays
POP: 109, 110
IMAP: 143	N/A
Web	HTTP: 80; SSL: 443, except to external Web servers. Also consider common high-order HTTP port choices, such as 8000, 8080, 8888	N/A
Small Services	Ports below 20, time: 37	Ports below 20, ; time: 37
Miscellaneous	Finger: 79; NNTP: 119; LPD: 515; SNMP: 161, 162; BGP: 179: ; SOCKS: 1080	TFTP: 69; NTP: 123; syslog: 514; SNMP: 161, 162
ICMP	Blocks incoming echo request (ping and traceroute), outgoing echo replies, time exceeded, and destination unreachable messages, except "packet too big" messages (Type 3, Code 4)	Note: This setting will block known malicious uses, but it also will restrict your legitimate use of the ICMP echo request

Using Firewalls to Protect Network Resources

Firewalls have been and continue to be an integral part in the planning process for DMZ deployments. The design can include any or all of the basic designs we looked at earlier in the chapter and may very well incorporate multiple types of configuration, depending on your organization's needs to protect data and resources from different threat areas. Firewalls are not the only component of the design that is important, but they do play a major part in allowing the administrator to control traffic more completely, thus providing a higher level of protection.

Part of the design process includes evaluating and checking the performance of different hardware- and software-based firewall products. This book discusses some of the most-used technologies in later chapters, such as Check Point and Check Point NG, PIX, Nokia, and Microsoft's ISA Server. Additionally, firewall considerations are explored during discussions of protection of wireless networks and methods of protecting networks using Sun and Microsoft network operating system (NOS) software.

Using Screened Subnets to Protect Network Resources

As you proceed to a more advance design for your DMZ, conditions could drive a decision to employ screened subnets for protection or provision of services. The screened subnet, in some designs, actually becomes synonymous with DMZ in usage. However, the screened subnet is actually a security enhanced version of the multihomed screened host configurations that were used in the past. It involves the use of more hardware but provides a more secure basis for configuration and blocking unauthorized access.

The screened subnet that we looked at earlier in the chapter can be configured in a number of different configurations dependent on need. The simplest of the constructions involves a multiple-interface firewall with the capability to filter traffic to more than one network. Although simpler, this design might not be appropriate to use in your environment if you plan to offer services such as Web, e-mail, FTP, or VPN connections from the public network to your private network. In these situations, a good case could be made for the dual-firewall approach, perhaps with multiple screened subnets that provide different services or access based on some criteria that you have identified during your planning process. Certainly, if offering services that involve e-commerce or access to confidential records (such as being HIPAA compliant in an enterprise involved with any type of patient records), your plan will most likely need to include multiple screened subnets, following the earlier suggestions that a multilayer approach be used to restrict access and retard attacks from outside.

Securing Public Access to a Screened Subnet

Public access to screened subnets is secured and restricted through a multilayer process, using a screening router to begin providing protection and a firewall in the next layer to protect the access point coming into the screened subnet. Figure 3.13 shows a possible configuration to begin this protection process.

click to expand
Figure 3.13: A Basic Screened Subnet

In this configuration, it is possible to limit the inbound traffic initially by configuring a rule set on the router; this piece might be provided by an Internet service provider (ISP), for example. Further levels of security can be developed as needed in your plan to protect assets on the screened subnet by firewall rule sets and hardening of the server providing services. Additionally, this design could be expanded or used for services or administration of screened subnets, providing greater security to the internal network as well.

Know What You Want to Secure First

As you begin your DMZ design process, you must first be clear about what your design is intended for. A design that is only intended to superficially limit internal users' access to the Internet, for example, requires much less planning and design work than a system protecting resources from multiple access points or providing multiple services to the public network or users from remote locations. An appropriate path to follow for your predesign path might look like this:

Perform baseline security analysis of existing infrastructure, including OS and application analysis
Perform baseline network mapping and performance monitoring
Identify risk to resources and appropriate mitigation processes
Identify potential security threats, both external and internal
Identify needed access points from external sources
- Public networks
- VPN access
- Extranets
- Remote access services
Identify critical services
Plan your DMZ

Traffic and Security Risks

After beginning to research the necessary components for designing your protection plan, you will reach a point at which you are trying to assess the actual risks to security from which you are trying to protect your enterprise network. One of the first tools you might consider in this part of your evaluation is the SANS Top 20 list of the current most critical vulnerabilities to find out if there is something that you are not aware of. You can view this list at www.sans.org/top20/; it is updated frequently. This information can help you to at least begin to identify some of the risks involved and then to design a more effective plan to secure what you need to secure.

As we continue with our overview of DMZ design principles, we also need to discuss the management of resources and the challenges that occur in designing for administration and control of equipment and resources that may be located in the DMZ. The following sections detail a number of the areas that we must be aware of during our consideration of the design and its implementation.

Application Servers in the DMZ

Application server placement in the DMZ must be designed with tight control in mind. As in other screened subnet configurations, the basic security of the operating system must first be assured on the local machine, with all applicable patches and service packs applied and unused services disabled or removed if possible.

We spend a great deal of time in this book covering the hardening of your systems (Windows 2000, Sun Solaris, and the like) within the DMZ. Additionally, functionality of the application servers located in the DMZ should be limited to specific tasks that do not involve critical corporate data or information. Therefore, although it is acceptable to place a Web server in the DMZ with a supporting database server, neither of those servers should contain confidential or critical corporate information, because they are still located in an area in which they are considered untrusted.

Critical or confidential information should not be accessible from or stored in the DMZ. For example, as discussed in the following section, it is not acceptable to store any type of internal network authentication information on machines in the DMZ. Likewise, front-end servers or application proxy servers can be placed in the DMZ for other needs, such as an e-mail server front end or a DNS forwarder. In these instances, neither the e-mail front end nor the DNS server should store any information about the internal network or allow general communication to pass unchecked to or from the internal network. Traffic to these servers from the internal network should pass through a firewall restricting traffic to individual machines in both directions using specific port and address information.

Domain Controllers in the DMZ

Domain controllers for Windows networks or other directory services authentication servers should never have those services located within the DMZ if it's possible to keep them out. It is feasible in some configurations to provide a front end to these critical servers from within the DMZ, but it is not recommended, because compromise of the bastion host being allowed to communicate with the internal network through the firewall while requesting service could lead to compromise of the entire internal system. Access to your internal network that requires authentication should instead be handled in your design by the use of VPN solutions, including RADIUS and TACACS/TACACS+, discussed in the next section. It is possible, however, that domain controllers need to be placed within the DMZ depending on what services you plan to provide in the DMZ. For example, if you were running a cluster that is highly available from the Internet on Windows 2000 servers, the cluster will not operate correctly without a domain controller present. For that reason, you have to accurately assess what you will need and analyze how to implement it and secure it.

RADIUS-Based Authentication Servers in the DMZ

Remote Authentication Dial-In User Service (RADIUS) servers, by definition and usage, are required to have full access to the authentication information provided by the Directory Services system in the enterprise, whether Windows, Novell, UNIX, Sun, or another OS. For this reason, the RADIUS server must be fully protected from attack and patched completely to avoid DoS conditions such as those detailed by CERT in advisories issued in 2002. The preferred option would have the RADIUS server located in the internal network, with proxied requests coming from a Routing and Remote Access Services (RRAS) server and restricted communication that would be allowed through the firewall to the RADIUS server only from the specified RRAS servers. Additionally, it would make sense to plan for the use of IPsec to further protect that traffic. Regardless, understand that you will need to analyze the need and deploy it based on a proper design that provides the service that is needed but still remains secure.

VPN DMZ Design Concepts

VPN usage has grown during the past few years. Many organizations embraced the possibility of VPN use as a method to communicate securely from remote offices. This led to a surge of connectivity that was requested in order to allow home "teleworkers" to perform their job functions without entering the secured environs of the actual workplace and its network.

A number of changes have been implemented in VPN technology in the recent past, and these have modified the thought process that we must undertake as we design our DMZ infrastructure. To begin with, VPN solutions should be created in a separate DMZ space, away from the other parts of the Internet-facing infrastructure, as well as your back-end private LAN. The VPN technologies now may incorporate the capability to enter your network space through public switched telephone network (PSTN) connections, Frame Relay connections, modem banks, and the public Internet as well as dedicated connections from customers and business partners that may use any of these access methods. Each of these connection types must be included in the plan, and entry points must be carefully controlled to allow the required access and protection of information while not allowing a back-door entry to our internal networks.

A number of these plans are discussed in subsequent chapters of this book as different firewall configurations and designs are considered and discussed. When we're looking at the possibilities for VPN implementation and protection, it is extremely important to use all potential security tools available, including IPsec and its authentication and encryption possibilities. It is also important to evaluate the actual network design, in order to use RFC1918 (private) addressing in the internal network and properly secure the addressing within the VPN, which should be registered addresses. This is called NAT—Network Address Translation.

Private addressing is one of the basic features of most firewalls. NAT converts private, internal IP addresses into publicly routable addresses. You might want to translate or to NAT (using the term as a verb to describe this process) your internal addresses because they are nonroutable private addresses or to discourage attacks from the Internet. RFC1918 lists the addresses that are available for private use on the internal network. The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks:

10.0.0.0 through 10.255.255.255 (10 /8 prefix)
172.16.0.0 through 172.31.255.255 (172.16 /12 prefix)
192.168.0.0 through 192.168.255.255 (192.168 /16 prefix)

Note

You can learn more about RFC1918 by visiting the RFC document online: www.cis.ohio-state.edu/cgi-bin/rfc/rfc1918.html

If you are using these addresses on your internal LAN and clients on the internal LAN need to communicate to Internet resources, you need to NAT these addresses to public addresses in order to be routed throughout the Internet. Public addresses are typically IP addresses assigned to your organization by the Network Information Center (NIC) or by your ISP.

The problem facing IPv4 is that the public address pool has been depleted, so network administrators may no longer be able to assign public addresses to all clients on their internal LANs and have them access Internet resources without the use of NAT. Therefore, administrators are forced to assign private addresses to internal clients and use their allocated public addresses for NAT address pools and for services provided by the DMZ directly accessible by the Internet, such as Web and e-mail relays. NAT makes it possible for a small number of public IP addresses to provide Internet connectivity for a large range of hosts. NAT can provide a static one-to-one IP mapping between private and public addresses or dynamically map a large number of internal private addresses to a pool of public addresses. This can extend a network with only one IP address.