# RootPrompt.org   Nothing but Unix.[Home] [Features] [Programming] [Mac OS X] [Search]


 DenyHosts, an SSH Server Attack Denial Tool

Every once in a great while I run across a very useful tool whose simplicity amazes me. One of those tools recently hit my radar after I noticed several failed SSH login attempts to my machine. Apparently someone had plenty of time to try to login, and was not deterred by repeated login failure. That set me on a course to find a solution that was simple, effective and enough of a barrier to the attacker that they would move on out of frustration, or simply be denied enough that they would find easier targets.

 (Submitted by Chuck Talk Mon Jun 6, 2005 )

  That search led me to find DenyHosts, a simple and elegant solution that works with a minimal configuration effort and is small, quick and clean. The ease of installation and operation make this an effective solution to annoying SSH attackers, and one that you should consider if you are using SSH services.

In order to be certain that you can use DenyHosts, you need to ensure that sshd has been complied with tcp_wrappers support. This is the default for most modern Linux distributions, but if you aren't certain, the following test will help you quickly determine if the script will work for you:

1) Login, as root, to your Linux system containing the sshd server.
2) Edit the file, /etc/hosts.deny
3) Add the following:
$ sshd: 127.0.0.1
4) Save the file
5) Attempt to connect to the local sshd server:
$ ssh localhost
6) You should see the following ssh error message:
ssh_exchange_identification: Connection closed by remote host

Congratulations! If the above error message was displayed, then sshd has been compiled with tcp_wrappers

If your client connects to the sshd server, then your sshd has not been compiled with tcp_wrappers, and DenyHosts will not work as expected.

7) Edit the file, /etc/hosts.deny
8) Remove the line that you added earlier (eg. sshd: 127.0.0.1)
9) Save the file


I tested this on my latest SuSE Linux Professional 9.3, and it does work as expected. You should be able to run this script without any problems, though you will need to perform some slight configuration adjustments to the config file for DenyHosts. In addition, you will need to have Python version 2.1 or greater, installed on your machine in order to use DenyHosts. My SuSE Linux install is currently running Python 2.4.14, and meets the requirements. Your mileage may vary (YMMV), so be sure to check what version of python you are running before attempting to use DenyHosts.

In order to run DenyHosts, you will need to download the source file from the SourceForge project page, and I would recommend the latest version (0.60 as of this writing) for use in production environments. DenyHosts is stable and operational, so don't be fooled by the version number. This is open source software after all, and version numbers mean less than they do in the proprietary world.

Setting up DenyHosts is a realtively straightforward process. On SuSE, I chose to install the program in the /opt directory, though you may install it in /usr/local or /usr/share for another distribution. The program is realtively small, and it should be simple enough to unzip:

#($some dir) tar -zvxf DenyHosts-0.6.0.tar.gz

This will have the effect of unzipping the files to the correct directory structure and leave you with the denyhosts.py program executable where you chose to install DenyHosts.

Before you can use the denyhosts python program though, you will have to examine the denyhosts.cfg-dist file, which is the configuration file for denyhosts. The file does have some minor tweaks that need to be adjusted prior to using it oin SuSE Linux 9.3.

1) First, comment out the RedHat SECURE_LOG file location by placing a '#' in front of the SECURE_LOG variable for RedHat
2) Second, uncomment the SuSE SECURE_LOG variable for /var/log/messages
3) You must decide how you wish to treat the offending host - either by blocking only SSH or ALL services in the BLOCK_SERVICE variable. Uncomment your choice and comment out the variable you decide not to use
4) Next, decide on the acceptable DENY_THRESHOLD variable for the number of failed login attempts that you wish to consider for denying services. The standard setting is for five attempts, but you may choose more or fewer attempts, depending on your personal choice.
5) Next, you must decide where your working directory for sll activity will be located. If this directory does not exist, you will need to create it, as it cannot be skipped - it is a MUST HAVE in order for denyhosts to work correctly.
6) I reccomend that the SUSPICIOUS_LOGIN_REPORT_ALLOWED_HOSTS=YES variable remains intact as is.
7) Next, you can choose whether or not to perform HOSTNAME_LOOKUP to determine if the corresponding hostname should be looked up when denying services. If the hostname is available, this can aid in determining the source of the offending attacker.
8) Finally, I do reccomend that the Deny Hosts report be mailed to root for further review. If the tools isn't reporting to you any activity - then what is the point of having the tool in the first place?
9) Save the file after you have made your choices for modification.

Now, you can go to the directory where DenyHosts-0.6.0 was installed and run the program by typing in:

#($PWD)/./denyhosts.py

If everything is working as expected, you should be returned to the prompt without comment on STD OUT.

You can set this up to be run at every boot (and I do recommend that be done as well), and be certain that every time your machine is restarted and the SSH service is made available, that the denyhosts python program is blocking access to unwanted service hijackers.

SSH is a useful tool to have, but some people will try to take advantage of any service, simply because they lack sufficient motivation to be deterred. They usually have a vested in interest in gaining control to run their spambots or other malicious tools. The only solid solution is to deter them as much as possible. No solution is one hundred percent secure, except not to be a part of the network, and that simply isn't an acceptable answer.

Stay safe out there, and keep on computing. The open source world offers many elegant and simple solutions, but no solution is an absolute. It is merely another tool that is available to you, and what works best for you may vary depending on your experience. Thanks to Phil Schwartz for this excellent python program. I do appreciate it!


Our content can be syndicated: Main page Mac Page

Copyright 1999-2005 Noel Davis. Noel also runs web sites about sailing and kayaking.
All trademarks are the property of their owners.
All articles are owned by their author