April 16, 2010

Recently we’ve been looking at ways to improve the security of our ssh login machines. From looking at our logs one thing that has become apparent is that we get endless brute force attacks searching for accounts with weak passwords. Now in an ideal world those weak passwords wouldn’t exist, of course, but we have to live with the fact that some people are better than others with their password choices. Also we certainly shouldn’t be making it easy for the attackers and servicing all their requests, if nothing else it raises the load on the servers which potentially disrupts our real users.

I’ve used fail2ban on my personal servers for a number of years without any major problems so I decided to take a look at using it for our ssh servers. The basic concept is that you have a filter which is applied to a set of log files and some actions which are carried out when failures over a certain threshold are found. This can work with any service, e.g. ssh or apache, fail2ban comes with a set of prepared filters and actions but it is relatively easy to add more.

For Informatics we are going to use one of the simplest configurations which is to watch the auth log and then put entries into /etc/hosts.deny when potential attacks are spotted. In the current configuration we consider an attack to be 5 failures to login within an 10 minute time period, that IP address then gets blocked for an hour. All addresses in the 129.215 block are whitelisted to reduce the chances of us locking out our own machines. Hopefully this won’t cause too many problems for real users who’ve forgotten their password. It’s easy enough to drop an IP block though when done this way. An alternative approach might have been to use iptables but that adds complexity and management overhead.

To help with the management of fail2ban I’ve written an LCFG component. At the moment this can just setup the main configuration file and basic jails, I doubt it would be too much work to extend it to handle new actions and filters if necessary.