APF, fail2ban & more

APF is wonderful for a good-enough firewall solution for a lot of people. But what if you also want the power of another great tool, fail2ban?

The problem is, fail2ban wants to make changes directly to iptables, which APF is maintaining. Rules that fail2ban writes will be overwritten by APF. I found the solution is pretty straightforward: fail2ban with APF. This works really well.

No, I still didn’t think it was enough. Why? Because the “gamin” backend of fail2ban is buggy on Debian / Ubuntu, and tends to stop working after some time. So, I use the polling backend, which means it seems to wait about 30 seconds or so between checks of the log files. Today I saw a very persistent bot become unbanned and immediately get banned again, about 30-40 seconds later. How many attempts had it made on the SSH server while unbanned? I didn’t even stop to check, I just wanted to find a way to react more quickly.

Search for “limit connection rate linux” or whatnot on the Googs and you’ll find a number of sites with basically the same solution. It looks like this:

This works well if you’re manually (or using home-brewed scripts) to tamp down the baddies. But again it’s modifying iptables directly, which we don’t want. A couple more searches yielded a promising page that said to add any custom rules you need to APF’s postroute.rules file. However, using the plain -I or -A options to iptables without a line number doesn’t work right, since the order of rules, and what happens at the top and bottom of a ruleset are significant. So we need to add the rules just above the first blanket SSH ACCEPT rule. Here’s what I did in postroute.rules:

Notice that I also added the --name option, to prevent a conflict with the default name that APF uses.

APF, fail2ban & more is original content from Devolve.

Author: Charlie Herron

Denizen of Portland, Maine; tech jack; lover / hater / whatever; philosophical dabbler. http://twitter.com/realgeek