dmz - best practices - vsd

CT IC 3, Siemens CERT 29. August 2001 1/5 © Siemens AG, 2001 D. Lehmann, Th. Klockow All rights reserved.

DMZ – Best Practices In this paper we present an overview of the work processes that are es-sential to security in a DMZ environment. We identified 23 specific tasks and one general. You will reach a very high security standard if you per-form 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 DMZ’s 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 ex-ploits 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 sys-tems 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 DMZ’s 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.

Firew all

INTERNET INTRANETOuterScreening

RouterCom puter

W eb-Server(http)

InnerScreening

Router

W orksta tion

InternetServiceProvider

Laptop

Mail-Server(smtp)

FTP-Server

(ftp)DNS-Server

(domain)

OuterIDS

InnerIDS

passiveconnection

passiveconnec tion

Hub Hub

Server

NetworkAdapter Card

SMCIDS-ConsoleLog-Server

Figure 1: Ideal DMZ design


However, since above design doesn’t 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 net-work consisting of a specifically configured VLAN and the system management console (SMC) which additionally serves as the central repository for log files.

Firewall

INTERNET INTRANET

VLANSwitch

OuterScreening

RouterComputer

Web-Server(http)

InnerScreening

Router

Workstation


Laptop

Mail-Server(smtp)

FTP-Server(ftp)

DNS-Server

(domain)


OuterIDS

InnerIDS

passiveconnection

DMZIDS

passiveconnectionon monitor

port

passiveconnection

Hub Hub

Server

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 technol-ogy 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 addi-tional DMZ VLAN switches as depicted in the following drawing.

Firewall

INTERNET INTRANET

VLANSwitch

OuterScreening

RouterComputer

Web-Server(http)

InnerScreening

Router

Workstation


Laptop

Mail-Server(smtp)

FTP-Server

(ftp)

DNS-Server

(domain)


OuterIDS

InnerIDS

passiveconnection

DMZIDS

passiveconnectionon monitor

port

passiveconnection

Hub Hub

Server

VLANSwitch

2nd DMZ

Figure 3: DMZ topology with two DMZs


The most secure way to modify the configuration of the DMZ’s system is to push all modifica-tions from a system in the internal network to the target system in the DMZ. This way there won’t be any need for the DMZ’s system to initiate a connection to internal systems. As a re-sult 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 won’t 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 MTU Discovery and Filtering ICMP” for additional information1.

− 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 don’t 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 DMZ’s 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.

1 http://www.worldgate.ca/~marcs/mtu/


− 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 won’t 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 par-ticular 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 abso-lutely 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 DMZ’s 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.,

don’t use one single system as a mail and WWW server. 6. Never connect a system to the DMZ before you haven’t applied your security check-

lists. 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 firewall’s 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. Fur-ther 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).


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 secu-rity 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 firewall’s 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 network-

and 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 be-tween business needs and security considerations/requirements.

dmz - best practices - vsd

Documents