Attack of the SSH Bots - observations on SSH brute-forcing attempts

Introduction

As publicly known, I have an active home server for a variety of purposes. I recently did something that could be said to be a major renovation; a big part of the internal software setups were replaced completely, and all of them were substantially updated or at least refactored to be better suitable for my current needs.

It is considered to be common knowledge that SSH bots are constantly on the hunt for vulnerable hosts. It is also an equally well known fact for me that my server was probed by these bots (as shown on firewall logs), but I had not systematically collected any statistical data about them.

So, for personal interest, I set up an automated statistical logger for SSH services. It observes SSH probing attempts, and jots down information in a easy-to-process format. The results were quite interesting indeed, in my personal opinion.

Note that all of these observations are about password-based login attempts. Even though my logging system would have logged failed public-key login attempts, absolutely zero of them occurred. This is an interesting observation in and of itself.

Observations

General statistics

Obsevations detailed in this post span time from Friday 29th September, 17:08 thru Friday 6th October 20:30. This time is non-continuous, with periodic server shutdowns (it is quite noisy, after all..) leaving gaps in the logs. There were a total of 4237 attempts to log on.

Assuming the server was active around 16 hours a day, this comes to around 37 attempts a hour. This may seem small by the first glance, but considering the server is usually on for most of the day, this very quickly racks up to a rather substantial count. There were approximately 58.8 attacks per single IP address, with the standard deviation of the sample being 194.14.

Root is the king

It is very obvious that these bots target the root account. Over 63% of tries were for the user root.

As a matter of policy among other security policies of mine, I have PermitRootLogin No on all of my SSH servers, so they would be intristically immune against this common attack attempt. The attacker would have to guess another username, before even getting on the topic of authenticating themselves.

Weak passwords mean open doors

These most popular, and yet decisively weak passwords cover over a fourth (26.4%) of all attack attempts. If you use any of these passwords on a public-facing server, chances are, it will be pwned before the day is done.

Looking at the rest of the log, many passwords were based on common words and relatively short.

Strong tendency for offenses from a few countries

China, solely, accounts for 54.8% of attempts - and the set of top 6 countries account for 92% of attacks. There is obviously some merit to the sometimes heard advice of simply blocking China - if I did that outright, half of the attacks from this sample would be gone instantly.

It is particularly interesting that there are many different intensities of attempts. From the bottom end, there were only a single or maybe a few attempts - and for the top contenders (including one IP from China with 1000+ attempts!), the attempts spanned several hours on end, sometimes even resuming after long shutdown times.

What to take away from this text?

• Secure your servers with strong passwords by least! Never use trivial, easy to guess passwords - someone likely has guessed them already!
• Use Fail2ban or equivalent auth-count based restrictions. For statistical purposes, I’ve set my server up that even when someone’s authentication attempts are up, it will not be revealed to them. Because of that, authentication attempts could rack up. Fail2ban is much less subtle, and simply firewalls offenders right off. It is your choice to use either method, as long as you limit failing attempts in some way.
• Use 2-factor auth. There are several kinds of 2FA implementations available for SSH connections, the simplest one probably being an enforced public-key+password authentication policy. This operation would kneecap bots very effectively, as they are unlikely to know the specific 2FA requirements for your server. This is also implemented for my server.

Particular captures from the logs

Here are a few particularly odd, weird and/or amusing snippets that were caught during the time period above.