COMMAND

    FW-1

SYSTEMS AFFECTED

    FW-1

PROBLEM

    Ofir Arkin found following.  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).   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.

SOLUTION

    FW-1's behaviour in this respect  has been discussed at length  in
    the past  and last  year a  patch was  released by  them for their
    base INSPECT code which changed the behaviour to not be this  way.
    A patch, which fixes this  problem, was made available due  to DoS
    problems.  This URL could help you:

        http://www.checkpoint.com/techsupport/alerts/ackdos.html

    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.