Securing SSH Using Denyhosts
Posted by narom on August 20th, 2007 
Email This Post
There are some very simple steps you can take to really harden remote access over SSH, especially if you can’t simply tie the service down to a limited number of source ports.
First things first, sshd_config. In Ubuntu this is usually found in /etc/ssh and can be used to configure a great number of features. The simplest ones to deal with are always the best. Restricting the users who can login via SSH is a first principle. This can be done in one of two ways, by user or by group. AllowGroups allows any user in this group authenticated access to the server via SSH. A more fine grained approach is to use the AllowUsers option.
Another easy win is by moving the listen port from 22 to some other randomly assigned port. This reduces the likelihood of a scan showing SSHD running.
Other steps you might want to take include disabling root access, disable password authentication and using keys only.
The next step is a wee tool called Denyhosts (http://denyhosts.sourceforge.net/). Make sure you’ve got the additional sources enabled in /etc/apt/source.list and then type:
sudo apt-get update
sudo apt-get install denyhosts
DenyHosts is a python script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).
Denyhosts acts as a dynamic blocker for SSH and other services. It relies on the /etc/hosts.deny and hosts.allow. It dynamically builds a list of hosts that repeatedly connect to your server. By default the service will block connections from IP sources that are repeated attempting to connect and access your host. The denyhosts process is configured in /etc/denyhosts.conf
There are additional things that can be done using iptables to rate limit connections and you should always run a firewall on your hosts but I’ll deal with that in a separate post.
Once you’ve put these steps in place you can rest assured the SSH on a public facing host is much more secure, there’s no guarantees but every little helps.
If you want to be notified the next time we write something please subscribe to our RSS feed.Thanks for Visiting!
August 24th, 2007 at 8:50 am
This is great but I also recommend sshblack - a perl script that tails your syslog or messages and sees the sshd failed login attempts. You can then set a number of failed attempts before adding the host to a deny rule in your iptables firewall. This will block any traffic from this host for a set amount of time. Works wonders! I’ve adapted it to check my apache logs for certain know virus/worms and block those hosts too.
August 27th, 2007 at 3:07 am
All great, I’ve used DenyHosts year or two ago. But I have much simpler and more effective solution. Just start SSH service on another port. Yeah, that’s. Instead of 22 use anything else, for example 10022. In /etc/ssh/sshd_config change Port 22 to Port 10022, restart and you’re done. I guarantee you that not one probe will reach your port. DenyHosts will still pass a few, before it blocks the port. And you can remember the new port easily, or just put it into ~/.ssh/config and be done.
The effectiveness of this approach is based on the fact that port 22 is hardcoded in all those cracker scripts, and they don’t bother searching for ssh on another port. It’s much harder for them if they also need to find the port, so they count on many people who leave ssh at default port.
Try this approach and you won’t regret it.
August 27th, 2007 at 3:51 pm
I don’t know about that !!
in my /var/log/secure I see crackers going after
a number of different ports to find my ssh port,
It seems they are checking other ports more than
port 22.
I also use fail2ban, and ban IPs for about 20 minutes and i don’t seem to see any repeats of same IP after that.
August 28th, 2007 at 10:48 am
Many solutions to the same problem: I use sshguard, which basically does the same.
There are other things you can do as well, like limiting the number of IP addresses you can connect from in your authorized_keys file (I do that for several users): the account of our service desk to access the machines has been limited to internal IP addresses only, since this account has the power (sudo) to shutdown or reboot the machine. I don’t want that to happen from ‘the outside’.
The authorized_keys file looks a bit like this:
from=”192.168.1.*,192.168.2.*,192.168.200.*” ssh-rsa [key goes here] [user]
The file itself is immutable for the user himself.
August 28th, 2007 at 5:52 pm
All of the above suggestions are fine, except that they all leave a small window of opportunity for a brute force scan to suceed. If during the first few trys, they randomly find a matching user/pass pair, they are in, even with all of the above options. Yes, low likelyhood, but not zero likelyhood.
A better solution is ssh-faker:
http://www.pkts.ca/ssh-faker.shtml
It is setup so that only the set of IP addresses you actually use to connect to it are allowed through to the sshd deamon. Everyone else stops at ssh-faker and needs to enter a password here first, before they even get to the sshd deamon the very first time. Result, hacker attack scans for sshd ports (no matter what port) are stopped dead because they think they find an sshd, but it does not work like an sshd. So they don’t even get one try to brute force a user/pass to sshd.
You, when you connect from a new IP, simply telnet to your machine and port (telnet machine 22) and enter your ssh-faker password. Ssh-faker then puts an entry into /etc/hosts.allow that then lets you connect straight through to sshd from that IP.
If you usually connect from only 2 or 3 static ip locations, you’ll only have 2 or 3 IP’s in hosts.allow. If you connect from varied different locations, all you have to do is periodocally clean the entries from hosts.allow to make sure no one else gets a try.
August 30th, 2007 at 9:14 pm
DenyHosts is great! I’m so glad I came across this article. Not 10 minutes after installing it, I’ve already got IP’s in my deny list. It’s not like I run a server or anything, it’s my desktop machine at home. I had no idea this scanning happens so much so often. Thanks for bringing this to our attention (or at least mine).
September 1st, 2007 at 11:09 am
Thank you very much by the article!
A very good work!
————————
September 3rd, 2007 at 3:17 am
denyhosts is working great for me, blocks all kinds of bad guys. The only problem I am having is since I changed from Mandriva to Ubuntu, I cannot get a reprt sent to ADMIN_EMAIL. I had a little trouble with this in Mandriva as well, but cannot remember how I overcame it.
Any suggestions would be welcome!