Re: FW-1 DOS attack: PART II

[lance () SPITZNER NET (Spitzner, Lance)]

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