Linux Server Security (2nd Edition( [Electronic resources] نسخه متنی

2.3. 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 (and critical!) 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 might
be different from the one who manages the firewall and DMZ servers,
and he might 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 administrators.

But does this mean corporate email, DNS, and other crucial servers
should all be moved from the inside to the DMZ? Absolutely not! They
should instead be "split" into
internal and external services. (This is assumed to be the case in
Figure 2-2).

DNS, for
example, should be split into
"external DNS" and
"internal DNS": the external
DNS zone information, which is propagated out to the Internet, should
contain only information about publicly accessible hosts. Information
about other, nonpublic hosts should be kept on separate
"internal DNS" zone lists that
can't be transferred to or seen by external hosts.

Similarly, internal email (i.e., mail from internal hosts to other
internal hosts) should be handled strictly by internal mail servers,
and all Internet-bound or Internet-originated mail should be handled
by a DMZ mail server, usually called an SMTP gateway. (For more
specific information on Split-DNS servers and SMTP gateways, as well
as how to use Linux to create secure ones, see Chapter 6 and Chapter 9,
respectively.) Thus, almost any service that has both
"private" and
"public" roles can and should be
split in this fashion. While it may seem like a lot of added work, it
need not be, and, in fact, it's liberating: it
allows you to optimize your internal services for usability and
manageability while optimizing your public (DMZ) services for
security and performance. (It's also a convenient
opportunity to integrate Linux, OpenBSD, and other open source
software into otherwise commercial-software-intensive environments.) Needless to say, any service that is strictly public (i.e., not used
in a different or more sensitive way by internal users than by the
general public) should reside solely in the DMZ. In summary, public
services, including the public components of services that are also
used on the inside, should be split, if applicable, and hosted in the
DMZ.

The primary exception to this rule is databases used by web
applications: it isn't a good idea to store critical
data in untrusted networks such as DMZs, so the best place for
databases is the internal network. The tradeoff is that you must then
allow inbound queries from your DMZed web servers to your internal
database servers, but it's possible to mitigate this
risk through careful design and hardening of those servers.