Linux Server Security, Second Edition

This is the Title of the Book, eMatter Edition

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

30

|

Chapter 2: Designing Perimeter Networks

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 usabil-

ity 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 environ-

ments.)

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