Protecting Data with a Military-Style DMZ

Some IT and security administrators are relying on an old military technique to layer their network defenses -- they're creating a demilitarized zone, or DMZ.
Posted December 17, 2004

Sandra Gittlen

For Allen Gwinn, senior IT director at Southern Methodist University in Dallas, the question is not if his 15,000-user network will be exposed, but how to control the damages when it happens.

Gwinn knows that as part of an educational institution, his network is a prime target for hackers. At the same time, there is a lot of information on his network that he must allow the public to access. To that end, Gwinn relies on an old military technique to layer his network defenses -- he's created a demilitarized zone, or DMZ.

DMZs are no-man's lands created to ferret out the enemy. Anything in the DMZ is negligible. In the enterprise, a DMZ is an area where the public can access certain elements of the network, but not the back-end mission-critical systems.

While firewalls, intrusion detection and intrusion prevention all are good strategies for detecting unwanted traffic on a network, Gwinn says the DMZ analogy provides a blueprint for bringing all these security tools together for maximum protection.

''A DMZ is a frame of mind on how you're going to treat things exposed to the Internet,'' Gwinn says. ''Everyone needs a plan for how you approach having devices in an untrusted world.''

Rick Fleming, CTO at Digital Defense, a computer security firm in San Antonio, Texas, says the trick is to put things in the DMZ that would not lead to catastrophic results if they were jeopardized.

He recommends Web servers, e-mail servers, and other information stores such as PDF silos. ''You have to ask, if someone were to gain root level access to this Web server, what would be the net effect? The answer should be that there is no net effect,'' Fleming says.

He adds that a lot of companies want to be able to put information out to the public, such as financial institutions. But they often make the mistake of linking those public machines with back-end private networks. He points to cases where banks offer public access to Web servers by giving customers digital forms to fill out. ''Suddenly, a hacker can access customer information in the back-end SQL database with simple queries,'' he points out.

Gwinn agrees.

''You don't want someone to compromise a machine in your DMZ and then come inside and compromise a machine within,'' he says. ''Machines classified as DMZ machines should have as little connectivity or as limited a connection as humanly possible with machines on your trusted network.''

As an example, Gwinn says he puts his e-mail server in the private network, but his e-mail smart host in the DMZ to take in and send out messages. He says putting a Microsoft Exchange Server in the DMZ is foolish. ''The first thing that happens is someone comes along and finds an exploit in the code and they exploit your server. They can then own your network.''

IT managers should create a DMZ that takes these possibilities into consideration. ''If the DMZ is set up correctly, it should limit outbound connections in some way, as well,'' Fleming says. ''If someone does compromise a box, they are limited to where they can go and what they can do. The server should not initiate outband connections, but people don't often think that way.''

Winn Schwartau, president of security consultancy The Security Awareness Company, says the biggest thing to have in a DMZ is deception.

''Whoever is coming in there should not know whether it's real or not,'' he says. ''The good guys will be fine and dandy but the bad guys will not. You want to create a hall of mirrors.''

He recommends adding a honeypot to the DMZ where you can get information on anyone trying to access your network. ''It allows you to spoof the bad guys and collect data on the tools they are using,'' he adds.

A DMZ does have its drawbacks, including the overhead on traffic. While Schwartau recommends examining all inbound and outbound traffic, he recommends using a variety of appliances to do this. ''Perform side tasks -- have your e-mail and virus checking on one box and your content filtering on another. Make it as distributed as possible so you're not overloading the CPU,'' he says.

Other considerations for a DMZ are the computation power required and temporary data storage, which for large enterprises could become costly.

For this reason, some companies reject the DMZ blueprint. ''They would rather deal with an occasional attack,'' Fleming says.

Not Gwinn. He says the costs associated with a DMZ are well worth it.

''Sure, it raises your costs until you prevent your first network security disaster. If you don't know what a costly network is, just wait until you have a major security compromise.''

0 Comments (click to add your comment)
Comment and Contribute


(Maximum characters: 1200). You have characters left.