Kamibu

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.

Most people use SSH to access their server over the Internet and administrate it. SSH is claimed to be a secure way of accessing a server. But with the wrong configuration this can be the contrary.

Disabling the direct root login is good as a hacker needs to guess 2 seperate passwords. So if he guesses the password of your first account he only has restricted access to your machine and needs to ‘su’ to gain root access, too.

First of all you should choose a good password for your users.

1. Let’s SSH into your server. You should use a second user account and ‘su’ to gain root access.

2. Open /etc/ssh/sshd_config with the editor of your choice.

vi /etc/ssh/sshd_config

3. For more security we should disable the insecure SSH Protocol 1. For doing so find the line ‘Protocol 2, 1′ and change it to ‘Protocol 2′.

4. Next thing is disabling the direct root login. The line ‘PermitRootLogin yes’ is allowing direct root logins. We need to change it to ‘PermitRootLogin no’.

5. After making these changes save the file and quit your editor.

6. Now we need to restart the SSHd

/etc/rc.d/init.d/sshd restart

Attention:

If you make a mistake in your sshd_config file it can happen that the SSHd will not start again. So take care of what you are doing and don’t logout before you tried your changes. Else you’ll need someone with physically access to your server to repair SSHd’s config.