Re: SSH Brute Force not working (any longer)

["Marius Mertens" <marius.mertens@gmx.de>]

Hi everybody,

On Wednesday, July 27, 2005 6:36 PM,
curby . wrote:

> I know enough to realize that it didn't stop working just because it
> hates me: most likely, i changed something in the configuration or
> something to make it stop working.  However, I can't think of anyting
> I could have done to two different machines to make them stop working
> in exactly that same way.  Basically, every SSH attempt skips the
> return to the input chain and jumps directly to log/drop or
> log/tarpit.  I've tried increasing the --hitcount, tried rebooting or
> otherwise restarting the network service, tried using a different
> --name in recet, etc.

Well, from what your wrote I guess it suddenly ceased working. Don't worry, 
you are definitely alone. Since you mentioned that it looks like it was 
skipping the whole rule that should RETURN "good" packets, it sounds like 
you have encountered the same thing that happened to me.
I only had a closer look at your first and second ruleset example, and if I 
understand it right, the first example should always return the packets, 
since RETURN is the first rule (inverted rcheck) in SSH_Brute_Force, so the 
recent list should never receive an entry.
And I guess that in your second example the DROP rule (positive update 
check) always matches and therefore always drops, though the way I 
understand the rules, they should never match, because again the list entry 
has never been set.
If my above two guesses about your ruleset behaviour are true, then you have 
the same problem I had. Suddenly they ceased working, and the inverted match 
was always false (where it should have matched) and an added non-inverted 
match for testing with the same criteria did match, though it should have 
been the other way round.
I also tried roughly the same debugging you did, with no results. It 
happened with both a 2.6.12.1 kernel.org and a 2.6.11 debian kernel, reboot 
did not change anything, and I was unable to find out where the problem was.
What I found out was, that low hitcounts (20 or smaller) always matched a 
positive match, while high hitcounts (21 and above) never did, even after 
pushing a sufficiently large number of packets through that ruleset to have 
more than 21 entries within the last minute. So

iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 
0  --hitcount 20  -j RETURN

never returned. While

iptables -A SSH_Brute_Force -m recent --name SSH ! --rcheck --seconds 
0  --hitcount 21  -j RETURN

always returned, regardless how many packets have been processed by that 
rule within the last minute. Maybe there is a similar "critical" number of 
hits for you.
So sorry, no idea how to get rid of it, but I thought you might be 
interested in knowing that you are not the only one encountering that 
problem. The only positive about it: I finally gave up debugging it, and as 
silently as it came, the problem disappeared. Everything is working fine 
again. With a still unchanged ruleset of course ;-)
So I hope (and assume) it will silently disappear for you, too, though I 
would give quite a lot to actually find out what the hell went wrong in the 
3 days it was not working.

Good luck,

Marius