DMZs for dummies
DMZs are the best place for your public information. That way customers, potential customers, and outsiders can obtain the information that they need about your company without accessing the internal network. Your confidential and proprietary company information should be stored behind your DMZ on your internal network. Servers on the DMZ shouldn't contain sensitive trade secrets, source code, or proprietary information. A breach of your DMZ servers should at worst create an annoyance in the form of downtime while you recover from the security breach.
Here are examples of systems to put on your DMZ:
- A Web server that holds public information.
- The front end to an e-commerce transaction server through which orders are placed. Keep the back end, where you store client information, behind the firewall.
- A mail server that relays outside mail to the inside.
- Authentication services and servers that let you in to the internal net.
- VPN endpoints.
- Application gateways.
- Test and staging servers.
Typically services like HTTP for general public usage, secure SMTP, secure FTP, and secure Telnet are deployed on the DMZ. If you use your firewall to block all incoming HTTP connections headed for your internal network, people from the outside can't surf your internal network. Once outside HTTP is blocked, departments within your organization can then safely deploy Web servers solely for internal use.
If you want to deploy secure FTP and secure Telnet bastion hosts that have built-in authentication mechanisms such as S/Key or time-based token ids, your DMZ is the place to put them. Since e-mail starts out by traversing public networks, it is inherently insecure. By having a SMTP gateway on your DMZ that transfers e-mail to an internal mail hub, you can place potentially infected public e-mail on the SMTP gateway, inoculate it with anti-virus software, and then securely deposit it on an internal mail hub that is configured to receive "cleaned" mail from your secure SMTP gateway.
To build a DMZ, your firewall has to have three network interfaces, as most nowadays do. One interface goes to the inside of your network, one goes to the un-trusted Internet, and the third goes to the DMZ. The DMZ consists of those servers you need to connect outside of the firewall. Servers containing your mission critical data are protected behind the firewall (See Figure 1).
When you configure your firewall rule-set, you want to put tight restrictions on the traffic you let through to your internal network, and use different, and perhaps less restrictive rules for your DMZ. For example, you can allow HTTP to the Web-server on your DMZ, but not allow HTTP to your internal network. Systems in the DMZ should be as securely locked down as you can make them. You might use application-locking devices to prevent unauthorized behavior on your DMZ, and you might have an intrusion detection system in place on your DMZ. You can monitor machines on the DMZ fairly simply, because you know what ports need to be used, and how the general public or your internal employees need to make use of the DMZ servers.
By contrast, you need highly restrictive firewall rules for traffic heading to your internal network for a variety of reasons. First, since security is typically an afterthought, it is often the case that the security of your internal network is typically in some sort of nebulous or unknown state, so you need to create a penetration barrier. Second, users inside your network will want maximum flexibility, and therefore will reject internal security mechanisms as much as they can. You basically need to protect these users, and their systems, from their own naiveté.
An analogy I like is one that I heard Christian Byrnes, Vice President of Global Security Strategies for the META Group, recite at a recent security conference: "You can't boil an ocean, but you can boil a pot of water." In other words, you might not be able to secure all the systems on your network, but you can secure a small handful of systems--those on your DMZ.
It only takes securing a few systems to create a security perimeter around your internal network. If your internal network has grown to an ocean-sized state, putting in place a DMZ is a security project that has a defined scope--and that's something you can turn into a security success story.
Laura Taylor is the Chief Technology Officer and founder of Relevant Technologies. Ms. Taylor has 17 years of experience in IT operations with a focus in information security. She has worked as Director of Information Security at Navisite and as CIO of Schafer Corp., a weapons development contractor for the Department of Defense.