>My question is am I right or wrong when I think that most critics made to
>packet filtering (no user authentication, no application level knowledge,
>firewall "open" when down, vulnerable to snooping, vulnerable because of IP
>fragmentation, of udp connectionless protocol, of RPC...) do not apply to
>Firewall-1 because of it's enhanced filtering features ?
Yes and no -- there are a lot of subtle issues and one of
these days I need to do a whitepaper, but until then maybe I can
put a few ideas out for discussion. [I think ches and smb will be
talking about some of this in the next rev of thier book, too]
First off, the reason for application level gateways rather
than "smart packet filtering" was mostly an implementation detail.
If you remember back, there was a time when free versions of UNIXlike
source weren't growing on trees, and if you hacked a firewall into the
kernel you had to sign your brain rights away in perpetuity on
a source license. It's a big win, portability-wise, and from a
standpoint of making it easier to test code. Running an application
gateway under Saber-C is a luxury you don't get with an in-kernel
proxy. But I digress... :)
The original idea of an application gateway was that it
gave you a few things a simple router-based firewall didn't:
1) Since you were working at a TCP level, the view of
your traffic was instantly converted to connection
oriented, which made life a lot easier.
2) Since you were mediating the connection, you could
put extra logging or security features into the proxy,
which you can't do in a router.
3) It was easier to run under a debugger.
Nowadays, with dynamic packet filtering, #1 no longer
applies. The firewall (presumably) makes sure that the connections
are managed and sequenced correctly. If implemented correctly
it should be about the same degree of difficulty to spoof a
dynamic packet filtering firewall as an application level
firewall. So they are comparable.
#2 is the trick, and it's inbound services that really
grab you by the 50-ohm resistor. :(
Suppose you have an application level proxy that
recognizes the old
Reply-To: "|..."
sendmail hole. The proxy can provide blanket coverage
for all systems behind it, if it filters that nonsense out. So
that's a real benefit. If it's a screening firewall, unless
there's what amounts to proxy code in the firewall, that
stuff will get through. It means that:
1) You need to configure your firewall right
2) You need to secure (at least one system) behind the firewall
Now, a smart packet filtering firewall might be able to
do that particular check -- essentially a subroutine call built
into the in-kernel filter -- then they'd be equivalent to an
application gateway.
The bottom line, however, is that if you're a duly
paranoid network manager, you'll probably still block all
incoming mail (regardless of the type of firewall) and direct
it to a postoffice system behind the firewall, which is
running a reasonably patched-up version of sendmail. Otherwise
you're just asking to get nailed by the next sendmail hole
that the application level proxy doesn't "know" about. I'm
using sendmail as an example here, but it could be any
service. :( If you have a TELNET proxy and I talk to it and
then it connects me to a system behind it with a buggy telnetd,
then I can still break your machine if I somehow manage to
authenticate or steal an authenticated connection.
The end result of this is that there's a strong
pressure to LET NOTHING IN which means the Internet link
isn't very useful -- so a balance has to occur. One other
trend I'e noticed is lots of use of plug-gw to "enable"
services inbound to captive processes on internal machines.
That's *exactly* the same as packet filtering, conceptually.
The bottom line is that whatever firewall you
are using, you need to be extremely concerned about how
inbound services are managed. You need to secure them
as well as possible. You need to >>GAACK!<< implement
host-based security! :) Firewalls are not, really, a
solution for inbound services -- which is what everyone
is evolving towards wanting to do. :)
So -- application level firewalls and dynamic
packet filters are basically the same thing as far as I
am concerned, for outgoing access. For incoming data,
you need to look at the application and how/if it can
hurt you, and, at this point, I wouldn't rely on my
firewall to protect me. Draw up a matrix of what needs
to go in and what needs to go out. The firewall can
cover what goes out, and you need to figure out on a
case by case basis how to do host security for whatever
comes in.
Good luck! :)
mjr.
--
Chief Scientist, V-ONE Corporation -- "Security for a connected world"
work http://www.v-one.com
personal http://www.clark.net/pub/mjr/mjr-top.html
Follow-Ups:
|
|
