[21850] in bugtraq

home help back first fref pref prev next nref lref last post

Re: FIN_WAIT_1 DoS (netkill): Why the vulnerability still exists?

daemon@ATHENA.MIT.EDU (Greg A. Woods)
Wed Jul 25 15:18:08 2001

MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@weird.com (Greg A. Woods)
To: stanislav shalunov <shalunov@internet2.edu>
Cc: bugtraq@securityfocus.com
In-Reply-To: <87d76qywpl.fsf@cain.internet2.edu>
Reply-To: woods@weird.com (Greg A. Woods)
Message-Id: <20010724201023.628C4DF@proven.weird.com>
Date: Tue, 24 Jul 2001 16:10:23 -0400 (EDT)

[ On , July 24, 2001 at 15:05:10 (-0400), stanislav shalunov wrote: ]
> Subject: Re: FIN_WAIT_1 DoS (netkill): Why the vulnerability still exists?
>
> (I'd rather throw away random connections, with preference to those
> that eat a lot of buffer space).

That seems illogical given the nature of the problem.

You definitely want to start cleaning up by throwing away connections in
the FIN_WAIT_1 state.  Starting with the oldest ones may have less
impact on valid connections than simply clobbering random ones, and/or
clobbering the ones with the most buffers used.

If you've got some way to tell which connections have ever successfully
transmitted some valid data packets (i.e. gone beyond the handshake and
received any ACKs) then you might initially drop only the connections
which have not ever transmitted any data (er, received any valid ACKs
for sent packets).  I guess it is possible for the attacker(s) to work
around this first-level defense though and ACK one or two data packets
first, but will they?  :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>

home help back first fref pref prev next nref lref last post