[11237] in bugtraq
Re: FW-1 DOS attack: PART II
daemon@ATHENA.MIT.EDU (Spitzner, Lance)
Tue Aug 3 12:25:49 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.SO4.4.02.9908011109090.9797-100000@spitzner.net>
Date: Sun, 1 Aug 1999 11:23:07 -0500
Reply-To: lance@SPITZNER.NET
From: "Spitzner, Lance" <lance@SPITZNER.NET>
X-To: Ramon Krikken <rkr@nmi.net>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <19990801114755.59065@service.nmi.net>
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
