Re: [FW1] Stateful ICMP

[Chris Brenton <cbrenton@sover.net>]

Wolfram Schmidt wrote:
> 
> > Has anyone gotten stateful ICMP to work on 4.1?
> 
> Is this the same as in 4.0? I can only speak for 4.0.
> If yes, you have to allow the return packets as well.

If you have to enable return packets, is it really stateful? For example
to enable outbound Telnet I don't have to enable >1023 because this is
implied. I would expect ICMP to do the same if it was really stateful.

> "Accept ICMP" is too permissive IMO, but you need it th make ICMP stateful
> (and for encryption, it seems).

This is kind of what I mean as well. If I allow echo-request outbound,
it should be implied that echo-reply should be permitted back in in a
stateful manner. This does not seem to be what's happening with FW-1.

> Therefore I have "Accept ICMP" "Last" -
> after my drop anything cleanup rule. This disables the "Accept" part but
> enables the stateful inspection.

"stateful" maybe, although I would disagree with this statement based on
the above. "inspection", no way. Based on what I've reviewed in 4.0 and
prior code there is _zero_ inspection taking place with ICMP. This means
that if you enable Echo you could just as easily be passing a Loki
control session because no payload inspection is performed. Yet another
"intelligent piece of Swiss cheese". :(

> The statefullnes of ICMP is somewhat different from the statefullness of
> TCP/UDP. ICMP packets which are replies (i. e. echo reply or error packets
> for tcp or udp connections) are checked if the corresponding connection
> exists and dropped if not. Then they are checked against the rulebase.

ICMP is a lot harder to nail down than straight TCP or UDP. For example
with TCP, replies will always be generated from the target host. With
ICMP the reply may come from the target or an intermediate gateway.
Destination unreachable, source quench & time exceeded are good examples
of IP packets that _will not_ be returned by the target IP but some
other address.

So if I'm trying to get to www.sun.com and I get a timex from
192.168.1.5, how does the firewall know if the packet is legitimate?
This could be a gateway between me and Sun or it could be an evil person
out of badguy.com. 

Of course the fix here is to actually "inspect" the packets and look for
the original header in the payload. This will tell you if the timex is
legit or not. Problem here is that you need more than an intelligent
piece of Swiss cheese to pull it off.

Cheers,
Chris
-- 
**************************************
cbrenton@sover.net

* Multiprotocol Network Design & Troubleshooting
http://www.amazon.com/exec/obidos/ASIN/0782120822/geekspeaknet
* Mastering Network Security
http://www.amazon.com/exec/obidos/ASIN/0782123430/geekspeaknet


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================