Ok, so you've decided to create a DMZ to provide a buffer zone between the Internet and your internal corporate network where sensitive resources reside. You've examined the advantages and disadvantages of DMZ designs and decided whether to use a single "three legged" firewall to create your DMZ network, or two back-to-back firewalls sitting on either side of the DMZ. Now you have to decide how to populate your DMZ. That depends, in part, on the type of DMZ you've deployed. This article will go into some specifics of how to deploy a DMZ: which servers and other devices should be placed in the DMZ, and how to monitor DMZ activity.
A computer that runs services accessible to the Internet is sometimes referred to as a bastion host. Others use this term to refer only to hardened systems running firewall services at the Internet edge. Your bastion hosts should be placed on the DMZ, rather than on your internal network, because by either definition they are directly accessible to the Internet.
Best security practice is to put all servers that are accessible to the public in the DMZ. However, this creates an even bigger security dilemma: you don't want to place your corporate Exchange server, for example, "out there." The solution is to create a split configuration.
In a Split Configuration, your mail services are split between servers on the DMZ and the internal network. Your internal mail server will handle e-mail that goes from one computer on the internal network to another internal computer, with no exposure to the Internet. Mail that comes from or is sent to computers outside the internal network over the Internet will be handled by the other half of the team, an SMTP gateway located in the DMZ.
You may be more familiar with this concept in relation to DNS servers. It has become common practice to split your DNS services into an internal zone and an external zone. This allows you to keep DNS information about your internal hosts private, while only the external DNS records are propagated to the Internet. The external DNS zone will only contain information about your public servers.
Another example of a split configuration is your e-commerce system. You can place the front-end server, which will be directly accessible by Internet users, in the DMZ, and place the back-end servers that store sensitive information on the internal network.
What goes in the unauthenticated DMZ
Most of us think of the unauthenticated variety when we think about DMZs. This is a network that's wide open to users from the Internet. Anyone can connect to the servers there, without being required to provide credentials. The servers you place there are "public" ones, and might include the following:
- Web servers that you want to make available to the general public, such as your company's primary Web presence advertising its products or services.
- Your public DNS servers that resolve the names in your domain for users outside your organization to the appropriate IP addresses.
- Public FTP servers on which you provide files to the public (for example, downloads of your product manuals or software drivers to enhance your products).
- Anonymous SMTP relays that forward e-mail from the Internet to your internal mail server(s).
Of course, you can have more than one public service running on a single physical computer. That can be done in one of two ways: two or more services (such as Web services and FTP) can run on the same OS, or you can create separate virtual machines using software such as Microsoft's Virtual PC or VMWare's software for servers running different services.
You may also place a dedicated intrusion detection system/intrusion prevention system (IDS/IPS) in the DMZ to catch attempted attacks. Another option is to place a honeypot in the DMZ, configured to look like a production server that holds information attractive to attackers. The idea is to divert attention from your "real" servers, to track intrusion patterns, and perhaps even to trace intrusion attempts back to the source and learn the identity of the attackers.
What goes in the authenticated DMZ
An authenticated DMZ holds computers that are directly accessible to the Internet, but are not intended for access by the general public. They may be used by your partners, customers or employees who need access from home or while on the road.
Some types of servers that you might want to place in an authenticated DMZ include:
- Web servers that you want to make available across the Internet for selected users.
- FTP servers that you want to make available across the Internet for select users.
- A front end mail server that you want users to be able to access when away from the office in lieu of using VPN to tunnel into the internal network.
- An authenticated SMTP relay server for the use of your employees when they're away from the office.
- SharePoint or other collaboration servers that need to be accessed by project team members outside the corporate network.
The key is that users will be required to provide authentication credentials (username/password or, for greater security, multi-factor authentication such as a smart card or SecurID token). In other words, the firewall won't allow the user into the DMZ until the user authenticates. Once in, users might also be required to authenticate to particular servers.
An authenticated DMZ can be used for creating an extranet. It's a private network and is more secure than the unauthenticated public access DMZ, but because its users may be less trusted than those on the internal network, the internal network is still protected from it by a firewall.
The wireless DMZ
Another important use of the DMZ is to isolate wireless clients from the internal network. Although it's common to connect a wireless LAN (WLAN) directly to the wired network, that poses a security threat because of the inherently more vulnerable nature of wireless communications. Even with standard wireless security measures in place, such as WEP encryption, wireless is not secure, and stronger encryption such as WPA is not supported by all clients and access points.
Segregating the WLAN segment from the wired network allows your organization's users to enjoy the convenience of wireless connectivity while reducing some of the risk to the rest of the network.
A wireless DMZ differs from its typical wired counterpart in that you not only want to protect the internal network from the Internet and DMZ, you also want to protect the DMZ from the Internet. In that respect, the WLAN DMZ functions more like the authenticated DMZ than like a traditional public access DMZ.
To control access to the WLAN DMZ, you can use RADIUS servers to authenticate users using the Extensible Authentication Protocol (EAP), along with port based access controls on the access point.
Securing DMZ Components
You will probably spend a lot of time configuring security on the firewalls and IDS/IPS devices that define and operate in your DMZ, but you should also secure other components that connect the DMZ to other network segments, such as the routers and switches.
It's important to consider where these connectivity devices should be placed in relation to the DMZ segment. You'll need to configure your routers to allow Internet users to connect to the DMZ and to allow internal users to connect to the Internet. You may need to configure Access Control Lists (ACLs) on your routers. Remember that you generally do not want to allow Internet users to connect to the internal network. One way to ensure this is to place a proxy server on the DMZ, and set up internal users to go through the proxy to connect to the Internet.
It's also important to protect your routers' management interfaces to keep hackers from changing the router configurations. Be sure to set strong passwords and use RADIUS or other certificate based authentication for accessing the management console remotely. Be aware of all the ways you can administer the router (Web interface, Telnet, SSH, etc.) and lock them all down. To allow you to manage the router through a Web page, it runs an HTTP server. It is a good security practice to disable the HTTP server, as it can serve as a point of attack.
What about using VLANs to create a DMZ?
The Virtual LAN (VLAN) is a popular way to segment a network, using one switch to create multiple internal LAN segments. The VLAN logically divides the network; however, switches aren't firewalls and should not be relied on for security. Your DMZ should have its own separate switch, as should the internal network and the external network; you should not use VLAN partitioning to create these networks. That's because with a VLAN, all three networks would be connected to the same switch and if that switch is compromised, a hacker would actually reconfigure the VLAN—not a good situation.
If you want to deploy multiple DMZs, you might use VLAN partitioning to separate the DMZs, all of which are connected to the same switch. This is generally accepted practice but it is not as secure as using separate switches.
You can use Cisco's Private VLAN (PVLAN) technology with some of their Catalyst switches to isolate devices on a LAN and prevent the compromise of one device on the DMZ from leading to the compromise of other DMZ devices. For more information about PVLANs with Cisco Catalyst switches, see Cisco's Web site.
Monitoring DMZ activity
The DMZ is created to serve as a buffer zone between the Internet and the corporate internal network, and if you build it, they (the hackers) will almost certainly come. When they do, you want to know about it as quickly as possible. Thus, your next step is to set up an effective method of monitoring the activity that goes on in the DMZ. This is especially true if your DMZ acts as a honeynet.
Many firewalls contain built-in monitoring functionality or it can be added with add-on modules. For example, ISA Server 2000/2004 includes a monitoring configuration node that can be set up to alert you if an intrusion is detected. Third party vendors also make monitoring add-ons for popular firewall products.
An IDS system in the DMZ will detect attempted attacks for which it has signatures. A dedicated IDS will generally detect more attacks and have greater functionality than the IDS monitoring feature built into firewalls. For example, Internet Security Systems (ISS) makes RealSecure Network IDS software and Proventia intrusion detection appliances that can be installed in the DMZ.
Most large organizations already have sophisticated tools in place to monitor network activity in general: software such as HP's OpenView, IBM's Tivoli/NetView, CA Unicenter or Microsoft's MOM. Many use multiple monitoring tools, especially if the network is a hybrid one with multiple operating systems or platforms.
How do you integrate DMZ monitoring into the centralized management/monitoring system? In this case, you could configure the firewalls so that the existing network management and monitoring software could communicate with the DMZ devices. However, this would present a brand new security risk. Monitoring software often uses ICMP and/or SNMP to poll devices and keep track of availability. These protocols are not secure and could be exploited.
A more secure solution would be put a monitoring station running proprietary monitoring software inside the DMZ or install agents on DMZ devices. Information can be sent back to the centralized network management/monitoring station in encrypted format for better security.
There are devices available specifically for monitoring DMZ activity, such as the ZoneRanger appliance from Tavve. Placed in the DMZ, it monitors servers, devices and applications and creates a secure conduit through the firewall to proxy SNMP data to the centralized network management/monitoring station.
Whichever monitoring product you use, it should have the capability to log activity and to send a notification via e-mail, pager or other immediate alerting method to administrators and incident response teams.
DMZ: As easy as 123
Deploying a DMZ consists of several steps: determining the purpose of the DMZ, selecting the servers to be placed in the DMZ, considering other devices (such as IDS/IDP) to be placed in the DMZ, and deciding on a method and strategy for monitoring DMZ activity. When you understand each of these steps and use the tools mentioned in this article, you can deploy a DMZ in your organization with relative ease.
Debra Littlejohn Shinder, MCSE, MVP is a technology consultant, trainer, and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor, and contributor to over 20 additional books on subjects such as the Windows 2000 and Windows 2003 MCSE exams, CompTIA Security+ exam, and TruSecure's ICSA certification.