Securing sshd with DenyHosts
DenyHosts is a Python script that is “intended to be run by Linux system administrators to help thwart ssh server attacks.” Basically it takes a look at your logs, scanning for hosts that have attempted to connect to your ssh daemon. It then automatically adds any hosts that appear to be attempting to hack into your system to /etc/hosts.deny, permanantly blocking them.
It is made to be run from cron or as a daemon, so it continually checks for offending hosts and automatically adds them to the blacklist. Just let it run in the background and it does the work. It’s really a pretty slick idea.
So I loaded it on my Gentoo box to try it out…
First up, emerge the script:
# echo "app-admin/denyhosts ~x86"> package.keywords
# emerge denyhosts
The ebuild gave me a configuration file at /etc/denyhosts.conf. Looked pretty good to me so it was time to test it out:
# denyhosts --version
DenyHosts version: 1.1.2
Installed ok, so then I ran it with the default settings:
# denyhosts --verbose -c /etc/denyhosts.conf
Processing log file (/var/log/messages) from offset (0)
Added the following hosts to /etc/hosts.deny:
192.168.2.10 (unknown)
192.168.1.101 (unknown)
192.168.1.102 (unknown)
192.168.1.5 (callisto)
callisto
198.203.136.130 (unknown)
Heh, well that doesn’t look good. It flagged most of the boxen on my LAN’s two subnets:
# cat /etc/hosts.deny
sshd: 192.168.2.10
sshd: 192.168.1.101
sshd: 192.168.1.102
sshd: 192.168.1.5
sshd: callisto
sshd: 198.213.146.130
It did block one IP that I didn’t recognize, and one other IP that belongs to a Matt (not shown). The rest of the IPs belong to my trusted computers, including my main desktop at 192.168.1.5. Easy enough to fix with nano, but still… odd results.
And had I not checked hosts.deny after running the script, I would have had to go to the basement and plug in a monitor to fix it. And that’s just not cool. :)
So what’s my conclusion?
Although it would appear that DenyHosts didn’t work too well, I’m still going to run it once in a while (not from cron as expected). I still think using port forwarding to run sshd on a non-standard port (i.e. something other than 22/tcp) is the best thing you can do to improve ssh security at your site. But I can see how a tool like this one could be potentially useful as well.
Update: Just to be clear… I didn’t read any of the docs and didn’t take the time to configure the script correctly. The script is cool. See Phil’s comments below.
January 20th, 2006 at 11:46 am
Wow…where did you find that script?
January 20th, 2006 at 9:37 pm
Some guy who goes by the name “Fuzzie” in CPLUG. Odd fellow. :)
January 21st, 2006 at 12:36 am
BTW, congrats go to Fuzzie. His is the official 100th comment of the site!
I feel like there should be a prize or something. Heh.
February 20th, 2006 at 5:47 pm
To prevent any one of your trusted servers from being banned simply create the allowed-hosts
file in your WORK_DIR and add the known servers in there. For details see:
http://www.denyhosts.net/faq.html#allowed
Othewise, DenyHosts will certainly deny access from any ip address where the failed login attempts exceeds the respective threshold values.
February 20th, 2006 at 9:54 pm
Hi Phil,
Thanks for the tip!
Like I said, I didn’t really spend much time with DenyHosts and I didn’t take the time to RTFM. So I certainly don’t blame the app for my ignorance. The FAQ and documentation are really quite good. I just wanted to see how it ran “out of the box.”
It really is a nice little script, and I’ve been recommending it to people. Keep up the good work! :)
April 5th, 2006 at 8:54 pm
[...] A while back I wrote about securing sshd with DenyHosts, a Python script by Phil Schwartz. Since that time, I know quite a few people who have started using it on their servers and are quite happy with it. It’s a slick little script. [...]
October 30th, 2006 at 12:26 am
[...] I’ve mentioned DenyHosts back in January, and it’s seen some rather active development since that time. It’s a Python script “intended to be run by Linux system administrators to help thwart SSH server attacks.” [...]