On Tue, 21 Oct 1997, Graham Wheeler wrote:
> > > My biggest beef with 'state-based firewalls' is that a
> > > state-based filter cannot rewrite packets, it passes packets through,
> > > leaving the internal network exposed to various packet attacks.
>
> This is not true. Our Citadel firewall, for example, which supports both
> proxies and state-based packet filtering, when used in transparent
> state-based filtering mode, modifies all packets to hide
> internal addresses and ensure that client ports are still unique as a
> result, as well as modifying the packet contents for FTP (PORT changes)
> NNTP (newsgroup blocking). It also parses packet content to log FTP
> transfers, WWW URLs, newsgroup access, etc.
I think you're missing the point completely here. What a packet filter
doesn't do is rewrite what are 'legitimate' packets at the transport
layer. Modifying portions of a packet isn't the same as rewriting it.
For instance, a packet filter won't protect an NT 4.0 base computer from OOB
attacks, and still allow a Solaris one to function. You _have_ to upgrade
every "protected" machine or deny legitimate OOB packets. Proxies simply
don't have that problem, fix the gateway and the problem immediately
disappears.
Transport and Internetwork layer bugs are erradicated with one solid proxy's
stack. If the proxy is running on an OS which isn't vulnerable (taking some
of the eggs out of that same basket), then you'll never see the problem.
Extrapolate that bug problem out to a trojan or up to a whole transport
mechanism, and it's a hands down win for the proxy side.
In the case of other covert channels, it is certainly possible for a packet
filter to zero the "empty" part of a frame, or replace the data portion of
an ICMP echo request datagram, but most of them don't. Proxies give you
that protection cheaply, it's part of the model. Filters need to have it
written in. By the time it is all written in, if that ever happens, the
fantastic speed increases touted by those vendors are non-existant.
Fragment attacks are another place where well-tuned proxies tend to work
out well by default.
> > > A
> > > state-based filter also does not have the application code to intelligently
> > > filter application commands.
>
> I agree that it is much easier to write a proxy to do these things, as you
Which makes the code easier to verify, which makes the code easier to
write correctly, which makes the assurance level higher. We are talking
security here.
While there are a great number of people who think that having _any_ firewall
is security, there are still a few of us who like to minimize *all* the risks
as _much_ as possible, and then try to do intrusion detection for the
rest. I'm more interested in how a vendor handles coding and fixes to
stop a rogue employee than in buzzwords, transparancy, or GUIs.
Hell, 99% of the firewalls out there have administrators who have never
done a risk analysis on SMTP or HTTP. That sure as hell doesn't make
those people right, bright, or someone to base a firewall choice on.
Attackers are getting _more_ sophisticated. Firewall administrators are
getting _less_ sophisticated. Packet based firewalls are more permissive
than proxies. Am I the only one who has a problem with this?
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
proberts @
clark .
net which may have no basis whatsoever in fact."
PSB#9280
Follow-Ups:
References:
|
|
