Re: Proxy Firewalls as a security requirement

From: Bennett Todd (bet@rahul.net)
Date: 01/23/02


Date: Wed, 23 Jan 2002 11:01:46 -0500
From: Bennett Todd <bet@rahul.net>
To: Frank Murphy <frank.murphy@riag.com>


2002-01-17-12:36:25 Frank Murphy:
> We are running into a few companies demanding that
> we use proxy firewalls instead of stateful inspection.

In my experience, that's the norm in industry segments where
security is really acknowleged to be of paramount importance.

> My boss made the following comment:
>
> " ... an inbound proxy firewall does not provide any
> additional protection that I can see. If port 80 is open
> through a proxy server, the server can still be
> compromised if it has a vulnerability on that port."

The phrase "port 80 is open" is telling. There are proxies of many
sorts. The simplest --- and thus the stupidest, and least secure ---
is a generic TCP proxy, like e.g. the plug-gw in Gauntlet or fwtk.
There are lots and lots of generic TCP proxies available; Freshmeat
works great for finding 'em. If you are using a generic TCP proxy
for incoming traffic, then the TCP service on the inside must still
defend itself against in-band data attacks. This mostly means you
need to choose your daemons carefully. But even this stupid sort of
proxy still provides some protection that a packet filter doesn't.
Since the proxy runs on the bastion, receiving the decoded TCP
stream from the bastion's IP stack, and creating a new packet stream
to the inside, a proxy will automatically strip out any attacks
based on subtleties of weird packets. Fragment reassembly attacks,
various stealthy port scanning tricks, some kinds of
denial-of-service attacks, all get blocked by a proxy. Proxies are
"default closed" to such attacks. Packet filters can block them, but
only if the author of the filtering rules happens to know about and
choose to block the particular attack. Packet filters are default
open to low-level network attacks.

But the above discussion applies only to stupid proxies. Sometimes
such proxies are appropriate, but more often you should use
high-security application-specific proxies, and these add far more
substance. Run dnscache (from djbdns) as your DNS proxy. Run Postfix
as your SMTP proxy. Don't allow anything else inbound through your
bastions (place your webservers outside the bastions).

> Are any of you also advocating Proxy Firewalls as a
> security requirement.

Anywhere I have need for a high-security firewall, I use proxies as
a building block. I haven't found myself in the position of trying
to ram them down someone else's throat before, though; I just note
if someone uses packet filters to allow incoming traffic, and if so
I note that they've got a casual and relaxed security stance and
treat them accordingly.

> If so, would you expound on all the reasons and point me to some
> good documentation?

"All the reasons" is tough. Besides the protection against low-level
network attacks, and the use of application-specific proxies,
there's also a configuration mgmt side of things: I don't use
proxies alone, I always build hybrid firewalls using both proxies
and packet filtering. The two different ways of looking at things
provide a very nice reinforcement: it would be a remarkable
configuration error that would enable new traffic through both
routes.

As for documentation, I'm not sure where to point you. Cheswick and
Bellovin remains my favourite first starting point for getting an
understanding of the problem you're trying to solve. Chapman and
Zwicky is pretty good for basic techniques. Lots of good discussion
in Garfinkel and Spafford, too.

But for the real answer, I'd say subscribe to bugtraq, and to a nice
assortment of firewall mailing lists, and read 'em for a while.
Think of a design you like, and keep track of how often you'd have
to worry about whether someone broke in before you fixed some new
hole you just heard about. Hybrid firewall designs, with multiple
layers using different technologies to provide redundant protection,
can give you "defense in depth", and that can let you sleep easier.

-Bennett