Re: Comparisons of Firewall-1 vs. PIX

["Paul D. Robertson" <proberts () clark net>]

On Wed, 30 Sep 1998, Jean-Christophe Touvet wrote:

>  I think your reply raises an interesting question: should source port
> filtering be considered mandatory for a firewall ?

YM "packet filtering firewall", HTH.

>  I'd say generally no, because firewalls are mainly used to protect networks
> from untrusted hosts, and if you don't trust a host, you can't trust source
> port of connections coming from it. In many cases, source port filtering even
> gives one a false sense of security: I've seen too many network administrators
> astonished when presented results of TCP scans using source port 20 or UDP
> scans using source port 53, for example.

And I've successfully used source port limitations to ensure that DNS 
queries came from another box I administered which had user accounts on 
it.  If misuse were a candidate, and internal firewalling were not an 
issue, then maybe you'd have a case, but your limitations seem arbitary 
to me.

>  Source port filtering is useful when writing outgoing stateless filtering
> rules, for instance if one authorizes incoming packets for a given service
> port, only packets with this source port should be going out (with ACK bit set
> if it's TCP), but stateful filtering doesn't require to specify the second
> rule. Theorically, it should be also useful to control source port of
> connections coming from trusted UNIX hosts, because one can (almost ;-) be
> sure that only a root-owned process opened a privileged socket, but that
> source port control is generally enforced on the target host.

What of the case where you are using an internal and external DNS, and 
you want to ensure that only BIND on each server can talk to the other, 
no other services?  Offering source port control in the filter rules 
allows more granular rules, and that's never a bad thing when properly used.

>  This is why I'd understand very well that PIX may not allow source port
> filtering: basically, it's a diode, which trusts everything in the internal
> network and noting outside. To answer the original question (FW1 vs PIX), I

Well, unless they're sending non-initial fragments and you haven't gotten 
the lastest fix *sigh*.

It seems to me that fragment handling (especially of a type that was 
consistantly used in DoS attacks over the last few years) is a part of the  
essance of packet filtering.  Any packet filtering firewall vendor who 
misses that for over a year pretty much goes into the loser column in my 
book.

> think that it's also the most fundamental difference between these products:
> FW1 can be used to control bidirectional traffic between many network
> interfaces and is designed to allow complex rulesets, while PIX's design is
> simplistic.

I'm a fan of neither of the products, but it seems to me that there's a 
happy medium somewhere between the maze of twisty passages that seems to be 
FW-1's design and the over-simplicity of PIX.  While over the years FW-1 
has edged closer to providing more security, PIX doesn't seem to be 
breaking any new ground.  Your observations may vary.

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