Yeah, I have the stevens books and they are the bibles for me (funny they have very
little coverage of bootp/dhcp in volume 1&2) but anyway....
I already do define icmp rules for request in one direction, reply only in the other
etc etc.
but that is not my point.....my point is that from what I have been reading you must
write some custom inspect code to make this occur in a statefull manner.
In other words, a REPLY should not be allowed to be sent unless a state entry has
already been defined for a prior REQUEST which it is in reply to.
It sounds to me like if I define a rule that allows icmp-reply from the outside, I
could
fabricate icmp packets with the proper type code and it would just forward them
right thru my firewall without any stateful inspection.
Am I missing something here?
As far as I am concerned, ICMP is far too easy a way to move data around under
the radar, but it is really hard to just completely turn it off.
----- Original Message -----
From: "Jon Vandiveer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 10, 2001 2:45 PM
Subject: [FW1] ICMP Stateful or NOT ?
>
> ICMP, statefully inspected, ummm NO
>
> Check out TCP/IP Illustrated... (i.e. read it......)
>
> There are ~17 types of ICMP messages ( that I know of)
>
> If you want to controll ICMP, YOU will need to setup a rule of your own
> devising:
> maybe something like this.....
>
> S D S A
> X Y ICMP Echo Request Allow
> Y X ICMP Echo Reply Allow
>
>
>
> Date: Wed, 10 Jan 2001 09:59:40 -0500
> From: [EMAIL PROTECTED] (Carl E. Mankinen)
> Subject: [FW1] ICMP Stateful or NOT ?
>
> I seem to be reading quite a bit that even 4.X does not use stateful
> inspection
> for ICMP requests. Is this in fact the case, or has CheckPoint corrected
> this
> in the latest releases?
>
> For them to say that ICMP packets are harmless and thus do not require
> stateful inspection is beyond belief (having my doubts they actually said
> this...)
> ICMP is a perfect method for tunneling control connections for trojans, or
> for sending obscured hashed data containing information you wouldn't like
> exposed.
>
>
>
> ================================================================================
> To unsubscribe from this mailing list, please see the instructions at
> http://www.checkpoint.com/services/mailing.html
> ================================================================================
>
================================================================================
To unsubscribe from this mailing list, please see the instructions at
http://www.checkpoint.com/services/mailing.html
================================================================================
