As the Wiki for fail2ban is a little less than explanatory than it could be (and they reversed my edits which made the instructions clearer), here are my own notes on setting up fail2ban to block pop3 attacks.
Have been seeing sample dictionary attacks on some servers for a while now from random ip addresses – eg
Sep 28 13:01:03 www vpopmail[20411]: vchkpw-pop3: vpopmail user not found web@:24.153.205.71
Sep 28 13:01:09 www vpopmail[20417]: vchkpw-pop3: vpopmail user not found web@:24.153.205.71
Sep 28 13:01:11 www vpopmail[20420]: vchkpw-pop3: vpopmail user not found web@:24.153.205.71
Annoying, but not realistically going to provide much of a security issue – most of the user names are the generic ones which aren’t actually in use on the servers.
As we already use fail2ban to perform basic service blocks against naughty script kiddie wannabee’s, why not have it block vpopmail attacks also.
Our mail error logs are located in /var/log/mail.log
As you saw above, the logs show the same common text for each failed login –
A simple regex to identify that in the logs would look like this (as per the fail2ban wiki)
First step is to create a filter for fail2ban.
Create /etc/fail2ban/filter.d/vpopmail.conf as below:
#
# Author: Lawrence Sheed
#
# $Revision: 1.0 $
#
[Definition]
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile.
# Values: TEXT
#
failregex = vchkpw-pop3: vpopmail user not found .*@:<HOST>$
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
Second step is to add our filter to the fail2ban setup
Add this to the bottom of /etc/fail2ban/jail.conf
enabled = true
port = pop3
filter = vpopmail
logpath = /var/log/mail.log
maxretry = 3
logpath should be amended to whatever your mail logs for vpopmail appear.
maxretry should be set to a value that you agree with.
Restart fail2ban with a: /etc/init.d/fail2ban restart
and check that it has added the filter.
tail /var/log/fail2ban.log
You should see a line like this:
If so, you’re all set!
Some additional tips, as I have found some issues subsequently in Fail2ban on some systems:
If you find that fail2ban gives error 200 or 400 on occasion, this is due to a timing issue bug in fail2ban.
There are 2 possible solutions:
Solution 1 – Edit fail2ban
Open /usr/bin/fail2ban-client
Look for
def __processCmd(self, cmd, showRet = True): beautifier = Beautifier() for c in cmd:
After for c in cmd: add a delay
time.sleep(0.5)
This should look similar to this now –
def __processCmd(self, cmd, showRet = True): beautifier = Beautifier() for c in cmd: time.sleep(0.5)
Save, and restart fail2ban. If you still see 200 or 400 issues, increase the delay higher e.g. time.sleep(0.8)
Solution 2 – Use a different block method
Instead of iptables, we can configure fail2ban to use route
Add a config file for this:
pico /etc/fail2ban/action.d/route.conf
Add this into the file and save it.
# Fail2Ban configuration file [Definition] actionban = ip route add unreachableactionunban = ip route del unreachable
Open /etc/fail2ban/jail.conf
Look for ban action = … in the [DEFAULT] section, and comment it out with a # at the start of the line
then add
eg
#banaction = iptables banaction = route
Save the file.
Restart fail2ban
It will now use route to block bad ip’s.