OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: DMZ, defined.

Re: DMZ, defined.


Steve Bellovin (smbresearch.att.com)
Wed, 27 Jan 1999 15:37:20 -0500


Personally, I call it the DMZ network, regardless of whether it's in
between two firewall components or hanging off a third interface on a single
firewall. I'll make sure that that's clear in the second edition of
the book....

Conceptually, the DMZ is a partially-protected zone -- not exposed to
the full fury of the Internet, but not fully behind the firewall.
The point, in general, is not to protect the service hosts -- they
should be capable of protecting themselves; see below -- but to allow
the inside firewall component to make certain assumptions about the
impossibility of outsiders forging DMZ addresses. That in turn allows
more stringent access controls through the inside component.

Why, then, did we use two components with a net between them? In ancient
times, when we chiseled our own firewalls out of stone tablets, a UNIX
box, and a pair of routers, there wasn't a lot of choice. A three-headed
firewall has three possible communication paths to worry about, and
very often the difficulty of applying rules to a path, as opposed to
an interface. A modern firewall box *may* be able to do better, in which
case there's really no reason to buy an extra box.

Earlier, I asserted that service hosts should be able to protect themselves.
To a first approximation, and even to a second, that's obvious -- they
exist to provide a very limited set of functions, either to the outside
or to the inside. By definition, services offered to the outside must be
robust in the face of attack. And at this point, services offered to the
inside can and should be cryptographically authenticated. If nothing
else, you can use ssh for adminisitrative access.

That said, there may be some denial-of-service attacks that can be launched
on the inside-only ports, such as bogus cryptographic authentication
requests -- win or lose, those can be quite expensive. A firewall may be able
to deflect that sort of problem. Or you may be constrained to run some
sort of system where you can't turn everything off, probably because the
vendor was quite certain no one would ever want to, and either built the
system in such a way that you can't do it, or never told you how to in the
first place. In principle, though, service hosts don't need to be protected.
Firewalls are not needed to protect a very small number of specialized
machines; rather, they're designed to protect a large number of general-
purpose machines. And given that, the purpose of the DMZ is to allow
greater assurance about which machines can even attempt to contact the
inside.



This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:18:02 CDT