Date: Mon, 24 Apr 2000 16:12:38 -0400 (EDT) From: stanislav shalunov <shalunov@att.com> To: bmilekic@dsuper.net Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack Message-ID: <200004242012.QAA46910@tuzik.lz.att.com> In-Reply-To: <Pine.BSF.4.21.0004241530110.20271-100000@jehovah.technokratis.com> (message from Bosko Milekic on Mon, 24 Apr 2000 15:36:22 -0400 (EDT)) References: <Pine.BSF.4.21.0004241530110.20271-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: Bosko Milekic <bmilekic@dsuper.net> > > Well, with regards to (b) -- somewhat -- I have been thinking about > a solution for `local' processes swallowing up sockbuf space and, > consequently, mbufs. I'm sure you can think of something else to append to > that and have similiar behavior for remote attacks. I've looked at your paper draft (printed it out, even). I'm not a real kernel hacker to appreciate what's difficult and what's possible, but it seems to me that the daemon design you describe would suffer because of its out-of-layer placement. While it's a noble goal to try to prevent local DoS attacks, it's probably not really possible in Unix model (a virtual machine would help). I think it'd make more sense to concentrate on remote attacks, and limit oneself to AF_INET family. UDP is fine: We send it and forget about it. If we are short of any resource, we drop it. An attack such as netkill requires protection of TCP stack that amounts to killing TCP connections. To make intelligent decisions, we need some information about connections (queues, rtt, time of last packet from remote, etc.) TCP code has all the information for TCP packets. How easy would it be to look for it from a separate daemon? How maintanable would it be? If something changes later, how easy would it be to forget about the daemon? And since it'll only show under attack, testing might not reveal such omission. Since something has to happen pretty fast when there's no mbuf space for new connections or for growing send queues, it'd seem that kernel itself might seem like a natural place for such action, no? > I'm very willing to continue the work once this is all over, which > will hopefully be in approximately 3 weeks. I'm willing to provide input and to discuss what the system should do in my opinion as long as the kernel is a black box. My expertise is insufficient to discuss placement of those actions in particular places in kernel. --Stanislav 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?200004242012.QAA46910>