0

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?

  • You can block them to get less noise in the logs, to be able to focus on the messages that actually matter. – André Borie Feb 24 '17 at 20:43
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.

  • 1
    My raspi can only be reached via IPv6 for a few months, now. I haven't seen a single attempted login of a nonexistent user or root since the change. They really just scan IPv4 addresses, they don't even care about DNS entries (which would lead to my IPv6 address). Disabling IPv4 can do an even better job at keeping logs small. – UTF-8 Feb 24 '17 at 20:43
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.

  • I don't think they have hope of ever finding a password which isn't one of the million most common ones. As soon as there isn't a single user which even can log in with a password (if all use public key authentication), I don't see any point of running a software to make futile login attempts harder. – UTF-8 Oct 2 '16 at 13:59
0

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.

  • Hundreds of attacks per day? These come in literally ever few seconds (see the example log). Do you know how many seconds a day has? Saving a tiny amount of bandwidth and CPU time doesn't sound like good practice. It might very well be good practice to block these attacks but surely, it has to be something else, doesn't it? I mean, I haven't seen a single one not fighting a lost cause by attempting to log in as a user who doesn't have a password or doesn't exist at all. What if I get rid of all passwords and only accept public key authentication? – UTF-8 Oct 1 '16 at 13:53
  • While only allowing certificate logins does add security, it won't stop the rubbish in your logs, the attacks will continue regardless and they will go on forever unless you make some changes. These are botnet attacks, fully automated. All Internet connected servers have these issues and need to deal with them. The people who fail to deal with them are often the ones making the problem worse by allowing new devices into the botnets. – Julian Knight Oct 1 '16 at 14:07
0

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.
  • I don't see any point in using non-standard ports. I don't really care about the log size and my system isn't going to be compromised by bots going through the million most common passwords. root doesn't have any way at all to log in directly, so no need to configure ssh regarding it. I know fail2ban (it's written with a "2", not with "to") and used it up until the latest installation of the OS. It's just that I don't see the point of it. – UTF-8 Oct 1 '16 at 13:49
  • 1
    If you let your logs get filled with rogue login attempts, you will not be able to see when something actually important happens - such as when someone actually does manage to get in since they now know you are running SSH and can target some attacks. Unlikely to be a person doing this, it is a botnet and they don't get bored or care whether your system is "important" or not, they are just looking for another foothold to compromise. Please don't undermine other people's security by allowing another system to join a botnet. – Julian Knight Oct 1 '16 at 14:03
  • Having re-read your edited Q, I've updated my answer to be more direct. – Julian Knight Oct 1 '16 at 14:15
  • The only thing I changed in my question was to replace a single term with a more appropriate one. I have a command called loginsAccepted which really just is an alias for logins | grep ACCEPTED. logins (not to be confused with the standard command login) calls the script which generates the output you can see in my question. I installed fail2ban now and by now it blocked all of the IPs which are currently active on my IP so there haven't been any more than 3 attempts per IP address in the last 30 minutes. – UTF-8 Oct 1 '16 at 14:24
  • Just as I observed in the past, bots tend to give up completely once they are banned, even if the ban only is for 2 minutes and they long could've had their next 3 login attempts. In my opinion, that just shows that their programmers know very well how small their chances of success are once a system is configured in any way even only slightly counteracting their activity. I still don't see why it would be a good idea to tell people to use fail2ban. Highlighting how important it is to avoid using passwords or to only use strong passwords, seems like a way better strategy. – UTF-8 Oct 1 '16 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.