Blocking SSH brute forcing using denyhosts
David | January 7, 2010Tired of seeing repeated attempts to login to a Linux server you run? There are a number of options, all with their own benefits and disadvantages. The easiest way is to move the port that the SSH server runs on, perhaps to 2222 instead of 22. However. this can be annoying behind some firewalls and means that you need to specify the port each time you SSH to a host. This post looks at denyhosts, a viable alternative.
denyhosts will monitor your authorisation log (typically /var/log/auth.log) and ban IPs that repeatedly fail to authorise as a genuine user. It will deny future logins by adding the IP address to /etc/hosts.deny.
On a sensible Debian or Ubuntu install, getting denyhosts is as simple as running:
1 | $ aptitude install denyhosts |
denyhosts should work as soon as it is installed. However, a few options can be tweaked to make it work nicely. The configuration file is at /etc/denyhosts.conf.
Firstly, set a proper administration email by changing ADMIN_EMAIL. The option RESET_ON_SUCCESS might also be important to you, by setting it to yes the failure count for an IP address will be reset if there is a successful login. If you want the blocks to expire (which is more important if you use synchronisation) then you should tweak PURGE_DENY to a sensible value, for example 1 week.
Synchronisation is one nice feature of denyhosts that means that information on IPs that attempt SSH bruteforcing can be shared between servers. Information about synchronisation can be read in the FAQ but enabling it is as simple as uncommenting the SYNC_SERVER line. By default, your server will share information on bruteforcers and receive it from other administrators who run denyhosts.
You can check how denyhosts is working by watching the logfile at /var/log/denyhosts. You can see newly added blocks logged as a line like the below:
new denied hosts: ['202.107.228.xxx']
Of course, you don’t need this as you’ve already disabled SSH password logins and your firewall disables access to port 22 from anywhere except a specially crafted list of IPs. But for 5 minutes work, it provides some peace of mind.
Hi David,
Nice article. I also use DenyHosts on my servers, as you say for the minimal effort involved in setting it up, it really is worthwhile.
You mention one security by obscurity measure of changing the SSH service port from 22 to something else, but then needing to specify the port when connecting. Don’t forget you can add an entry to the SSH client configuration file (e.g. /etc/ssh/ssh_config) such as the one below to specify an alternative port. Issuing the command “ssh server.keyboardcat.com” will now automatically use port 2222.
Regarding setting the ADMIN_EMAIL variable, I personally leave this “commented out”. There is no option in the configuration to summarise updates to weekly or monthly intervals, and I got tired of daily emails with a couple of new IP’s in it. Alternatively, I have used a Munin plugin script to graph the DenyHosts ban list (http://www.tjansson.dk/?p=717) to keep tabs on the volume of attacks.
Optionally, the administrator can modify the BLOCK_SERVICE parameter inn the configuration file from “sshd” to “ALL”. This means an IP attempting an SSH bruteforce will not only be banned from access to the SSH service, but also to any other system services using TCP wrappers. As an aside, note that Apache2 will not use /etc/hosts.deny by default (on Ubuntu server at least).
Another optional step to consider is adding your management IP address (if it is static) to /etc/hosts.allow just to ensure you don’t accidentally lock yourself out.
RB