Just to clarify; when I was talking about 'state-based firewalls', I
specifically meant 'state-based packet-filters'. As someone else pointed
out, proxies also maintain state, and could be defined as 'state-based'. I
should do as Ryan Russell does and say 'SPF'.
I still maintain that proxies intelligently handle application-level events,
and SPF does not. At all lower levels of the stack you of course have the
entire packet, but you're pattern matching, and are simply not operating at
the application layer, which among other things ensures a valid application
level protocol sequence. At one time I suggested a table of
commands/functions supported by vendor/proxy, though I have not yet seen one.
SPF does not rewrite packets, adding NAT though as Bernd Eckenfels points
out can rewrite packets. NAT though is not SPF, and visa versa.
My opinion on the place SPF should occupy, is in the external and internal
routers of the belt-and-suspenders firewall architechture. I discussed the
NSC NetSentry Borderguard with NSC since someone was positioning it as a
firewall (NetRanger/NetSentry et. al), and NSC stated it was not designed a
replacement for a proxy firewall, but should enhance it as a 'security
router'. A packet filter is a packet filter, and is not a proxy replacement
The crashing FW-1 turns out to be a case of unreleased TCP sessions, where
the webserver was not servicing and releasing HTTP requests fast enough,
FW-1 was queueing up a backlog of TCP sessions, and finally overloading. No
one was releasing TCP sessions. Removing the firewall of course fixed the
crashing issue, but internal to the webserver a single-session localhost DB
link was changed from TCP to UDP which should unlink the (client-WWW-DB)
chain and the queueing problem. Of course, other things need to be fixed...
;) ...Hmm, a new DOS?
One interesting development to watch though, is if you add enough code to a
packet filter, it just eventually might turn into a proxy.
Bill Stout
|
|
