Re: problem with recent match
On Fri, 10 Mar 2006 13:07:50 +0100
martin f krafft <madduck@madduck.net> wrote:
> I am somewhat baffled by a problem with a bunch of my machines.
> I use the following rules there to limit SSH brute force attacks:
>
> -A INPUT -p tcp -m tcp --dport 22 -j ssh-tarpit
> -A ssh-tarpit -m recent --name ssh_tarpit --set --rsource -j
> ssh-whitelist -A ssh-tarpit -m recent ! --update --seconds 60
> --hitcount 8 --name ssh_tarpit - -A ssh-tarpit -j LOG --log-prefix
> "[SSH flood] " -A ssh-tarpit -p tcp -j TARPIT
> -A ssh-tarpit -j DROP
> -A ssh-whitelist -s 1.2.3.0/24 -j ACCEPT
>
> This used to work, and I still have a machine or two where it works
> just as I want it: 8 connections per minute, if exceeded, you have
> to wait for a full minute before trying again (update instead of
> rcheck).
>
> The problem now is that I cannot log in from anywhere anymore,
> except for the whitelisted hosts. If I check the kernel output on
> the machine, I see the SSH flood log entries generated by the LOG
> line even for the first connection attempt.
Sounds like you are experiencing the timer overflow bug in
ipt_recent. On 32bit machines with HZ at 1000 (the default in 2.6),
you'll hit the bug after ~25 days of uptime. This could explain why
you're only seeing this on some of your machines.
There are a couple of workarounds available [1] [2], but
the consensus from the Netfilter maintainers is that a full rewrite is
needed.
[1]
http://blog.blackdown.de/2005/05/09/fixing-the-ipt_recent-netfilter-module/
[2] http://www.kd.cz/~martin/kernel-recent/
--
Adam James
Reply to: