[plug] UNIX - RISKS

[David Buddrige]

I found this by searching on the words "inetd.conf maximum connections"
at dejanews.

It seems to suggest a way that ths DoS could be prevented - by making a
maximum number of connections from any given IP address before rejecting
further attempts until more are closed...

I find that 99.9% of any problems I've had with Linux can be solved in
minutes using the usenet search facilities... it really is amazing...
;-)

regards

Dave...

>On Thu, 6 Aug 1998 01:58:18 -0400 (EDT)  Charles Sprickman wrote:
>> In inetd.conf, just change "nowait" to "nowait.100" or however many
>> connections/minute you need...  It's in the man page somewhere.
<snip>
>... the FreeBSD inetd(8) manual page shows:
>
>{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]]
>The maximum number of outstanding child processes (or ``threads'') for a
>``nowait'' service may be explicitly specified by appending a ``/'' fol-
>lowed by the number to the ``nowait'' keyword. Normally (or if a value of
>zero is specified) there is no maximum. Otherwise, once the maximum is
>reached, further connection attempts will be queued up until an existing
>child process exits. This also works in the case of ``wait'' mode, al-
>though a value other than one (the default) might not make sense in some
>cases.  You can also specify the maximum number of connections per minute
>for a given IP address by appending a ``/'' followed by the number to the
>maximum number of outstanding child processes. Once the maximum is
>reached, further conections from this IP address will be dropped until
>the end of the minute.

>So the -R switch applies to all services but you can taylor individual
>services with the nowait/max-child/rate field.  This FreeBSD is good
>stuff!



Paul Wilson wrote:
> 
> > From: Christian <again at global.net.au>
> > On Mon, 22 Feb 1999, David Buddrige wrote:
> > > Furthermore those connections almost certainly have a timeout after
> > > which it will be dropped - so opening a connection and not transmitting
> > > any data would not work either.
> >
> > I think that's part of the issue - the timeout for TCP is long enough
> that
> > you can keep the number of processes running at a sufficiently high level
> > to prevent creation of new ones.
> 
> There's a recognised DoS attack against web servers that relies on this
> timeout. Make connections to the considerably faster than the timeout will
> collapse the 'unused' ones, and your machine will grind to a halt. It was
> used against (IIRC) the Time-Warner site a couple of years back. In this
> case, even when the server was shutdown and rebooted, the problem didn't go
> away because the sender just kept on opening TCP connections ignoring
> errors. The newspaper article suggested that it took in the order of ten
> days before the attack collapsed.
> 
> Paul