Re: /N grouped concurrency limits for network services

[Solar Designer <solar () OPENWALL COM>]

On Wed, Feb 28, 2001 at 10:16:47AM +0100, Olaf Kirch wrote:
> Here's something I haven't seen before which I find sort of cool
> (rate limiting grouped by source IP network)...

I've been considering this for popa3d's standalone mode and for
xinetd (both already have a per source IP limit).  xinetd should
implement some defense against the low syslogd bandwidth problem
first (popa3d already has that).

I was going to have a configurable netblock size for use with this
feature, and would set it to /19 by default as that seems reasonable
for present netblock allocations.

Kurt Seifried has some valid concerns regarding IPv6.

Sebastian Krahmer had the opinion that per-source-address limits
actually introduce a DoS possibility.  I mention this here as I
suspect this is a fairly common opinion.  I don't agree.  The DoS
possibility was already there, what the limits do is reduce the
impact of such a DoS.  They also make it (very slightly) easier to
make the service unavailable to those on the same network which
should be considered when configuring the limits, but that is an
acceptable price for the reduced impact of the attack.

The per-source limits are not very different from other limits that
can be configured for a service.  Having a limit of, say, 100 users
logged in to an FTP server prevents the entire physical server from
being DoS'ed and at the same time makes it slightly easier to DoS
just this one service.  We have to choose.  If an implementation of
FTP / *inetd didn't offer the limit, we wouldn't have the choice.

bert hubert wrote:

> I'm not certain weather its best to group ip addresses by /16 or /24 - /24
> might consume too much memory, /16 might be too broad. Perhaps this should
> be a tunable parameter.

There's no memory consumption problem with implementing this feature
like the Bugtraq post implied.

--
/sd