Deciding What Should Reside on the DMZ

Once you’ve decided where to put the DMZ, you need to decide precisely what’s going to reside there. My advice is to put all publicly accessible services in the DMZ.

Too often I encounter organizations in which one or more crucial services are “passed through” the firewall to an internal host despite an otherwise strict DMZ policy; frequently, the exception is made for MS-Exchange or some other application that is not necessarily designed with Internet-strength security to begin with and hasn’t been hardened even to the extent that it could be.

But the one application passed through in this way becomes the “hole in the dike”: all it takes is one buffer-overflow vulnerability in that application for an unwanted visitor to gain access to all hosts reachable by that host. It is far better for that list of hosts to be a short one (i.e., DMZ hosts) than a long one (and a sensitive one!) (i.e., all hosts on the internal network). This point can’t be stressed enough: the real value of a DMZ is that it allows us to better manage and contain the risk that comes with Internet connectivity.

Furthermore, the person who manages the passed-through service may be different than the one who manages the firewall and DMZ servers, and he may not be quite as security-minded. If for no other reason, all public services should go on a DMZ so that they fall under the jurisdiction of an organization’s most security-conscious employees; in most cases, these are the firewall/security ...

Get Building Secure Servers with Linux now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.