[11234] in bugtraq
Re: Simple DOS attack on FW-1
daemon@ATHENA.MIT.EDU (Lance Spitzner)
Tue Aug 3 09:42:05 1999
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id: <Pine.GSO.4.02.9908010042210.9131-100000@dimension.net>
Date: Sun, 1 Aug 1999 00:46:08 -0400
Reply-To: Lance Spitzner <spitzner@DIMENSION.NET>
From: Lance Spitzner <spitzner@DIMENSION.NET>
X-To: Jeff Roberson <jroberson@CHESAPEAKE.NET>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <Pine.BSI.4.05L.9907301956150.11900-100000@chesapeake.net>
On Fri, 30 Jul 1999, Jeff Roberson wrote:
> It seems to me that if they maintain TCP state they could set a
> significantly smaller timeout if the connection is not established. So a
> timeout of a minute should be set on the initial syn request, and the
> larger timeout should only be used after the connection is established.
Actually, this is how it DOES work. When you get a chance, check out my
website, where I go into detail on how it works. Where it breaks down is
its handling of ACK packets. If I intiate a connection with an ACK packet,
then the connection is automatically added to the connections table for
3600 seconds, regardless if the remote system responds or not. You now
have a dead connection filling your connections table for an hour. Send
alot of these packets, and you quickly fill your connections table. An
example is "nmap -sP -PT80 10.0.0.0/8" launched by an internal system
would quickly fill most connections tables.
> Also, if they implemented a circular buffer where connections that had
> been idle the longest were disconnected in favor of new connections their
> scalability might increase some.
Excellent recommendation, I'll pass it along to Check Point!
Lance Spitzner
http://www.enteract.com/~lspitz/papers.html
Internetworking & Security Engineer
Dimension Enterprises Inc
