dcsimg

Got Security? You’re in Denial

Do you think your systems are secure? Install DenyHosts and you'll realize that you were in denial.

Exposing a system to the Internet means that you’ll soon (within hours) experience login attempts from random locations, from people you don’t know and from those with unclear motivations. DenyHosts is an SSH security tool in the form of a python script that helps prevent brute force and dictionary-based attacks against your systems. On my home system, I have at least one such attempt added to my /etc/hosts.deny file per day. I use DenyHosts to maintain that stealth watch over my insignificant system here in my dusty little corner of the Internet that I call home.

It amazes me to note how many hack attempts (806) I’ve had in the two years since I first installed DenyHosts. No, I don’t think I’m singled out, since no one could possibly know my ever-changing IP address with which to launch such an attack. I think that hackers script their hack attempts against entire IP networks and probably have an email notification alert them when they strike paydirt.

Installation

There are two ways to install DenyHosts on your system: from source and from package. Call me lazy but I prefer the package route over source anytime. Dependencies download with my package of choice and installation is automatic. Source installations often require me to seek out multiple dependencies that sometimes drag on for a day or two until I give up or try the installation on a different Linux distribution. My sage advice is to try your package manager first.

Package installation is simple. On my beloved Debian 5 system, I used:

$ sudo apt-get install denyhosts

The package search and download started in the usual way so I turned my attention elsewhere for a moment. When I glanced back at my Debian screen, the installation had completed and DenyHosts started. To my surprise, the latest version, 2.6.4, began protecting my system from unwanted SSH attacks without any intervention or assistance from me.

If you have to, or prefer to, use source for your installation, download the tarball from DenyHosts Downloads. Unzip, untar and cd into the DenyHosts source directory and issue the installation command:

$ sudo python setup.py install

Installing DenyHosts from source isn’t quite as automatic as it is from a package. From here, you’ll need to cd into /usr/share/denyhosts for some configuration fun.

Configuration

In the /usr/share/denyhosts directory, you’ll find two files that need attention before starting the DenyHosts service: denyhosts.cfg-dist and daemon-control-dist. Copy each -dist file to a non -dist version.

Make these two changes to secure the DenyHosts startup command:

$ sudo chown root daemon-control

$ sudo chmod 700 daemon-control

To finish your DenyHosts setup, do the following:

$ sudo ln -s /usr/share/denyhosts/daemon-control /etc/init.d/denyhosts

$ sudo chkconfig --add denyhosts

$ sudo /etc/init.d/denyhosts start

Enhancement

The default configuraton works well for most situations but only monitors SSH attempts. DenyHosts blocks SSH access when a foreign host attempts an SSH login to your system by adding an entry to your /etc/hosts.deny using the format:sshd: 192.168.5.10.

However, if you want more security, there is one parameter worth special mention: BLOCK_SERVICE. Using the BLOCK_SERVICE parameter, you can block ALL services from that host. Uncomment the line: #BLOCK_SERVICE = ALL, comment the line: BLOCK_SERVICE = sshd and restart the DenyHosts service.

Please note that the source installation and the package installation place files in different locations but has no effect on functionality.

DenyHosts enhances your security efforts without a great amount of work for you or stress for your system. There’s one feature that bears mentioning but is beyond the scope of this article: Synchronization. DenyHosts allows you to upload your blacklisted hosts to a central server and download blacklists from other DenyHosts users from around the world. I use DenyHosts on every Linux system that I have administrative control over. There’s just no excuse to do otherwise.

Do you use DenyHosts? If so, write back and tell us.

Comments on "Got Security? You’re in Denial"

wednai

Thank you for the article. I\’m installing right now.

It looks like the command \”sudo ln -s /usr/share/denyhosts/daemon-control denyhosts\” should be run from the directory \”/etc/init.d\”, but the article isn\’t clear on this point.

Reply
dragonwisard

Another solution is Single Packet Authentication.
http://www.cipherdyne.org/fwknop/

Better, IMHO, because attacker can\’t even attempt to log-in…even if they know the server exists.

Also, you should disable password authentication in favor of certificates which are much harder to brute-force.

Reply
palov@bio.bas.bg

I\’d better paly with \”MaxStartups\” in /etc/ssh/sshd_config (or wherever you choose to put the config file ;o) to hamper brute force attacks. And, probably, \”PermitRootLogin without-password\”…

Reply
stevekerr

I\’ve been using denyhosts for a few years; it has blocked 743 break-in attempts in the last year. Unlike the author, I have a fixed-ip with a DNS name. I wonder if that accounts for the higher (pro-rata) attack rate? I have my config set to block access to any address after 3 failed login attempts. I only have a single remotely accessible ssh account and, obviously, it is not root! As far as I know, no one has ever managed to break in to my system.

My only question is: Does having lots of entries in hosts.deny cause a degradation in network performance? I ask this as denyhosts has a \’purge\’ feature to remove blocked addresses once they reach a certain age. I have mine set to 1 year but I wonder if it should be less to improve network performance – bear in mind that hosts.deny is referenced for all network connections, not just ssh.

Reply
lugoteehalt

Sorry to be ignorant boys and girls but do you need this if you are not using ssh?

Reply
kmoffat

I\’ve been using it for years, also with apparent success. No break ins to my knowledge, and I\’m pretty sure I\’d know. I run Debian on a static ip running several web services, apache, postscript, dovecot, sshd, drupal, etc. I, too, am curious if a long list if denies degrades performance.

Reply
ibrado

You might also want to run sshd on a random high port.

Reply
txtiger73

DenyHosts is a nice program, but it is limited to protecting against abusive SSH connections.

