- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
DenyHosts: Keep on Knocking but You Can't Come In
Geeks aren't known for social skills, but admins are justifiably anti-social when it comes to unauthorized attempts to connect via SSH. Seeing a bunch of failed SSH attempts to your system? Take a look at DenyHosts as a way to block attacks, even before offenders try to connect to your server.DenyHosts makes it easy to ward off unauthorized SSH connection attempts. The utility blocks attempts to connect to your server via SSH after too many failed attempts or from a blacklisted host.
What's DenyHosts? It's a small utility that blocks attempts to connect to your server via SSH when there are too many failed attempts or (if you enable the feature) when a host matches a centralized list of addresses that have been making too many failed attempts to connect via SSH.
If you've maintained a server for any amount of time, you've probably noticed a number of failed SSH login attempts in
/var/log/auth.log -- depending on which distro or *nix flavor you're using. I ran into this recently with a slew of attempts from an address that resolves to a ".kr" domain. Since I'm relatively sure I haven't been to South Korea lately and I have no colleagues or friends with access in South Korea, it's a no-brainer that the failed attempts are illegitimate.
Most of the time, these kinds of attacks are simply a nuisance, if that. But why take chances? Whether it's an automated attempt that's testing hundreds or thousands of servers or an attack directed specifically at your servers, there's no reason to give attackers an inch. There's always a chance they could get lucky. Instead, throw up the barricades as soon as you detect an attempt to crack in.
You can do it manually, but that's a royal pain. (Which is, of course, something that attackers count on.) Instead, put the power of DenyHosts to work and frustrate attackers without even having to look at the logs.
DenyHosts is available from SourceForge, and it's packaged for Debian and Ubuntu as well as other distros. It should be a piece of cake to install.
Once DenyHosts is installed, it's a simple matter of editing
/etc/denyhosts.conf and firing it up. The config is pretty straightforward -- it's well-commented and easy to understand. A few settings should be tweaked though.
First, there's the BLOCK_SERVICE parameter. If a host hammers your system with failed login attempts, DenyHosts will thwack it by adding the host to HOSTS_DENY. By default, this is set to block SSH logins. But you can change this, and I recommend you do, to block ALL instead of just "ssh." This way, if attacks are not just some script-kiddie silliness, you can block other avenues of attack in addition to automated connections via SSH.
Out of the proverbial box, DenyHosts just blocks failed attempts on the system on which it's installed. However, the odds are pretty good that if an attacker is using automated attacks against your system, she's also attacking other systems. If your system isn't the first on the list, why not take advantage of other admins' annoyances and make use of DenyHosts' central server? Uncomment the SYNC_SERVER parameter and make use of the centralized service for DenyHosts, so if a system has been used to attack a bunch of other systems, it won't even have the opportunity to connect to yours.
DenyHosts is a simple tool, but it's also pretty useful. There's really no excuse not to have it installed and running. Set it up today and have one less thing to worry about.
Joe 'Zonker' Brockmeier is a freelance writer and editor with more than 10 years covering IT. Formerly the openSUSE Community Manager for Novell, Brockmeier has written for Linux Magazine, Sys Admin, Linux Pro Magazine, IBM developerWorks, Linux.com, CIO.com, Linux Weekly News, ZDNet, and many other publications. You can reach Zonker at email@example.com and follow him on Twitter.