Date: Mon, 24 Apr 2000 16:36:19 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: stanislav shalunov <shalunov@att.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: netkill - generic remote DoS attack Message-ID: <Pine.BSF.4.21.0004241619160.20571-100000@jehovah.technokratis.com> In-Reply-To: <200004242012.QAA46910@tuzik.lz.att.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Apr 2000, stanislav shalunov wrote: > 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). Given the argument of an already existing sockbuf limiting implementation, and the argument you've brought up above, then the conclusion that you have drawn seems justified. However, solutions must exist even in cases were configuration limits fail. The `daemon,' perhaps a misleading term, simply means in this case the it is to run as a so-called `kernel process,' like `bufdaemon,' for example. The layout that you've seen probably suffers from certain specific issues, but it nonetheless offers system-wide mbuf-exhaustion prevention for local processes. Limiting sockbuf space is great, but no matter to how low you may want to limit, enough [limited] offenders could eventually exhaust available resources -- this is primarily when the `daemon' is to be invoked. > > 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. Yes, this is exactly what makes things like this difficult. You want to implement something very flexible and reliable in-all-cases, but at the same time, you wan't to keep it clean and easily modifiable (as opposed to scattered all around the place). > > 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? As I said, the so-called `daemon' is a `kernel process,' and it runs in a kernel context with access to the kernel's global lists, and so on. Regardless, your point regarding speed in the case of remote-attacks is valid. This is specifically why I split the problem in two: (a) The local case; (b) The remote case. The approaches, as you've noticed, are entirely different. > 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 > I'm glad that you've already commented as you have and hope that you'll find time to perhaps "take the dive" and implement (or assist in) points (b) and (a) above. I'm also curious to see what changes are to come (if any) to this area of the tree as an indirect consequence of the WC/BSDi merger. -Bosko -- Bosko Milekic * pages.infinit.net/bmilekic/index.html * www.technokratis.com bmilekic@dsuper.net * bmilekic@technokratis.com * b.milekic@marianopolis.edu 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?Pine.BSF.4.21.0004241619160.20571-100000>