Date: Mon, 24 Apr 2000 22:49:17 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack (fwd) Message-ID: <200004250249.WAA54708@whizzo.transsys.com> In-Reply-To: Your message of "Mon, 24 Apr 2000 12:25:22 EDT." <Pine.NEB.3.96L.1000424121428.15998C-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1000424121428.15998C-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. > The question seems to be: is it acceptable to more agressively manage > state and timeouts, possible limited to specific circumstances, so as to > improve the performance of the FreeBSD TCP stack under conditions of load > similar to this attack (i.e., high levels of state consumption and/or > exhaustion), without substantially breaking normal behavior. Assuming you've got a good round trip time estimation, the timeout shouldn't need to take very long. But there is some administrative notion on how how aggresively you want to reduce the ACK timeout interval. I do like the notion of perhaps performing some sort of admission control on new connections based on the resources consumed by the remote host already. This also addresses the resources consumed on the *system* (e.g., process slots, etc) and not just by the network stack. louie 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?200004250249.WAA54708>