[unisog] automated IP blacklist tools?

John Kristoff jtk at northwestern.edu
Mon Nov 22 20:02:04 GMT 2004

On Mon, 22 Nov 2004 12:52:45 -0600
Albert Lunde <atlunde at panix.com> wrote:

> However, looking at this in the bigger picture across multiple servers, it
> seems like this would have similar requirements to parts of various
> anti-spam or intrusion-detection systems.
> So I'm wondering if people can suggest existing software or products that
> could be adapted to this purpose?

I'd be interested in this too, but for other reasons.  Personally I'd
hope to at least have the option of avoiding yet another box that sits
in between the path between the actual communicating end points.  In
addition, I'm not sure this is a general enough problem that a one size
fits all box works best for.  Though I know some people often prefer to
shove everything into a single box, I'm just not one of those people.

In one of your examples, a LDAP directory, could implement a relatively
simple queueing mechanism and throttle (discard) excessive attempts.  I
really like random early detection (RED) and think this might be another
area where its use can be tried.  Historically this type of problem has
been largely studied in the area of network congestion control and
avoidance mechanisms, which is where RED comes from.  RED has also been
applied to one additional related problem, MSDP storms (for those of you
familiar with multicast and Juniper routers, read up on the
'active-source-limit' config option).

I've also recently realized that this problem is similar to problems
people have in being able to log DNS queries.  Though in this case the
solution is turned into a 'sampling' mechanism, but fundamentally not
unlike the problem you're trying to solve.

If we can get some of these apps to add queueing and limiting knobs
based on source or simply request load, then the most abusive traffic
would be dropped proportionally so that valid stuff can still get

I might also raise the point though that sometimes more capacity is
a easier way to solve the problem.  ...or least most of the problem
up to some really excessive load, for whatever excessive means.
Though techies always seem to hate wasting cycles and most always tend
to optimize use of network bits even more than the use of bits in their
own grey matter.  :-)


More information about the unisog mailing list