Re: FW-1 DOS attack: PART II

From: Spitzner, Lance (lanceat_private)
Date: Sun Aug 01 1999 - 09:23:07 PDT

  • Next message: coda: "midnight commander vulnerability(?) (fwd)"

    On Sun, 1 Aug 1999, Ramon Krikken wrote:
    
    Ramon, you raise some excellent issues, specifically how FW-1
    mangles packets.  I have not tested that yet, so I cannot confirm
    nor deny its validity, however I have heard of this behavior
    before.  Looks like I have a new challenge to play with :)
    
    Regardless if FW-1 mangles packets, the issue still remains:
    If I initiate a connection with an ACK packet, and that session
    is accepted, it is then added to the connections table with a
    3600 second timeout(default), regardless if the remote system
    responds or not.  You now have a dead connection sitting in your
    state table for the next hour.  You can quickly fill your
    connections table, even by accident, because of this.
    
    There are a variety of measures you can take to protect against
    this, all of which I have detailed in my paper.
    http://www.enteract.com/~lspitz/fwtable.html
    
    1.  Decrease TCP Timeout to 15 minutes.
    2.  Increase your connections table to 50,000 +.
    3.  Implement a strict Firewall rulebase.
    4.  Jason Rhoads is developing a PERL script that monitors
        your connections table.
    5.  Enable Fastpath/FastMode (this does have other security
        implications).
    
    Thanks for the great feedback!
    
    > This is the correct behaviour for all FW1's. When FW1 receives
    > a !SYN-ACK packet it assumes the packet to be part of an established
    > connection. If the connection was not in the connections table, it
    > will be added, and the packet is mangled (strip data and change tcp
    > seq. nr) and forwarded to the remote host. Whether the connection was
    > valid or not, the destination host would reply, and the FW will
    > drop the connection from the table, or keep it. However, the only
    > way the connection is dropped from the table is when the destination
    > host sends two FIN packets, or the timeout value is reached. Therefore
    > if the destination host is not reachable, it takes a while for the
    > connections to vanish.
    >
    > As far as I understand, the rules don't even have to allow the connection.
    > This is because 'drop' in your ruleset does not mean drop. In order to
    > really drop the mangled packets the action needs to be 'vanish' (which is
    > not configurable through the GUI. Edit the .pf files manually).
    >
    > Note that this is how I understand the workings. I might be incorrect
    > in assuming that this explains the problem.
    >
    > On Thu, Jul 29, 1999 at 09:42:39PM -0500, Spitzner, Lance wrote:
    > >
    > > Now, if you start a connection with an ACK packet, the FW
    > > compares it against the rule base, if allowed it is added
    > > to the connections table.  However, the timeout is set to
    > > 3600 seconds and does not care if a remote system
    > > responds.  You now have a session with a 1 hour timeout,
    > > even though no system responded.  Now, do this with alot
    > > of ACK packets, and you have full connections table.
    > >
    > [SNIP]
    > >
    > > I would greatly appreciate if anyone could prove/disprove
    > > this. Also, FW-1's SynDefender did not protect against this
    > > attack.
    >
    
    Lance
    http://www.enteract.com/~lspitz
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:54:49 PDT