iptables -I INPUT -p tcp --dport ssh -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport ssh -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 6 -j DROP

"fail2ban" does exactly what you want. And it doesn't block permanently it blocks temporally. You can configure how long it should block, and after how many failed attempts it should block. A "aptitude install fail2ban" on Debian Squeeze automatically sets up blocking for sshd. In /etc/fail2ban/jail.conf you can configure bantime (default 10 minutes).

And slow? Kidding? Its just tailing on a logfile. Even a router with some low Mhz can easily do that.

Why not disabled password login all together and use key-based authentication?

> I thought that this was too slow

This is what we call in the industry, major unsubstantiated claims.

In the slang, bullshit.

@a: That looks kinda nice. Could you elaborate on exactly how it works? I wasn't aware that something like that existed.

@Sid: The too slow argument is at the fact that fail2ban seems to use a polling based system for reading the log files, while I use a syslog callback-based method of being informed about the failed logins. I would expect a callback-based method to almost always be faster to react to an action, and not use so many resources. But I see your point that installing it on Debian is easy. The documentation on fail2ban.org doesn't make it seem that easy, though. Also, fail2ban is written in Python, and I prefer Perl. Go flame war!

@Dennis: Accepting password auth is something I like, because it allows me to just download PuTTY or any other ssh client and connect as long as I can connect to the internet and a super-restrictive firewall isn't in place. I don't even need to bring any keys with me. I do use SSH keys on the computers I normally log in from.

@Hello71: Well, I'm not writing a university paper, I'm talking about my experiments on using ipset, rsyslog and some perl code to solve something that annoyed me. If fail2ban failed to impress me at first look, I consider that a failure of communication for the project, not a failure of the project as a whole. At second look, after what Sid Burn mentioned, it seems as it isn't as complicated to setup as I thought. The fail2ban project should consider this useful input on how to atract potential new users from someone who has never heard of it before.

@All: I also wanted to try out ipset and its iptree module with automatic timeout for unbanning, as it requires less work than traditional iptables rules, because you only have to match the ip against the set (hash lookup) instead of against multiple rules (linear scanning). The use of multiple ipsets to keep state on failed logins was just my way of letting the kernel do something for me so I don't need a separate storage system with timeout features for that.

Robin,

The two IPTables lines provided by 'a' implement a hit counter in IP tables. The first line causes every NEW connection on port 22 too add one to the hit counter, and the second line causes it to DROP packets after it exceeds a threshold of 6 in 60 seconds. You also need an ACCEPT line for port 22 somewhere after it (assuming you're defaulting to dropping traffic that isn't explicitly allowed, which you should be doing).

A slightly better (more explicit and clear) way of writing it would be like this:

-A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -m recent --set --name abusers --rsource

-A INPUT -p tcp -m tcp --dport 21 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name abusers --rsource -j DROP

However, an even easier option is to replace your IPTables ssh ACCEPT line with something like this:

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m limit --limit 1/min --limit-burst 4 -j ACCEPT

This says that you'll only ACCEPT the NEW ssh connection at a rate of 1 per minute per IP address, with an initial burst of 4 packets allowed (some implementations will send multiple SYN packets initially save time if a packet gets lost) at an initial burst.

I've found this does an excellent job of allowing SSH for legitimate use, while making brute force or dictionary attacks completely infeasible.

@Christopher:

Thanks for an excellent explanation of how to solve the problem with only iptables. I'll definitely have to try it out as soon as I find some time.

Spelling error
"of of anyone"

Thanks for catching that grammar mistake.

I have been using different solution which just seems to work better then this one and is lot shorter and simpler.

it just picks lastb sorts it uniq;s it and runs iptable to drop packets. Thats lot easier and adaptive.

Hi Robin,
fail2ban uses Gamin.
How did you arrive at the conclusion that it was polling?

@Gamin: Well, if you're using Gamin (which is a subset of FAM) you're still waiting for an event that a file has been changed and then reading it, overall resulting in a pull instead of a push event flow. My method of using a syslog handler to trigger the event (and sending the data) is more push-like and might incur slightly less resources (not tested). The overall performance difference is probably negligible.