Denyhosts and other ssh security
We have several servers exposed to the internet. Being Linux servers, we manage them by ssh. For security, we only allow key access — no passwords. But we still get a HUGE number of login attempts from — how shall I put it — unauthorized users. We always had no passwords set (! in the shadow file, not blank) and root disallowed from ssh so nobody could have logged in, but they still tried. Even after I turned off PasswordAuthentication, we still got attempts.
Then about a month ago, we had an attack. We were getting login attempts from hundreds of servers from around the globe. Where we were previously blocking a couple of server per week, we were shutting down connections from 15-20 servers per hour.
How do I know? Do I really check every line to /var/log/auth.log and /var/log/messages on every server every day and add offending servers to deny.hosts? No, of course not. I use DenyHosts. It’s a nice little python script thatscrapes your auth.log (or messages) looking for failed ssh connections. After it sees a certain number of failures from a particular IP address, it adds that address to hosts.deny and sends you a helpful email letting you know you are a bit safer now. You can also send your denials to a master server (which I have configured) and even download lists of hosts others have had to deny (which I haven’t). You can also see how many hosts have been added to their database in the last month. I wish it went back further. Then you could see the global attack which resulted in about150K servers being shut down in one day. The average prior to that was about 8K per day.
The only caveat I need to mention is that if you are running Hardened Gentoo, your SECURE_LOG is the Mandrake, FreeBSD or OpenBSD style (/var/log/auth.log) instead of the Gentoo style (/var/log/messages) as commented in the config file.
Also if you have a static IP address that you use to connect to the server, you should probably add it to hosts.allow. We’ve seen Nagios connect in a way that DenyHosts doesn’t like, so the outside address of our firewall was temporarily disallowed from connecting to a couple of our outside servers. That could have been exciting. Fortunately we could relay the connections from one server to the one that was blocked from our firewall to get around the block.
Otherwise, use ssh keys. And in your /etc/ssh/sshd_conf turn off root logins and turn off Password authentication:
PermitRootLogin no PasswordAuthentication no ChallengeResponseAuthentication no
Many of the attackers give up if you don’t offer password authentication at all which reduces the number you have to turn away later. And some of them do hammer your ssh server hard enough to spike the processor load. So anything you can do to reduce that helps.