How to category Design category Development category News category

A simple way to help protect your web and mail servers from hackers


There are many rules of thumb about managing server security from password policies to firewall configurations, ultimately however there are always going to be those who try dictionary attacks and probes for vulnerable scripts.

The background…

Our servers have been busy fending off failed IMAP, SMPT and POP3 connections for mail along with the dirge of “file not found” reports in the error log where spammers are looking for various open source software exploits (old phpMyAdmin and phpBB Forums to name a couple)

Despite a strict needs based approach of firewall configuration some services have to be exposed to the big wide world.

We started to wonder if there was a systematic way to block some of these hack attempts at the servers firewall temporarily.

Introducing Fail2ban

Fail2Ban is a log processor which uses RegEx Filters to scan various logs and perform custom Actions when these expressions find matches.

To get up and running with Plesk – you need to install Fail2Ban and configure it to play nicely with Plesks log structure.

Install Fail2Ban with:-

yum install fail2ban

Install whois (fail2ban uses it)

yum -y install jwhois

Fail2Ban sets up what’s called a Jail for each log. Matches are found that fit the criteria in your jail.conf file (note – Fail2Ban ships with .conf files but you can make your own .local versions and they take precedence. This prevents customised configurations being overwritten during upgrade)

Fail2Ban ships with lots of Jails but many didn’t work or apply to our Plesk servers. We only enabled jails that were relevant to us.

During setup, we tested each jail by manually checking the RegEx expressions against the intended log files. This involved a little reconfiguration.
For our servers the mail logs are actually at:

Our jails are configured just for mail only – see discussion for why this is sufficient to our server configuration.

# Jail for SMTP hack attemtps
enabled = true
filter = sasl
action = iptables[name=sasl, port=smtp, protocol=tcp]
logpath = /usr/local/psa/var/log/maillog
maxretry = 5
bantime = 300

# Jail for POSTFIX mail hack attempts
enabled = true
filter = postfix
action = hostsdeny
logpath = /usr/local/psa/var/log/maillog
bantime = 300

# This jail blocks bad IMAP logins
enabled = true
filter = courierlogin
action = iptables-multiport[name=courierimap-iptables, port="110,995,143,993"]
logpath = /usr/local/psa/var/log/maillog
maxretry = 6
bantime = 300

So… these are our 3 jails. We also need to configure the Filters as the RegEx patterns they contain probably wont suit our servers setup. Taking each in turn:-

  1. Filter sasl.local Note – this is customised (hence .local) the fail text looks pretty weird but I checked our logs and that’s exactly how these are getting logged!

    failregex = : warning: [-._\w]+\[\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: authentication failure$

    Test it with:

    fail2ban-regex /usr/local/psa/var/log/maillog 'warning: [-._\w]+\[\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: authentication failure$'
  2. Filter postfix – the standard Fail2Ban Filter is fine.

    Test it with:

    fail2ban-regex /usr/local/psa/var/log/maillog 'reject: RCPT from (.*)\[\]: 554'
  3. Filter courierlogin.local
    Note – this is customised (hence .local)

    failregex = LOGIN FAILED, ip=\[\]$

    Test it with:

    fail2ban-regex /usr/local/psa/var/log/maillog 'LOGIN FAILED, ip=\[\]$'

If ANY of these Filter tests don’t product matches – then be suspicious they are wrong. Look at the log file and check your RegEx. Or maybe you never receive this kind of attack!


All these tests on produced matches and in our first day of running – we had postfix matches coming through over night.

Further development

Our servers are firewalled on a needs basis with only mail and web ports open to the world therefore SSH wasn’t a great concern so the ssh-iptables Jail defined in the standard jail.conf file and in our jail.local were not required in our case.

We’re not doing any Apache log processing. I thought quite a bit about this and came to the following conclusions about it:

Each domain logs separately and they’re not all on daily rotation so we might be giving Fail2Ban a lot to work to do considering the volume and size. As a future step we may consider standardising on 1 day log rotation.

We have an increasing level of HTTP AUTH protection in place, particularly for giving a secondary layer of protection to some of the open-source packages we use. We will explore centralising the logging of HTTP AUTH failures and or tweaking log size in the future also.

Have fun with Fail2Ban!

Comments are closed.