I logged into a newly provisioned VM recently to see a message that there had been 86,876 failed login attempts from a domain in another country.

Last failed login: Sat Sep 13 04:02:20 UTC 2014 from 222.186.34.117 on ssh:notty
There were 86876 failed login attempts since the last successful login.

That got me to looking for best practices on securing Linux against attacks, and looking for help from RackSpace (one of the better Cloud hosting providers). 

As an FYI, you can use the lastb command to find the failed logins, and with a little piping you can figure out the top offenders:

sudo lastb | awk '{if ($3 ~ /([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}/)a[$3] = a[$3]+1} END {for (i in a){print i " : " a[i]}}' | sort -r -nk 3 | head

In my case this showed the following IP addresses as probing my SSH:

180.96.63.124 : 8622
220.177.198.82 : 3152
220.177.198.40 : 3114
222.186.55.206 : 3012
80.82.18.145 : 2889
183.57.57.159 : 2615
61.174.51.212 : 2503
183.57.57.168 : 2501
220.177.198.39 : 2250
202.109.143.93 : 2143

You can dig or nslookup to try and figure out where these hosts are, but mostly they are just bots that don’t follow the rules in the first place.

The RackSpace support guys pointed me to a few good documents:

• http://www.rackspace.com/knowledge_center/article/rackspace-cloud-essentials-basic-cloud-server-security
• http://www.rackspace.com/knowledge_center/article/linux-cloud-server-security-best-practices
• http://www.rackspace.com/knowledge_center/article/fail2ban

I decided to install fail2ban as the first step in this process, since what it does is block IP addresses temporarily when they are doing things that look like attacks. To install (assuming you have the right yum repos set up), you just run the command:

yum install fail2ban

Once it is installed, you just enable the service, and the default configuration protects you from a number of attacks (including the SSH brute force login hack I was seeing).

It’s a good idea to update the jail.conf parameters that send email, so that you’ll get notified on these sorts of failures. That way you know when somebody gets locked out, and can see if it is an actual attack or just a forgotten password.

Testing is pretty simple: just fail logging in a few times in a row, and you should get a “connection refused” on the fourth try. You can try again in a few minutes, since fail2ban only adds the rule to the firewall temporarily (I believe it is 5 failed logins will block for 5 minutes by default).

Next I needed to add a rule that is not included with fail2ban directly: I wanted to do the same thing for my WordPress site (I actually had some lame hacker sneak into a WP installation a year or so ago, and had to rebuild the whole server to get rid of the nefarious code).

Whipping out my trusty Google search, I found a few different ways to watch the WP logins, and settled on using a simple regex.

First I created a filter in the /etc/fail2ban/filter.d folder (naming it apache-wp-login.conf):

# Fail2Ban configuration file
[Definition]
failregex = <HOST>.*] "POST /wp-login.php
ignoreregex =

Next I created a jail.local file in the /etc/fail2ban folder:

[apache-wp-login]
enabled = true
port    = http,https
action   = iptables[name=WP, port=http, protocol=tcp]
filter  = apache-wp-login
logpath = /var/www/vhosts/system/*/logs/access_log
maxretry = 3

The above rule tells fail2ban to watch the system access logs for repeated logins, and will block the IP after 3 successive failures within 5 minutes. So if somebody tries to login (which for my sites is only used for content authors and admins) and brute force the site, they will get blocked for 5 minutes.