Date: Mon, 24 Apr 2000 13:10:42 -0400 (EDT) From: stanislav shalunov <shalunov@att.com> To: freebsd-net@freebsd.org Subject: Re: netkill - generic remote DoS attack Message-ID: <200004241710.NAA44530@tuzik.lz.att.com> References: <Pine.NEB.3.96L.1000422112731.857B-100000_fledge.watson.org@ns.sol.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I missed part of the discussion about FIN_WAIT flooding (term coined by Aleph1) a.k.a. netkill, catching up reading the archives. > From: Robert Watson <rwatson@FreeBSD.ORG> > The easy solutions that come to mind all increase the brittleness of the > network, but are probably better than being toasted: > 1) Decrease timeout on connections that don't respond to ACKs > 2) Enable keep-alives on all connections by default (we should probably do > this anyway for other reasons) > 3) Decrease the wait period in FIN-WAIT-1, especially if no ACKs received It seems none of these work to prevent netkill. The root cause--kernel doesn't know what to do when mbuf space is all taken--remains. The solution must possess the following properties: 1. When there's no attack everything should work as reliably as before; 2. When there's an attack the system must be able to serve at least some requests; 3. Older connections must not be penalized at the expense of bad connections; 4. Ideally, the algorithm used should heuristically identify mostly the bad connections and hurt them, not the good ones. It follows from (1) that until the mbuf space is full kernel shouldn't do anything unusual. It follows from (2) that when memory gets full the system mustn't panic as it does now, and it must do either of these: (a) stop accepting new connections until old ones time out; (b) free some mbuf memory forcibly. To do (b) properly, we can't just throw away pieces of send queues. We must tear down some connections and send an RST to the remote end and return ENOBUFS to the application, if any, using them locally. The solution (a) removes the obvious bug (system panics), but doesn't solve the problem. It appears that some variation of (b) must be deployed. The remaining question is what algorithm to use to identify the connections that need to be torn down (taking into account points (3) and (4)). I strongly suggest some sort of randomness in the selection. This way, even if some good connection possesses properties of what we identify as a bad connection, the remote end still has some chance of getting through when it retries. It's also important to free up a lot of memory. Tearing down connection is better than a panic, but it's bad. Better tear down a lot rarely than randomly kill a connection here and a connection there. This way, there are brief periods when it doesn't work, and it all returns back to normal and stays at least for a few minutes. -- stanislav shalunov, WHPD, shalunov@att.com 732-576-3252 1:10PM up 190 days, 2:32, 6 users, load averages: 0.04, 0.03, 0.02 Conscience is what hurts when everything else feels so good. 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?200004241710.NAA44530>