The requirements for building a De-Militarized Zone (DMZ) would not be considered onerous by most enterprises. Essentially all that is required from a hardware perspective is a three-legged firewall, a capability that virtually all current enterprise-class firewalls have. The challenge is determining which servers should reside in the DMZ, what traffic should be allowed through the firewall, and how to monitor for and protect against potential security breaches.
Network Configuration
The network configuration will be dependent on how many servers will be on the DMZ segment. Examples of network routing and configuration include:
- Direct public IP addresses. This option would be used when the enterprise has been assigned enough public IP addresses by its ISP or regional Internet number registry to give each server in the DMZ a public IP address. For instance, if there are five hosts in the DMZ, a /29 Classless Inter-Domain Routing (CIDR) block of eight public IP addresses would be required (one for the network, one for the gateway, five for hosts, and one for broadcast).
- Network and Port Address Translation (NAT/PAT) port forwarding. This option is appropriate for enterprises that only have one public IP address. NAT translates a request from the public IP address to a private IP address on a given port. For example, if a request comes in for port 80, the router says "I'm supposed to forward that port request to this private IP address in the DMZ." PAT translates an external port to a different internal port, and vice versa. For instance, a public Web server will receive requests on port 80, but because it is on a private subnet, the public Internet cannot reach it. When a request comes into the router, a PAT translation will forward that traffic to the port assigned to the server on the DMZ subnet (let's say port 8080). NAT port forwarding is much more commonly used today than PAT. The limitation of NAT and PAT is that only a single host on each port is supported per public IP address (i.e. only a single public Web server would be supported per public IP in this configuration).
Using direct public IP addresses is the simplest option, and certainly the most scalable. The only caveat is that the enterprise's ISP must be able to provide enough public IP space to support the number of servers needed in the DMZ.
Firewall Configuration
The diagram below shows that the Internet, or external network router, is considered completely untrusted, the DMZ is considered semi-trusted because it is filtered, and the internal network is trusted because it is, theoretically, completely isolated from the untrusted Internet and semi-trusted DMZ.
Figure 1. Basic Network Diagram with a DMZ
Source: Info-Tech Research Group
The firewall rules will vary somewhat for each enterprise depending on policies, but the basic rules for each segment are:
- Trusted network. Deny all ingress (incoming) requests. Do not allow any device in the internal trusted network to accept unsolicited connections from the public Internet. Egress (outgoing) requests should be limited to only those required for internal applications that require connectivity to the outside world. For instance, port 80 (HTTP) and port 443 (HTTPS) will need to be open for outgoing requests for most users. For more details refer to the Info-Tech Advisor research note, "Egress Filtering Contains Relay Attacks."
- Semi-trusted network. Allow ingress requests for only the ports and services required. For instance, a Web server requires port 80, a secure Web server requires port 443, an FTP server requires port 21, an SMTP server requires port 25, and a DNS server requires port 53. For egress requests, limit DMZ host requests much like on the trusted network. Only allow outgoing requests for ports or services necessary. This way, if a DMZ machine is compromised it cannot be used as a "bot" to participate in hacking or denial of service attacks.
- Untrusted segment. All traffic is allowed on the untrusted segment, but it is a good idea to implement an IDS sensor at the Internet/external border router to detect and alarm on suspicious or threatening network traffic. For more details on IDS sensor deployment, refer to the Info-Tech Advisor research note, "Layering Fine Tunes Intrusion Detection."
Recommendations
Building a secure DMZ would rank fairly low in terms of complexity, effort, and cost for most enterprises, but very high in terms of necessity. By following these simple rules, public facing servers can be isolated from the internal network and at least partially protected from the public Internet.
- Identify the servers that need to be accessed externally. Only place servers in the DMZ that need to be accessed from the Internet. For instance, Web, SMTP, FTP, DNS, VPN, and Webmail servers should reside in the DMZ. Any servers that contain proprietary data, customer data, or otherwise sensitive information should reside on the trusted internal network.
- Pick a network architecture. If there is sufficient public IP space to support the number of servers in the DMZ, then it's best to give each DMZ server a public IP address. If not, then decide between PAT or NAT port forwarding. NAT port forwarding will be easier to implement, and some firewalls have the ability to port forward to multiple private IP addresses for load balancing.
- Lock down the segments. Firewall rules for the trusted network must be very strict, particularly for ingress traffic. Follow the "deny all" rule for the trusted network and make exceptions based on policy for egress traffic. Only open the ports and services necessary for ingress on the DMZ segment, and treat egress traffic like the trusted network. Finally, put an IDS sensor at the gateway for the untrusted segment to ensure that threatening traffic is identified and stopped before it can do damage.
Bottom Line
A DMZ on the corporate network is a virtual necessity for enterprises. Building a DMZ is relatively easy to do, but ensuring it is done properly and securely requires some thought and planning. Take the time to plan and implement a secure DMZ on the enterprise network.
