DMZ Best Practices

In this paper we present an overview of the work processes that are essential to security in a DMZ environment. We identified 23 specific tasks and one general. You will reach a very high security standard if you perform all of them. However, performing the tasks will lead to high security only if your general design of the DMZ is secure. For this reason the paper starts with a description of a secure DMZ topology.

The DMZs purpose

The area between the Internet and the Intranet is called demilitarized zone (DMZ) if this area is protected against external threats and has only limited access to internal systems. The goal of a DMZ is to limit the impact of a break-in to the systems contained in the DMZ. As such the DMZ separates externally exposed systems from the internal network. If systems in the internal network are open for connections from the Internet then hackers can attack them. Even if a firewall protects the internal network a hacker can still use the intended communication path to the server to attack the system. For example, a firewall protecting a web server will always permit HTTP traffic to reach the web server. Unfortunately many exploits are known that do not require anything else then HTTP traffic to compromise a web server. As a result a publicly available web server should reside in the DMZ. Then, if the web server gets compromised the attack is limited to and contained in the DMZ. Continuing the example it is obvious that if a hacker gained privileges on the web server he can use the web server as a beach head to attack other systems in the DMZ. The more systems he can compromise the more likely it will be that he will finally succeed in breaking through to the internal network. As a result the DMZs design should separate systems that serve different organizations and/or purposes so that the hacker cannot proceed from the penetrated web server to other systems. Administrators of firewall, router, switch, and system need to work closely together to ensure that a successful hacker attack will be unlikely.

Architecture
The architecture of the Intranet Internet connection is the key element that defines the base level of security for the whole company network. If the architecture is in itself insecure then it will be impossible to reach a sufficient security level. The following drawing in figure 1 details what we think is the best and safest topology for the Intranet Internet connection. Of course, your architecture might be different but achieve the same results.

passive c onnec tion pas s iv e connec tion Hub Netw ork Ad apte r Car d Hub

Inne r IDS

Oute r IDS Inne r Scre e ning Route r La ptop INTRANET Com pute r

INTERNET

Oute r S cre e ning Route r

Inte rne t Se rvice Provide r

W e bS e rve r (http) M a ilSe rve r (sm tp)

Fire w a ll DNSSe rve r (dom a in)

FTPSe rve r (ftp)

SM C IDS-Console Log-Se rve r

Se rve r W orksta tion

Figure 1: Ideal DMZ design

CT IC 3, Siemens CERT Siemens AG, 2001 All rights reserved.

29. August 2001 D. Lehmann, Th. Klockow

1/5

However, since above design doesnt scale for large environments figure 2 shows the best practice design for complex DMZs. Apart from the basic elements like screening router and firewall we also included intrusion detection systems (IDS) and a system management network consisting of a specifically configured VLAN and the system management console (SMC) which additionally serves as the central repository for log files.
Laptop INTERNET Outer Screening Router Internet Service Provider
Hub Hub

Firewall

Inner Screening Router Server

INTRANET Computer

passive connection

passive connection

Workstation

VLAN Switch

passive connection on monitor port

Outer IDS

WebServer (http)

MailDNSFTPSMC Server Server Server IDS-Console (smtp) (domain) (ftp) Log-Server

DMZ IDS

Inner IDS

Figure 2: Best practice DMZ topology

The firewall has three network adapter cards (or more, see below). One network adapter card connects the firewall with the screening router that provides the connection to the Internet service provider (ISP). Another network adapter connects to the router that is connected to the internal network. All other network adapter cards connects to VLAN switches. The VLAN switch is the main element of the DMZ and it is important to note that we do not recommend to use a HUB or a simple switch. Using a HUB would allow the WWW server to also see the traffic of the mail server which could lead to disaster if the WWW server was compromised. In this case the incident could hardly be limited to the WWW server. This is also the case if you use simple switch technology because it can not be used to deny traffic from one system to the next. A hacker who penetrated the WWW server could still attack the mail server, for example. As a result we recommend to use a VLAN switch and have different VLANs for different systems. This leads to a configuration where the WWW server is no longer able to talk to any other system in the DMZ. The above described architecture could easily be extended by further separate networks just by adding additional network adapter cards to the firewall and connecting these cards to additional DMZ VLAN switches as depicted in the following drawing.
Laptop INTERNET Outer Screening Router Internet Service Provider Outer IDS
passive connection Hub Hub

Firewall

Inner Screening Router

passive connection

INTRANET Computer

Server Workstation Inner IDS

VLAN Switch

passive connection on monitor port

VLAN Switch

2nd DMZ

WebServer (http)

MailDNSFTPServer Server Server (smtp) (domain) (ftp)

SMC IDS-Console Log-Server

DMZ IDS

Figure 3: DMZ topology with two DMZs CT IC 3, Siemens CERT Siemens AG, 2001 All rights reserved. 29. August 2001 D. Lehmann, Th. Klockow 2/5

The most secure way to modify the configuration of the DMZs system is to push all modifications from a system in the internal network to the target system in the DMZ. This way there wont be any need for the DMZs system to initiate a connection to internal systems. As a result the firewall could block all such connection attempts.

Basic rules for the configuration of the essential security components that build the DMZ
Business needs will have a great influence of what traffic will be permitted through firewall and screening routers. However, some basic rules are fundamental to security and should always be followed.

Inner and outer screening router

