Re: [ANNOUNCE] Kernel Blocking Firewall

[Willy Tarreau]

On Fri, Jan 09, 2009 at 01:15:06AM -0700, jmerkey@xxxxxxxxxxxxxxxxxxxxx wrote:
> You should go and look at the code, 1) the window of addresses cached in
> memory is designed to act as an LRU windows for the addresses stored in
> the database to use less memory, so no, the in-memory only ip tables is
> primitive in comparison

I was not speaking about iptables but ipset which is an iptables extension.
>From my memories, you can have addresses stored as bitmaps, where one bit
equals one address. This would lead to less than 100 kB of RAM for your
500k addresses. But I agree that the concept of the LRU cache is interesting.

> 2) the database can just keep growing ad growing
> 3) the code I posted also loads the database if the system reboots, so
> your applications remember all those botnet addresses 4) their is the
> ability to set a timer to expire and recycle the oldest addresses (while
> still remembering all of them).

IIRC, this is also supported in ipset (I just have not looked at it for a
while now).

> From my experience with dealing with these systems, and observation of how
> RBL databases work, when an infected system gets blacklisted, it stays
> that way until the user goes to the websites and requests removal.  I have
> found these zombie systems tend to stay that way, and no, by default you
> NEVER want to unblock them for at least 6 months.

This is stupid considering that most of them change their IP address every
24 hours, or at most every 7 days. This is just used to show that spam rate
drops, hiding the fact that valid mails drop for similar reasons. For your
own use, you might consider that you'll never receive mails from people
hosted at the same ISP as the bots you block, but doing this on a large
scale or for companies who do their business around e-mail is plain stupid.

I'm on a static IP, but a lot of people I know are not. It would be
unfair to block them from posting to, say, LKML just because the week
before, someone with their address had been sending spam. And no, it
does not help getting the problem solved since the only users annoyed
are not the ones with the faulty installation.

Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/