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: BUGTRAQat_private 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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:29:32 PDT