It’s well known that people try to brute force SSH servers using dictionary attacks to try to guess username and password combinations. The ssh daemon does not disclose the fact that password logins are disabled and root logins are disabled most of the time, and that only simple users can login, and those only using a public/private rsa key pair. We do that, it works fine, it’s good, and secure. But we still get brute force attacks.
One of them happened yesterday. The first thing we noticed was that one of our servers was down! I tried logging in to look into what’s going on, and I couldn’t see anything weird. Everything was in perfect shape. And although Apache was running, HTTP connections timed out. I restarted Apache. No luck.
Then I noticed the netstat log:
That’s the count of active TCP/IP connections every second, during the last few hours. Interesting that at some point it grows to a few hundred. This server doesn’t get that big of a load, so we weren’t expected to handle that. And it worked as a DoS.
But what was going on? Nothing in Apache access logs, or error logs…
Apparently, it was yet another SSH dictionary attack. Christian noticed it…
Oct 21 22:23:37 Gutenberg sshd[25711]: Invalid user Rauno from 84.103.144.152
Oct 21 22:23:37 Gutenberg sshd[25721]: Invalid user Reeta from 84.103.144.152
Oct 21 22:23:38 Gutenberg sshd[25735]: Invalid user Reetta from 84.103.144.152
Oct 21 22:23:43 Gutenberg sshd[25752]: Invalid user Reija from 84.103.144.152
Oct 21 22:23:44 Gutenberg sshd[25826]: Invalid user Reijo from 84.103.144.152
Oct 21 22:23:44 Gutenberg sshd[25882]: Invalid user Reima from 84.103.144.152
Oct 21 22:23:45 Gutenberg sshd[25913]: Invalid user Reino from 84.103.144.152
Oct 21 22:23:48 Gutenberg sshd[25963]: Invalid user Reko from 84.103.144.152
Oct 21 22:23:49 Gutenberg sshd[26009]: Invalid user Reversals from 84.103.144.152
Oct 21 22:23:53 Gutenberg sshd[26053]: Invalid user Riikka from 84.103.144.152
(Actual IP addresses and server names vary)
And… the log keeps going and going for thousands of attempts, and they keep becoming more often. He probably used a fast server for that.
In either case, although we were completely secure from an SSH login perspective (even if he guessed an actual password using this method -which he wouldn’t because we use secure passwords-, he wouldn’t be able to login without an rsa key), we were vulnerable to a DoS attack. Lately we’ve been trying to become less parsimonious about security, establishing almost formal procedures to avoid XSS attacks and SQL injections, as well as other attacks. It’s about time to come up with more drastic methods for blocking DoS attackers.
It’s true that DoS attacks are a massive plague for (mainly web) servers, and it doesn’t have a standard, ultimate way of being prevented. System administrators can only take some measures that would decrease the possibility of getting under such an attack. So, good luck with this stuff.
About a year ago, I remember seeing a hand utility that can run alone, or tie into your IPtables, and will blacklist any IP with five bounced logins in a row.
That might be helpfl, at least against the minor attacks, but carries with it the danger that people with dynamic IPs might inherit a blacklisted IP.