Slightly advanced, but note that you CAN block in progress connections using iptables
What is happening is that the usual top (ish) rule in your iptable script says something like "continue if connection established", this can be seen as a performance optimisation to avoid running your full rulebase after the connection exists, however, it's not a limitation of iptables. So you have two main ways to tackle this:
Add your blacklist rules *before* the continue rule. One of the fastest/simplest ways to achieve this is with the new ipset functionality of recent kernels. You can then have a single iptables (block) rule, which references a dynamically updated ipset that contains all your blacklisted IPs. Curiously ipsets can have a timeout value which appears to cause entries to fall out after a set time period. Requires some changes to the "actions" in fail2ban
Alternatively note that you can purge specific connections from conntrack (subsequent packets will either be treated as "invalid" or "new" depending on whether you have loose tracking set in /proc/sys/... Something like "conntrack -D -n a.b.c.d" should do it? This still requires some tweaking to fail2ban, but the iptables rules stay the same
Just saying...
Good luck
Ed W
On 26/08/2011 13:22, Felipe Scarel wrote:
Yeah, I had read about half of that thread, and after I sent my mail kept reading and stumbled upon this: "(...) using the recent module needs dovecotto close the connection upon authentication failure, as iptables only (normally) comes in to play for new connections (...)".
So, yeah, my suggestion probably won't work.
On Fri, Aug 26, 2011 at 09:15, Felipe Scarel fbscarel@gmail.com wrote:
Alex, I've not personally done it (so just speculating here, bear with me) but you can customize Fail2Ban's actions if needed. So, if you can match the attemps through some regex (and since you're seeing them in the logs, that should be quite possible), then you can edit one of the 'actions' to drop the connection for <ip>.