Great Circle Associates Firewalls
(October 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: re: FW-1 and ICMP (lack of) statefulness
From: Bill Burns <shadow @ netscape . com>
Organization: Netscape Communications
Date: Mon, 13 Oct 1997 09:45:53 -0500
To: firewalls-digest @ greatcircle . com
Reply-to: shadow @ netscape . com

"Paul D. Robertson" <proberts @
 clark .
 net>" was quoted as saying:

>As I said, it doesn't maintain state information for ICMP.  Other than
>that, I've only recently gotten an evaluation unit to try to re-create
>some attacks that I've heard of.  It won't be high on my list, because
>I've personally lost trust in the product, and don't see it as a viable

>choice for the bulk of my security needs in the near future.  I also
won't
>cast further aspersions on the product without having done my own
tests,
>no matter what I've heard, or who I've heard it from.
>
>ICMP state is non-existant as shipped in Firewall-1.  Checkpoint has
said
>that they didn't see it as important to add an Inspect program for it
>implemented as a default.
>
>It is possible to add Inspect code to make it work "as it should" if
>you're to buy into the state implementation.  Personally, I think OOB
>showed it to be fairly flawed methodology-wise, your paranoia may vary.

I can certainly vouch for the fact that ICMP is not handled statefully
as FW-1.  I was getting a lot of flack from my user base when they
wanted to run Vitalsign's NetMedic on their Win95 boxes.
(http://www.vitalsigns.com).  Because it relies on ICMP traceroute and
ping it failed to pass our FW-1 box.  When I looked at the INSPECT code
that handles ICMP I was appalled to see that the FW-1 checkbox "allow
ICMP" meant "allow ICMP packets; except for ICMP redirect".  Yikes!  So
much for stateful inspection which I had come to know FW-1 for.  Turns
out that Checkpoint doesn't handle ICMP statefully nor does it handle
valid ICMP responses to staefully-tracked UDP or TCP packets.

So, after two weeks of learing the INSPECT language (as best as anyone
can learn a language that's not really documented) we came up with our
own INSPECT code to handle ping and traceroute packets.

So....in one respect it was certainly nice to be able to check out their
code to handle these packets and have the flexibility to add to it to
accomidate one's own security policy.  On the other hand, it still seems
lame to have to go through this trouble.

We're evaluating the PIX box as well just to give it our due diligence,
but I must confess that I don't like the feeling of lack of control I
have with a black box approach.  With FW-1 at least I was able to peek
around in their code and tell THEM that something wasn't up to snuff.
With black boxes, you're more or less at the mercy of the salesperson or
technical support person you're talking to in order to get the straight
answer of what they allow.


Indexed By Date Previous: Re: To Gauntlet or not to Gauntlet
From: Frederick M Avolio <avolio @ tis . com>
Next: Re: PIX : big FTP downloads stop a 99% (side-tracked a little)
From: ccurtis @ facm . fit . edu
Indexed By Thread Previous: Re: my Promiscuous mode query
From: Rik Hemsley <hemsleyr @ keyline . co . uk>
Next: firewall-I and eliashim antivirus
From: Arjan van der Valk <avdvalk @ neth . hp . com>

Google
 
Search Internet Search www.greatcircle.com