I'm really starting to like fail2ban. It just when through a major overhaul, and while I was pulling my hair out for awhile trying to figure out the new layout, it makes a lot of sense. I'm adjusting my custom rulesets to the new layout. These are designed to prevent continous dnsrbl rejects, unknown domain rejects, and brute force attempts to send spam, all from the same IP. Will they ever learn? Doubtful.
Here's what I've come up with:
/etc/fail2ban/filter.d/pstdns.local:
failregex = NOQUEUE: reject: RCPT from \S*\[(?P<host>\S+)\]: 554</host>
/etc/fail2ban/filter.d/pstdom.local:
failregex = NOQUEUE: reject: RCPT from \S*\[(?P<host>\S+)\]: 450</host>
/etc/fail2ban/filter.d/pstnorcpt.local:
failregex = NOQUEUE: reject: RCPT from \S*\[(?P<host>\S+)\]: 550</host>
I'm going to submit these rules to the debian maintainer to see if they are interested in using them.
Important thing to note here, is that the first one is based upon using realtime black lists to block proxy and open relays, which are infamous for sending spam. There are a few amazing free services, like sorbs, which provide this service. My thoughts are that an IP will likely get blocked for longer than an hour, or even a few, so it doesn't make sense to simply keep querying the dnsbl to ask if the ip is blacklisted. Therefore, if it is blacklisted, and the offender keeps trying because their bot is too dumb to give up, then their packets get dropped. Logical? I think so.
The other rules for non-existent "from domains" and recipients have to be much more lenient, but still help the worst offenders.
My email to the package maintainer:
Hi,Here are some rules I use on Debian for fail2ban to block relentless spammers. This is not for protection against password crack attempts, but more for reducing traffic and generally blocking bad ips. I've posted more information here:
Thanks,
Docunext Staff
¥