[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 -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

[2] http://www.kd.cz/~martin/kernel-recent/

Adam James

Reply to: