Re: Crafted Packets Handling by Firewalls - FW-1 case

[IAKOVLEV () FR IBM COM (IAKOVLEV () FR IBM COM)]

If I remember correctly, this may something to do with the "transparency"
designed into FW-1: if a problem occurs and the inspect module is reloaded,
state tables purged etc., this should not break the connections underway. So if
an ACK goes back, the firewall gets it through, the sending host is supposed to
respond with a valid forward packed, and the state table will be recreated.
But you are right, in some cases those reverse packets could be dropped without
big harm to the operations, ex. SYN-ACK (the initiating host will have to send
more SYNs); and in some cases they can probably be allowed through (with the
sanitized payload) ex. FIN-ACK, but with the response of the targeted host
blocked if it does not correspond to a normally allowed traffic pattern.

Regards,
A. Iakovlev

*** Disclaimer: The above views and opinions are my own and do not represent nor
necessarily correspond to those of the IBM Corporation ***

Ofir Arkin <ofir () packet-technologies com> on 20/01/2000 07:33:38

Please respond to ofir () packet-technologies com

To:   BUGTRAQ () SECURITYFOCUS COM
cc:    (bcc: Andrei V Iakovlev/France/IBM)
Subject:  Crafted Packets Handling by Firewalls - FW-1 case

I will try to focus more on the subject.

FW-1 do accept:  ACK, SYN-ACK, NULL, FIN-ACK  (and more) as valid
traffic if they match the rule base, even if no connection establishment
was in progress and no session state was in the firewalls table.

That means no SYN was sent from the inside machine
no SYN-ACK from the outside machine and no ACK back
to finish the 3 way handshake [This is connection establishement
from the inside out].

Just a "nowhere from" SYN-ACK traveling from the attacker to
the probed host(s).

I have seen before Lance Spitzners article about "Understanding
the FW-1 State table" http://www.enteract.com/~lspitz/fwtable.html
(all lance papers are worth reading!) and it is validating what I have
found a few month ago.

If FW-1 was checking for correctness, if the SYN-ACK belongs
to a connection establishment in progress, no problem would
have occur.

Since a SYN from an inside machine should indicate the starting of
the 3 way handshake, that a  SYN-ACK should be returned with
the same per of sockets.

But since no "state" was made in the table for this connection
no firewall should accept this SYN-ACK.

Afrer the SYN (or other combination of the TCP Flags from the outside)
to an open port (and IP) in the FireWall rule base openes a session
in the statefull table any other packet  can travel from the outside ->
inside
when the only checking to be made would be see if it match the
sockets!.

This opens a welth of opportunities to the attacking part.

OS Detection, Port Mapping and other tactics to map a network enjoy this
behavior.

If CheckPoint FW-1 have a problem with the start/stop process
than it had to build another mechanism to remember.

Understanding that one of the Firewalls obligations is to examine
valid traffic is essential. He is, in most cases, the sole defender of
a network.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ofir Arkin                      Tel: 972-3-5587001
Security QA Manager    Fax: 972-3-5587003
Packet Technologies     http://www.packet-technologies.com
                                   ofir () packet-technologies com
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-