04 Sep 09 Denyhosts: SSH Brute Force Protection
I’m always very uneasy when I look through my web server and system logs. It seems dozens of people (or more!) a month try to log into my server, attempt an SQL injection attack on one or more of my hosted websites, and probe for weaknesses. It really makes me lose some faith in humanity.
I was tipped of to the Denyhosts script via a tweet from @dozba. This is nothing more than a Python script that analyzes your ssh log file, looking for suspicious activity. It monitors the number of failed SSH login attempts over time, and once a configurable threshold is reached, it adds the IP address of the remote host to your hosts.deny file, thus blocking the brute-force break-in attempt. The script is very configurable. It can have different thresholds for login attempts to existent or non-existent user accounts, it can purge blocked entries, and it will email you when it blocks a host.
Installation and configuration on Ubuntu is a breeze, as it is available as a package. Use your favorite package manager and install it. Ubuntu automatically configures it to run in daemon mode, so you won’t need to mess with cron. Configure it by editing the file /etc/denyhosts.conf. Restart the daemon, and then you are done. In a nutshell:
$ sudo apt-get install denyhosts $ sudo vi /etc/denyhosts.conf $ sudo /etc/init.d/denyhosts restart
Two days after I installed it, I had already blocked 5 break-in attempts. Thanks to the author Phil Schwartz and the Ubuntu package maintainers for this very useful utility!
Reader's Comments
Brian, just came over here again from your FB post on server monitoring and ran into this article. I have since added you to my Google Reader… not sure why I hadn’t previously.
Anyways, I get concerned with scripts that have to run as root (yeah, I know technically, this could be run as a different user, but that could take quite a bit of work to figure out). Have you reviewed this code just to make sure it is “legit”?
I don’t know Python, so just wondering if you’ve taken a look at it. I know, I know, I’m a worry-wort. LOL.
Hi Montego!
Yes it is true the script runs as root. It pretty much has to at some point in order to update /etc/hosts.deny.
I certainly didn’t perform a security review of the code, but I did skim it out of curiosity to see how it works. I’m perfectly fine with running it, as it exists in the official Ubuntu and Debian package repositories. So I’m relying on those communities to have vetted it. It has also been around since at least 2005 or so and is a pretty well known tool.
Since I have installed it, it has blocked 31 attacks in just a few weeks. I’m very grateful for it.
These are good points that you have made and they have allayed my concerns.
Actually, the only hurdle that I see to running this as a different user is the need to have read access to the /var/log/secure.x log files. Since these are usually rolled by the log roller, I wonder if they are deleted and re-created or just overwritten. If overwritten, then it would just be a matter of setting the permissions once (and possibly “touching” as many revisions as will need)… don’t know.
To get around the write to host.deny, one can actually use a different deny file.
Here is the FAQ on running DenyHosts as root: http://denyhosts.sourceforge.net/faq.html#3_1
The Ubuntu package configures DenyHosts to run in daemon mode, so it is running as root. You could however change this and have cron execute DenyHosts periodically.