Configure it to perform ingress and egress filtering. Ingress filtering filters all incoming packets that cannot originate from the Internet, like packets with a non-routable source network IP address of, e.g., 10.10.10.10. Egress filtering does the same for outgoing packets. block all NETBIOS traffic originating from the Internet (ports 137-139). permit only traffic on those ports that are open by the firewall. This will reduce the load on the firewall. This wont work if you, for example, permit FTP traffic since FTP ports are not static.

have SNMP disabled. If you use TFTP or telnet to communicate with the router or to upload configuration data to the router then make sure that you restrict on the IP address level the devices that are permitted to communicate with the router.

Firewall
Configure it to block incoming ICMP echo requests to all systems on the internal network and to the systems in the DMZ except for those where there is a need that they are highly visible to the Internet like the WWW server. block all other ICMP traffic except ICMP type 3 code 4 (fragmentation needed but DF bit set) which some systems use for path MTU discovery (PMTU-D). See Path 1 MTU Discovery and Filtering ICMP for additional information . deny all connection attempts (both incoming and outgoing) except for those where there is an explicitly defined allow rule. This should be your default rule. only allow incoming traffic to systems that offer the requested service, e.g., permit incoming DNS traffic to DNS servers only. block outgoing traffic that was initiated by a server. Servers respond to queries but dont initiate a communication. Please note that this is not true for FTP, DNS, and mail servers. log all connections (incoming and outgoing, denied and permitted). If this seems not feasible due to high number of connections then at least log all denied connections. block all insecure protocols such as TELNET, FTP. In case you permit FTP then make sure that the FTP server functions as an anonymous FTP server. restrict the DMZs systems to connect to those systems only for which there is a need to communicate. Prior to this, of course, you would have to determine for every system on your side of the firewall with which other systems on the Internet it needs to communicate.

http://www.worldgate.ca/~marcs/mtu/ 29. August 2001 D. Lehmann, Th. Klockow 3/5

CT IC 3, Siemens CERT Siemens AG, 2001 All rights reserved.

block all connection attempts from systems in the DMZ to the internal network. In case you have a configuration where your web server needs to dynamically create pages based on data from a database server use a mirror of the database server and put this mirror in the DMZ. Then the real database server should push all changes to the mirror. This finally results in a staging host configuration where DMZ systems wont need to communicate with internal systems directly. If you need to get data back from the system in the DMZ to systems in the internal network then always prefer a design where the internal system invokes the data transfer (pull design). If this is impossible due to real-time processing demands then dedicate one particular system in the internal network and open up the firewall and screening router so that the system in the DMZ can send data to this particular system in the internal network only. Here it is fundamental that only those ports are open that are absolutely necessary by the application that wants to exchange data. It is best practice that the receiving application runs in a non-privileged environment so that a buffer overflow attack would not lead to a root compromise. Do not use any insecure protocols like TELNET or FTP for communication with firewall. Only use SSH or a vendor supplied firewall management protocol.

DMZ VLAN switch

Configure it to separate all servers in the DMZ from any other system in the DMZ by putting it on its own VLAN. However, the SMC must be able to communicate with all systems. disable the administrator VLAN. Configure and maintain the switch only by using the serial link cable.

Work processes
1. Document the DMZs architecture. In particular document design decisions that lead to your topology. 2. Analyze the tangible and in-tangible impact of a security compromise of your firewall and/or DMZ. 3. Create security checklists for systems of all types in your DMZ, e.g., firewall, router, DNS server, WWW server or customize already available checklists from Siemens CERT, e.g. Windows NT/2000 measure plan, UNIX measure plan, IIS and database server checklists, FTP and DHCP server best practices. 4. Only have a minimum of services installed and running on your systems. 5. Never have one single system serving two different purposes at the same time, e.g., dont use one single system as a mail and WWW server. 6. Never connect a system to the DMZ before you havent applied your security checklists. 7. If you want to connect a test system to the DMZ make sure it is securely configured considering item 2 and 3. 8. Scan all systems on a periodic basis. 9. Verify your firewalls rule set on a periodic basis using a port scanner located in the Internet and a sniffer in the DMZ. Document the results and compare them with your expected results. 10. Define a person that is responsible for the whole Internet Intranet connection. Further for each system nominate a single person that is responsible for the system. Clearly state that this person is in particular responsible when it comes to security. 11. Provide security awareness training to all administrators. 12. Document all accounts on all systems (privilege level, who may access account, why).

CT IC 3, Siemens CERT Siemens AG, 2001 All rights reserved.

29. August 2001 D. Lehmann, Th. Klockow

4/5

13. Document each system (e.g. router, firewall, web server) configuration with respect to OS version, patch level, installed software including version and patch level. 14. Establish a change management process that requires active participation of a security expert. 15. Establish a patch process that makes sure that all systems in the DMZ are always on the highest patch level. 16. Document your firewalls rule set (what is permitted/denied, why, who requested a particular rule). 17. In a written contract operator and customer of the DMZ have to define the technical contact persons of both operator and customer. 18. Permit only systems of the same department in a single DMZ. 19. Document and restrict which systems are permitted to connect to what other systems. 20. Enable logging on all systems. 21. Monitor your systems for attempted break-ins. You might want to use both networkand host-based IDS. 22. Define an escalation process for security incidents. 23. Have a password policy in place that demands strong passwords 24. General rule: You will need a company security policy that all employees/managers have to obey. This security policy must also address how to resolve a conflict between business needs and security considerations/requirements.

CT IC 3, Siemens CERT Siemens AG, 2001 All rights reserved.

29. August 2001 D. Lehmann, Th. Klockow

5/5