Date: Mon, 24 Apr 2000 22:15:26 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: Robert Watson <rwatson@FreeBSD.ORG>, Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) Message-ID: <20000424221526.F31449@prism.flugsvamp.com> In-Reply-To: <200004250249.WAA54708@whizzo.transsys.com> References: <Pine.NEB.3.96L.1000424121428.15998C-100000@fledge.watson.org> <200004250249.WAA54708@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 24, 2000 at 10:49:17PM -0400, Louis A. Mamakos wrote: > > On Mon, 24 Apr 2000, Jonathan Lemon wrote: > > > > > Given a quick look at netkill, it appears that it mainly acts as > > > a DoS by establishing a connection, then dropping its end, leaving > > > the server to maintain the connection until TCP gives up. The server > > > will wind up with the connection in either ESTABLISHED or FIN_WAIT_1 > > > state, depending on the traffic patterns, and what the attacker does. > > > > Sounds right to me, although the technique really applies to any part of > > the state machine--presumably you select one of those states because they > > provide the longest timeouts before automated garbage collection or > > connection verification ``keepalive''. At this point with the ESTABLISHED > > case, as Louis has pointed out, it is generally assumed that the > > application level will take care of detecting dead end-hosts not > > responding in a timely manner. However, if the application layer does do > > this and perform a close(), the state still hangs around in the FIN_WAIT1 > > stage for a long time, so I don't see any purely application layer > > solution helping us. > > Actually, it shouldn't hang around in this state. When the local application > does a close(), the local sends a TCP segment to the remote host with > a FIN flag set, and wants this FIN to be acked. In the netkill attack, > presumably the remote host won't be answering and the connection will get > timed out. After the local host's FIN is ACKed, the connection state > moves to FIN-WAIT-2 awaiting the remote host to send a FIN from > it's side. Yes, but when in FIN_WAIT_1, the connection sits around waiting for its FIN to be acked, and keeps re-transmitting the FIN until TCP gives up. The timeout for this is essentially the retransmit interval, and TCP drops the connection after reaching maxrexmt, but this period is long (the same as a timeout in ESTABLISHED state). For FIN_WAIT_2, we start a timer at 2MSL, which is shorter than a full blown rexmt timeout. (yes, this violates the spec, but its better than sitting around forever) -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000424221526.F31449>