Denyhosts as an added defence to ssh server
A couple days ago I had a brief article on the vandals banging away at the door of my ssh server. Like I said, I’ve, at times, been fairly smug abou the futility of their actions, but…. the persistance concerns me. Let me be more specific, I keep a fairly tight ssh server setup (don’t allow version 1, only have specific users allowed, use privilige seperation, deny root login, and keep it updated whenever there is a problem with a running version.) But, when you see a single IP making THOUSANDS of attempts to log in, you start thinking…. what if they were to hit on the right username and try a thousand combinations of passwords with that username. Hmmmm… disturbing. So, I wound up setting up denyhosts and thought I’d share a bit more about it here.
Denyhosts basically uses tcp wrappers to protect sshd from repeated failed login attempts. By default here is how things should work. BAD_IP tries to login with 5 different usernames. If they’re all “invalid” names (not existing on the system.) Then that’s enough to get BAD_IP written up in /etc/hosts.deny (or your systems equivalent/it seems flexible in it’s setup of config file locations.) To do this, it monitors your secure log (or whatever log keeps track of inbound ssh connection attempts.
Of course, I should note that IF you have ALL: ALL in your hosts.allow the deny policy will do nothing. I’ve found a machine that had ALL: ALL in hosts.allow and it’s such an old install that I’m not sure if it came that way, or if it was altered that way to troubleshoot a networking issue. TCP wrappers checks hosts.allow first, then hosts.deny – so if ALL: ALL is in hosts.allow then EVERYMACHINE is ALLOWED for every connection – the rest (deny) will be ignored.
Anyway…. let’s say the attacker at BAD_IP was using a valid username…. 10 attempts then with failed passwords would get them banned. Sites can be “unbanned” after a set period of time. There is another feature which is VERY interesting though.
You can have denyhosts connect to a central server and get information on banned machines (and, if you like, SEND information on banned hosts.) So, if someone is on a big hacking spree you can proactively ban their address before it reaches your server. Now, I do see some potential problems with this, but the default is that there is a threshold that the offending IP must have been reported by a total of three users for it to be downloaded and banned. This would seem to be an interesting idea though.
For those that are anxious about locking out access accidentaly. There is an ability to whitelist a host (or several.) This can be done by ip or dns (I’m not quite sure how this would work if you’re using something like dyndns where you might not have a reverse dns lookup (ip -> domain). That might be worth checking.) So….. if you have an ip that you are confident will be a safe way in, you can whitelist it to prevent it from being banned.
It can also send an email to a configurable address to notify the administrator of banned IP addresses.
It adds a nice layer of protection to a ssh setup. Most all of the options are VERY configurable, so if you’re a bit more paranoid you can set the ban threshholds lower, or if you’re a bit concerned about locking yourself out you can set the threshholds lower. I wish that it would protect other services as well. HOWEVER…. it should be noted that you COULD adjust the “name of the service” configuration line from sshd to ALL and then you would ban the offending IP address from ALL system services. Of course, that would assume that all hack attempts are nice enough to try and break in via ssh first. (Admittedly there are other applications which try to protect other services. However, changing sshd to ALL may be a good idea, I mean if they’re trying to crack a login for sshd, why would you want them to access any other ports?)
Anyway… here’s denyhosts.sourceforge.net, it’s been featured as a Unix review tool of the month.