DenyHosts: Automated SSH Brute Force Response System

Posted by admin on September 2, 2007 under Tech Tips | 4 Comments to Read

DenyHosts SSH

DenyHosts is a project that adds a protective layer to an SSH server by automatically blocking malicious hosts that use brute force or dictionary attacks. If you have SSH services enabled and accessible from the internet, you will likely have thousands of failed login attempts from several sources within a very short period of time. DenyHosts monitors all login attempts, and based on a customizable rule-set can block hosts from making further connections if an attack pattern is matched.

Using tcp_wrappers, the DenyHosts service elegantly manages entries in the /etc/hosts.deny file, adding and removing hosts when thresholds are crossed. e.g. Three failed logins with unknown user accounts; Three failed logins with root account; Five failed logins with known user accounts; Unblock host after a set period of time; etc. You can also specify whether DenyHosts blocks access to SSH or ALL services, thereby mitigating any other attack vectors the offender might try next.

A most valuable feature that makes DenyHosts even more attractive is the optional centralized reporting system. The service can be configured to report all abusive hosts to the DenyHosts collection server, and automatically import a list of IP addresses that others have reported. This network of intelligence gathering and incident response helps to thwart a large number of attacks before they happen, because the attackers (most of which are automated bots) are blocked before they have a chance to move on to other protected servers.Other useful features include email notification when hosts are blocked, and counter resets after successful authentication to prevent accidental blacklisting caused by fat fingered admins. :-)

For those of you using Ubuntu 7.04 (Feisty Fawn) and above, it is available in the Universe repository:

sudo apt-get install denyhosts

Edit and customize /etc/denyhosts.conf for your desired options, and restart the service:

sudo /etc/init.d/denyhosts restart

Ubuntu 6.06.1 LTS will need a manual installation, as it is not included in the repositories.

Be sure to check out the project at http://denyhosts.sourceforge.net.

Be Sociable, Share!

Comments

  • jeffatrackaid said,

    I used to use denyhost (and even supported them for a bit), but I’ve found that log analysis tools are subject to exploit. Attackers can use a tool like netcat to inject strings into your logs. These strings then get picked up by tools like DenyHosts and other log scanners. When they pick up these strings they block the IP supplied by the attacker.

    I’ve since turned to using IPtables to rate limit connections.
    http://www.rackaid.com/resources/how-to-block-ssh-brute-force-attacks/

  • gmendoza said,

    I do agree that rate limiting provides a very simple method of reducing risk of brute force attacks. However, simply rate limiting new TCP connections is not the best solution to the problem.

    1. By only looking at new connections, the scripts or attackers can attempt to enter a password up to the configured “MaxAuthTries” value configured on the ssh server. e.g. If the server is configured for 5 password attempts (5 is the default), multiplied by the number of new connections, you get 15 password attempts in a minute time frame. While a far cry from 100’s or 1000’s of password guesses, it still too many to be considered best practice IMO.

    2. Rate limiting based on new connections doesn’t have the added benefit of distributed behavioral pattern analysis. DenyHosts for example obtains many thousands of reports on offending IP addresses from it’s many thousands of clients around the globe. This list is not simply “ever growing”, as there are configurable rules regarding entry tolerance and lifetime.

    3. I agree that log analysis tools provide the platform for “potentially” one attack vector, as long as the application (in this case openssh) sanitizes log output, this risk is fairly low. Plus, new connections from repeat offenders are blocked by the systems tcp wrappers, reducing the risk even lower since most connections are simply refused.

    4. Both Log Analysis tools like DenyHosts simple IPTables rate-limiting do not prevent zero-day attacks against vulnerable openssh servers. A much more secure method of protecting against application layer attacks is not even allowing ANY connection up the stack until the client has been authenticated by crypto system. For that I recommend Fwknop for “Single Packet Authorization”.

    http://cipherdyne.org/fwknop/

    No crypto authentication, the port doesn’t even respond as being open. Thanks for your comments. I also enjoyed your site.

  • jeffatrackaid said,

    Good points.

    1. I need to update one of my ssh posts. I typically set MaxAuthTries to 1 or 3 depending on the system to help with this. When possible, I get rid of password auth completely.

    2. I suspect the distributed monitoring is not as effective as people think. Yes, it sounds great but how many attacks do you actually block due to the pooled list? I used to use Dsheilds in the capacity and stopped as I found it helped with less than 1% of the hits on a pool of 50 servers. I would love to see numbers on this but based on my own observations these distributed tools on the scale of DenyHosts are of limited value.

    Now, I am a big fan of collating data within your own environment. I’ve had great success with that approach due to the sequential scanning nature of many bots.

    3. In case, I missed citing it, here’s a good reference on attacking log tools:
    http://www.ossec.net/main/attacking-log-analysis-tools
    The point is that ssh does not sanitize log output, so using log analysis tools can introduce new vulnerabilities.

    4. For those environments, I just use VPN and lock out public ssh access completely.

    Don’t get me wrong, I like the concept of denyhosts, fail2ban and similar items, especially for shared hosting environments where end-user control is not well monitored. However, when these tools turn a potential security issue, e.g. weak password, into a known exploitable issue, I tend to leave them off of my systems. For example, what if I spoof your DNS resolvers, google’s IPs, hotmail, etc. Targeting these IPs with injections could have serious impact to your operations.

  • jeffatrackaid said,

    I found it … here’s an old post about using botnets to defeat rate based tools.
    http://www.theregister.co.uk/2008/12/08/brute_force_ssh_attack/

    This get’s past both iptables and denyhost type approaches since they can trickle in the attacks from various bots. And your right that’s when port knocking and fwknop come in handy.

Add A Comment