[plug] UNIX - RISKS

[Christian]

On Mon, 22 Feb 1999, David Buddrige wrote:

> > create other than the hard limits imposed by the operating system. Since
> > incoming TCP/IP connections are usually handled by servers that run as
> > root, it is possible to completely fill a target machine's process table
> 
> This is based on incorrect data.
> 
> While it is true that servers run as root, it _is_ possible to place a
> limit on the number of processes that a given server task executes.  For
> example Apache can be configured fairly simply to only allow a specific
> maximum number of connections, after which it will refuse further
> connections.

I believe this is something specifically to do with Apache and isn't
really related to the way inetd (or sendmail etc.) handle these
connections.  If inetd had tighter control over how it managed these
connections then this DoS would not happen.  I don't believe there is a
way of controlling how many processes inetd will spawn for a particular
service - other than the way detailed by Simson.

> 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.

> Therefore the statement that:
> 
> > there are no limits on the number of processes that the superuser can
> > create other than the hard limits imposed by the operating system. Since
> 
> Is false.  You can set whatever limits you like.
> This is the same with every other server prosess I have heard of.

How do you set a limit on the number of finger connections that can be
made?  The only way I can think of is to set inetd to "wait" after
spawning a fingerd process however your ability to limit here is very
restricted (ie, limit it to one or no limits).  If you know a way of
setting the number of processes that will be spawned for a given service,
please let me know.  Perhaps xinetd does this (I've never looked at it
closely)  but I don't believe inetd does. 
 
Also in future there is no need to include a copy of a very long message
when replying to the list when you make no comments on that message.

Regards,

Christian.

============================================================================
"Those who do not understand Unix are condemned to reinvent it, poorly."
                					-- Henry Spencer