Accept filter semantics (Re: Handling of DOS attacks in NetBSD 5)

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Jan 04, 2011 at 09:36:30AM -0700, Sverre Froyen wrote:
> Hi,
> 
> In the past, I have observed DOS attacks where a client connects to port 80 
> and then leaves the connection open indefinitely. Repeating the process can 
> easily tie up all available http processes.
> 
> I recently upgraded several servers to NetBSD 5 and I now observe a slightly 
> modified behavior, presumably because of the accept_filter(9) addtion to the 
> kernel. Instead of http process starvation, I now observe between one and two 
> hundred TCP connections that are in the "ESTABLISHED" state (as reported by 
> netstat -s). Once this happens, the server denies additional HTTP requests.

There is a problem here: a new socket option is probably required to
allow the application to set a timeout for conections being processed
by the accept filter.  But what to do upon timeout?

Changing the behavior of the filter to just allow connections through
is unsafe: it can break applications that expect that once dataready
lets the connection through, some minimal-size read will not block.

Perhaps it can be changed to drop connections; but this too is a change
in the semantics of the existing filter, albeit one less likely to cause
applications to go catatonic or spinny.

Irritatingly, too, we cannot use the existing receive timeout socket
option to control this behavior, since it is (correctly) inherited
from the listen socket to the accepted socket.

So there's some thought and some new code required here.  All I can say
personally is that I'm working on it, but none of the obvious solutions
actually seem to work without breaking applications written to use
existing accept filters, particularly not complex ones maintained outside
the NetBSD tree.

Thor