Why block IPs from which SSH login failed too often?

Question

I have an internet-facing Raspberry Pi on a private internet connection and the last time I set it up, I didn't bother installing a way of blocking IP addresses from which too many SSH login attempts failed from attempting SSH logins in the near future because I simply don't see the point of it.

All this resulted in is log entries looking like this:

2016-10-01 14:28:25 root        failed   119.249.54.88:56388
2016-10-01 14:28:26 root        failed   121.18.238.104:43921
2016-10-01 14:28:27 root        failed   119.249.54.88:56388
2016-10-01 14:28:28 root        failed   121.18.238.104:43921
2016-10-01 14:28:30 root        failed   119.249.54.88:56388
2016-10-01 14:28:30 root        failed   121.18.238.104:43921
2016-10-01 14:28:34 root        failed   121.18.238.104:41379
2016-10-01 14:28:35 root        failed   121.18.238.104:41379
2016-10-01 14:28:35 root        failed   119.249.54.88:60430
2016-10-01 14:28:37 root        failed   121.18.238.104:41379
2016-10-01 14:28:37 root        failed   119.249.54.88:60430
2016-10-01 14:28:41 root        failed   121.18.238.104:42230
2016-10-01 14:28:41 root        failed   119.249.54.88:60430

The log only shows login attempts via password since attempting to log in via public key authentication would be even more ridiculous. The vast majority of login attempts tries to log in as root which in the case of my raspi of course can't even log in at all. So far, no login attempts even guessed a valid user name (pi has been guessed quite often but it doesn't exist on my raspi), let alone one which even can log in via username and password.

Is there any security benefit of blocking such IP addresses for a few minutes? The chance of a system with only complex passwords (for the users which can log in via username and password) seems to be basically 0. Even with only an 8 character printable ASCII password (which would be pathetic, of course), the username guaranteed to be correct (since one should never assume a username to be a secret), and 100 login attempts per second (which my slow internet connection probably can't even handle), that's literally ~1 million years until expected success.

If I block these login attempts, all I'm realistically going to do is to tell the attackers to go attack someone else and maybe lock myself out for a few minutes if I get a password wrong too often (happened only once thus far and I set the time to block to something like 2 minutes so I only had to wait for a short period of time). I don't see why this would be advised. It just seems so unnecessary. Am I missing something?

Answer 1

Is there any security benefit of blocking such IP addresses for a few minutes?

Smaller log files as the bots give up and attempt different targets. Smaller logs means more log history (and less churn if those logs are written to flash).

If I block these login attempts

Intializing a secure ssh connection and checking whether root is allowed to login is a lot more work that dropping a packet.

You save a tiny bit of power, and perhaps a non-trivial amount of bandwidth.

fail2ban... I don't see the point

You could pretty easily add a firewall LIMIT rule instead.

my slow internet connection ...

Scenario 1

TCP handshake: 3 packets
SSH session initiation: half a dozen packets
Login failure: 2 packets
TCP teardown: 3 packets
------------------
Total: 12+ packets @ 1800 per hour = 2-20 MB per hour

Scenario 2:

SYN hits the floor.
------------
Total: 1 very small packet @ 10 per hour = not much

These bots are using a non-trivial amount of your bandwidth. Block them so they will use less.

Answer 2

This is a simple brute force attack, they pick a login and go trying every possible password, starting from the most common ones and such.

In your case they've been trying a user name that doesn't even exist, which leads you to question if there's even a point in blocking them, but consider the scenario where they do try a valid login.

Not blocking their IP would give them the opportunity to try out several millions, maybe billions of passwords per day, until they find the right one.

If you block their IP for several minutes every time they fail a number of attempts, however, will render their hopes of finding that password within a practical time completely futile. That server won't be hacked that way within a life time.

This also means they will most likely give up and stop flooding your server with silly login attempts.

Answer 3

In order to thwart SSH attacks like this one, utilities like fail2ban or CSF/LFD are commonly deployed on Internet-facing servers. These tools will parse your logs and generate iptables rules on the fly to block the offending IP address.

Even if they are unlikely to succeed, I think it is good practice to block those attacks. You'll save some bandwidth and CPU.

Depending on the tool, you may be able to whitelist certain IP addresses like yours, if they are static or don't change often.

On certain systems I have witnessed hundreds of attacks per day. At some point they might drain your resources. You have little to lose blocking them.

Answer 4

Is there any security benefit of blocking such IP addresses for a few minutes?

If you change your public SSH port, you will probably never see another attempt. That is the best way to keep your logs clear so that you can see actual issues.

If you disable password logins in SSH, the chances of any rogue login are very small indeed.

Blocking the IP's is really only necessary if you don't do the above. In that case, just because you've not seen a successful attempt in the few minutes you've actually looked at the logs, this does not indicate that they won't be successful in the future or that they won't then run some other attack that is successful but is masked by the many other log entries. However, doing the temporary blocks certainly doesn't hurt except for a very rare delay to your own login. It does add extra security and it would help in the case that the botnet switches to a more targetted attack.

---

Any computer connected directly with open ports onto the Internet will start to be automatically scanned by attackers within around 30sec or so.

Because so many Internet connected devices use SSH to provide remote access to the command line and because the root user has total control over and access to the device, it is the main port that attackers look to compromise.

You will never be able to manually keep up with all of the attempts and it is a waste of time trying. However, there are a couple of things you can and should do:

• Move the Internet facing port from 22 to something high. That will stop almost all attacks immediately. The easiest way to do that is in your router. But you could also use the Pi's IPTABLES firewall to do it.
• Ensure that root cannot use SSH, this should be the default anyway. If you need elevated rights, use sudo. As this is a Pi, you should also disable the Pi user or at least prevent Pi from using SSH, create an alternative ID.
• Install fail2ban on the Pi. This can be used to automatically ban source IP addresses if they fail to complete a login. If you ban any of those IP's for, lets say 5 minutes, you will be getting pretty safe. Make sure you either whitelist any IP's that you legitimately use, or that you only ban for a period short enough so you don't get locked out yourself if you fail to login properly.