What does brute force SSH hacking look like?

Brute force hacking is the easiest, least effective, and messiest method of all the ways to attempt to gain access to a system. It leaves a really obvious trail, and it’s fairly easy to stop unless you’ve become the target of large organization that really is out to get you.

By definition, brute force hack attempts are simply some variation of just trying to guess a proper username and password combination. I will look at attempts to break in to a Linux box via SSH, but the principals are the same regardless of the attack target.

Linux tracks log ins in two files and there are two separate commands to read them: last and lastb. The last command shows successful logins and system reboots, whereas the lastb command shows unsuccessful logins. Let’s take a look at the latter.

The format of the output of both files is like so:

The columns are username, terminal, originating IP address, and the login time, logout time and session duration. Since these are failed logins the last three columns together should represent no session time at all. If you look at the out put of the last command, you’ll see what successful sessions look like.

Now that we know what file looks like, let’s start tearing it down:

It becomes fairly obvious what is going on. The bottom 5 lines represent 2 unique IPs that have collectively failed to log in almost 10,000 times. For context, this lastb log only covers 48 hours. These are definitely brute force attempts, so let’s see what they’re doing:

The first and last guy has been solely trying to brute force the root account. This won’t work on my system because I do not allow password logins through SSH:

The next guy is doing more of a dictionary type attack. He is trying to stumble across a valid username and password combination by going through an alphabetic list of names (looks like 450 unique names that he tries multiple times. This also will not work on my system because I have no users and, as mentioned, I do not allow password logins:

So now you know your enemy. What can you do to stop them?

Turn off password logins

Move SSH off the standard port 22.

This is controversial because it is essentially an attempt at security through obscurity, but if you take the time to do this you will notice a drastic drop in brute force attacks. I attribute this to the fact that most brute force attacks are done en masse and therefore the low hanging fruit become the targets of opportunity. Simply moving off port 22 will drastically reduce the attention you get.

Use an IP blocker

If you simply must leave SSH on port 22 and accepting passwords, you can look at a package like Fail2Ban. This package tails logs and when it finds X number of failed password attempts, it does some preconfigured action. Typically, changes your IP tables rules to ban that IP either permanently or for some set period of time. I’ve used it in the past and it performed well.

Update

Nothing beats empirical data, so I moved my SSH daemon off port 22 on Saturday Nov 14th and watched to see what would happen to the stats. Below is a graph of failed log in attempts. I think it’s pretty obvious when I changed ports. This is a really startling example of how a simple change like moving off a well known port can drop your exposure to drive by attacks. This will not be enough to prevent attacks from someone who is specifically targetting you, but it does get you off the low-hanging fruit list.

ssh-logins