fail2ban & i like Debian
Few weeks ago i was Googling for some solution to block ssh bruteforce attacks dynamically generating firewall rules. The first thing i’ve tried was iptables -m recent. A pretty straightforward tutorial could be found here. But it didn’t suite, as it blocked ALL ip’s after any n connection, successful or not. It meant, that i could open only n shells to a remote host. For me it seemed annoying. Increasing n leads to usefullness degradation of this method, so i switched to the alternative one - sshguard.A review/HOWTO-INSTALL is here. Doing all the steps like in review, i’ve got it worked.
Then i saw an authors notes about a linux.com’s review mentioned before. And i realized, that i was going the wrong way. I’ve done all steps like described in the author’s documentation, and went testing. Nothing worked. In next 1.5 days i doublechecked configs, realized that it doesn’t work and i need to come back to the first method and upgrade it so it would be more reliable to crashes.
I’ve written a 5-lines script, which checked whether sshguard is running now and started it if it wasn’t. This was inserted into cron, then i tested it. It worked, and in a bit of time this setup was copied between all servers running Debian. As long as i tried, sshguard refused to work on Redhat servers, seems like it’s beacuse it didn’t matched log entries with it’s built-in regexps.
I was really happy after finishing. I really don’t like software that doesn’t report anything about it’s current state, whether it is error or not. sshguard is of that kind.
A week passed, we switched from syslog to syslog-ng, just because we wanted php-syslog-ng. As always, a tutorial is here. It’s setup was an easy thing really, just completed all steps in the tutorial on one server, and then used puppet to create a template and implement this setup on other servers.
The next day i read a logwatch report and my eyes widened…. few hundreds of ssh authentifications failures! I ran testing sshguard - it didn’t work! 
Spent about half an hour trying to figure out why - the only reason i see is that syslog-ng log entries format differs from syslog format. But really it is something hardly to believe, especially if sshguard uses regexp’s. No time to waste, went on Googling for another solution.
And here comes fail2ban. Quickly looking through it’s wiki pages, i decided to try it on one of our servers.
apt-get install fail2ban, ssh to that server from my home desktop, 6 login failures and … YES, I’ve got BANNED. The first time in my life i was banned and was really glad about itv 
. Added 3 lines to puppet manifest, triggered my remote servers and in about 15 minutes i’ve got 8 servers protected from ssh bruteforce attacks and a template to setup this on any new server running Debian. Pretty cool, right?
So, conclusions:
- if you want to protect from ssh bruteforce attacks, you have 2 efficient ways - iptables -m recent + ssh keys + disabling passwor/challenge-response authentification methods in sshd or fail2ban or smth like it (but i really like this tool);
- if you choose software, pay attention to it’s development line, its activity and progress - this values are sometimes more valuable then 3%(maybe more or maybe less) performance gained by rewriting a tool from script language into C/C++, especially when using open-source(and we are using
);
- the meaning of a distro, IMHO, is that it ships (binary) packages, which are ready to use, up-to-date with stable versions and with proper DEPENDENCIES automatically installed if needed. And this packages include some templates of configs or at least one config, which is not a default one of a software packaged(which is also included), but the most commonly used be people, who configured this software for their needs. So when you setup a package, especially a rather simple and one-task, you can hope that it works “from the box”. This case was with fail2ban, and this is the real power!
Thanks to guys, who keep Debian alive and well!