OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Solar Designer (solaropenwall.com)
Date: Thu Mar 01 2001 - 07:28:11 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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