I\’ve gotten more mileage out of Fail2Ban because it handles multiple services (ssh, ftp, pop3, imap, smtp, www); offers multiple blocking methods (iptables, netfilter, TCP wrapper); is easily extensible (write your own filter patterns and include arbitrary log files); and automatically un-bans IP addresses. This makes it more suitable for public servers that host a number of different services for multiple clients.

Another simple trick is to rate limit connections in your firewall. For example, this limits any IP address to 4 connections in 60 seconds:

iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 –rttl –name SSH -j DROP

Reply
gromm

Why bother? Just edit /etc/hosts.allow and add the fixed IP addresses that *are* allowed to connect, rather than waiting for just anyone on the internet to try to abuse your servers. Need access from random internet cafes? Set up an SSH server in an unimportant location – like your house – and let it act as an intermediary gateway.

You could also save an SSH key to a usb keychain that you have on your keyring (which is *always* on your person, right?) and disallow password authentication entirely. This is far more secure because the likelihood of anyone brute-forcing a DSA signature in your lifetime is smaller than winning the lotto 14 weeks in a row.

These methods make password attempts go away entirely.

Also, it\’s pretty obvious that the author of this article has never even been a professional sysadmin. If you\’re going to write about security, you should have some experience either in this profession, or as a security expert.

Reply
ionutg

How many hackers with fixed IP\’s are there in this world? Your IP is changing, the hackers IP is changing … you end up collecting his providers range of IPs. Then, after allm you might be more secure.

Did anybody do any statistics on the number of attempts/denials per IP?

Reply
tallship

Instead of depending upon logfiles, and, considering the fail2ban even states that there is \’some\’ lag because of this, I\’ve always been a portsentry fan.

Portsentry, logcheck, logsentry, and hostsentry are part of the sentry tools package at sourceforge, and even though I like fail2ban I find that in a production environment I need something that is working in realtime.

Be careful though, some parts of portsentry can be setup with hair triggers, and you need to make sure you have your exceptions in or else you may find yourself clearing out your /etc/hosts.deny and iptables for a few days until everything settles down.

Reply
engcheng

Just change port number
———————–
just for sharing, from the record of my /var/log/auth.log, my fixed IP web server used to face at least 100 over brute force attacks per day via various geographical sources, and using all forms of login names from root to john to mary to oracle…

I used to add the intruder\’s IP to host.deny, buy again, their IP keep changing and I got a bit tired. So…

I changed my SSH port to 1234 instead! and that really helps (in my case). Now, after a month of monitoring, I can proclaim I face no trace of brute force attacks. Alternatively, if you\’re more technical advance, can try knockd.

Reply
txtiger73

tallship — I respect your opinion and agree that real-time monitoring is a great feature.

True real-time reaction requires deep packet inspection. The defensive system must have an application-level knowledge of the protocols and up-to-date attack signatures. It also introduces a significant performance impact, especially when the host is under stress or attack from multiple sources.

We use Fail2Ban in daemon mode. After adjusting our log file buffering, we see response times in the 1-2 second range. Since we also implement rate limiting on SSH, FTP, POP3, IMAP, and SMTP services, an attacker\’s window of opportunity is fairly limited.

I considered Trisentry (PortSentry, LogSentry, HostSentry) three years ago. Here are my concerns:

- The package hasn\’t been updated since May 2003. Seven years is a LONG time in the security world.

- FreeBSD and several Linux distros have dropped third-party maintenance in favor of more active projects.

- PortSentry\’s signatures are hard-coded in the base C code. The open source scanning tool, nmap, provided workarounds for PortSentry five years ago.

- Logcheck\’s pattern matching is fairly limited — simple keywords with wildcards — no regular expressions. That makes hacking your own signatures unnecessarily difficult.

- The package analogous to DenyHosts and Fail2Bail — HostSentry — hasn\’t been publicly available since Cisco acquired Psionic Technologies in late 2002. That leaves us without the ability to review warnings from the applications themselves (especially useful with web applications).

- While watching for port scans can provide some forewarning, there is no guarantee a subsequent attack will be immediate. On our production systems, we see port scans occur up to a week prior an attack. Blocking IP addresses for extended lengths of time — especially proxy or gateway servers — causes far more harm than good.

Reply
martinladner

I found sshblack helpful. It\’s a perl program that can be used to block IP addresses after N bad login attempts and then automatically unblock them after N days. In my case, the file servers were public-facing to serve many customers who did not use consistent IP addresses and weren\’t technically savvy; so, I couldn\’t use a whitelist or play with port numbers. I set up set up shell scripts to ease its interaction with hosts.deny and to monitor sshblack (to bring it back on line when it dies). sshblack works by monitoring authlog and maintaining a list of blocks and failed login attempts.

Reply

Hello, Neat post. There’s an issue together with your web site in internet explorer, could test this? IE nonetheless is the market chief and a huge portion of other people will leave out your fantastic writing due to this problem.

Reply

Greetings! Very useful advice within this post! It
is the little changes that produce the largest changes. Thanks for sharing!

Here is my blog post – Kafelki do ?azienki

Reply

Appreciating the hard work you put into your blog and detailed information
you provide. It’s awesome to come across a blog every
once in a while that isn’t the same unwanted rehashed material.
Fantastic read! I’ve bookmarked your site and I’m including your RSS feeds to my Google account.

Take a look at my page … stylowe kafelki do ?azienki

Reply

I was excited to find this website. I want tto to thank you for your time just for this wonderful read!!
I definitely savored every bit of it and I have you
book-marked to see new information iin your web site.

Reply

Hello. excellent job. I did not imagine this. This is a fantastic story. Thanks!

Reply

I used to be suggested this website by means of my cousin. I’m not positive whether or not this put up is written by means of him as no one else realize such exact approximately my problem. You’re amazing! Thank you!

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>