linux-kernel - Re: [ANNOUNCE] Kernel Blocking Firewall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 Jan 2009 10:09:56 +0100
From:	Willy Tarreau <w@....eu>
To:	jmerkey@...fmountaingroup.com
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] Kernel Blocking Firewall

On Fri, Jan 09, 2009 at 01:15:06AM -0700, jmerkey@...fmountaingroup.com 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/