I’ve noticed a little spate of password attack attempts via Roundcube – a webmail program we use for mail over at https://mail.computersolutions.cn

Roundcube does have captcha plugins available which will mitigate this, but users will complain if they have to type in a captcha to login for mail.

Fail2ban provides an easy solution for this.

Roundcube stores its logs in a logs/errors file.

If I take a look at a sample login failure, it looks something like the example below

[09-Jun-2014 13:43:38 +0800]: IMAP Error: Login failed for admin from 105.236.42.200. Authentication failed. in rcube_imap.php on line 184 (POST /?_task=login&_action=login)

We should be able to use a regex like:
IMAP Error: Login failed for .* from

However fail2ban’s host regex then includes a trailing ., and fail2ban doesn’t recognise the ip.
I eventually came up with the overly complicated regex below, which seems to work:

IMAP Error: Login failed for .* from <HOST>(\. .* in .*?/rcube_imap\.php on line \d+ \(\S+ \S+\))?$

Lets add detection for that into fail2ban.
First up, we need to add roundcube into /etc/fail2ban/jail.conf

[roundcube]
enabled  = false
port     = http,https
filter   = roundcube
action   = iptables-multiport[name=roundcube, port="http,https"]
logpath  = [YOUR PATH TO ROUNDCUBE HERE]/logs/errors
maxretry = 5
findtime = 600
bantime = 3600

Note that we are not enabling the filter yet.

Change [YOUR PATH TO ROUNDCUBE HERE] in the above to your actual roundcube folder
eg /home/roundcube/public_html/logs/errors

Next, we need to create a filter.

Add /etc/fail2ban/filter.d/roundcube.conf

[Definition]
failregex = IMAP Error: Login failed for .* from <HOST>(\. .* in .*?/rcube_imap\.php on line \d+ \(\S+ \S+\))?$

ignoreregex =

Now we have the basics in place, we need to test out our filter.
For that, we use fail2ban-regex.
This accepts 2 (or more) arguments.

fail2ban-regex LOGFILE  FILTER 

For our purposes, we’ll pass it our logfile, and the filter we want to test with.

eg

fail2ban-regex  /home/roundcube/public_html/logs/errors /etc/fail2ban/filter.d/roundcube.conf  |more

If you’ve passed your log file, and it contains hits, you should see something like this:

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/roundcube.conf
Use log file   : /home/www/webmail/public_html/logs/errors


Results
=======

Failregex
|- Regular expressions:
|  [1] IMAP Error: Login failed for .* from <HOST>(\. .* in .*?/rcube_imap\.php on line \d+ \(\S+ \S+\))?$
|
`- Number of matches:
   [1] 14310 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    61.170.8.8 (Thu Dec 06 13:10:03 2012)
    ...[14309 more results in our logs!]

If you see hits, great, that means our regex worked, and you have some failed logins in the logs.
If you don’t get any results, check your log (use grep) and see if the log warning has changed. The regex I’ve posted works for roundcube 0.84

Once you’re happy, edit jail.conf, enable the plugin.
(set enabled = true), and restart fail2ban with

service fail2ban restart

Over the last few weeks, we’ve been noticing an increase on hack attempts on wordpress installs and other CMS’s (eg joomla).

Most of these attack attempts are from Russian IP space (typically Ukraine), although there are also a lot of botnet attacks from hosed windows computers also (these come from a variety of countries).

To counter this, we have been pro-actively implementing a number of different mitigation solutions, ranging from upgrading clients CMS installs and adding captcha plugins where possible to prevent brute force password attacks, through to scanning for vulnerable files throughout all clients website, and updating them to non-vulnerable versions (timthumb.php being the major issue/problem child that we’ve found to be vulnerable/exploitable).

We have also implemented server-wide lockout systems for failed logins for wordpress using one of our existing protection mechanisms (fail2ban).

Some of you may already have noticed an additional question or captcha being asked during login to your systems.

(example below)

This is for your safety – if someone hacks into an install, they typically then attempt to run additional items within an install such as malware.

We also have live monitoring for malware running on all servers, and have been quite proactive in upgrading installs which are capable of being compromised.

In the case of a site being compromised and malware being dropped into the site, our live scanner sends us an automated email and we actively investigate.

If we cannot resolve the immediate issue, and find the security hole, we disable the clients site and inform them of an issue, and the need to take further action.
(To date, we haven’t had to go that far though).

We’re not the only people seeing this, although its not well known outside of the web hosting community at this present time.

We believe in proactive solutions for these kinds of attacks, and our multilayered approach appears to have spared us from most of the problems facing others at this time.

Lawrence.

References:

http://blog.hostgator.com/2013/04/11/global-wordpress-brute-force-flood/
http://blog.sucuri.net/2013/04/protecting-against-wordpress-brute-force-attacks.html
http://blog.cloudflare.com/patching-the-internet-fixing-the-wordpress-br

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[20410]: vchkpw-pop3: vpopmail user not found www@:24.153.205.71
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 –

vchkpw-pop3: vpopmail user not found web@:24.153.205.71

A simple regex to identify that in the logs would look like this (as per the fail2ban wiki)

failregex = vchkpw-pop3: vpopmail user not found .*@:$

First step is to create a filter for fail2ban.

Create /etc/fail2ban/filter.d/vpopmail.conf as below:

# Fail2Ban configuration file for vpopmail
#
# 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 .*@:$

# 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

[vpopmail]
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:

2009-10-01 12:36:09,590 fail2ban.jail   : INFO   Jail 'vpopmail' started

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 unreachable 
actionunban = 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.