Hundreds of failed login attempts: Is that normal?

Question

Whenever I SSH into my DigitalOcean droplet as root (where possible I use a user instead), I regularly see there is hundreds, sometimes of thousands failed login attempts from the past few days.

• Is this normal?
• What is it likely to be cause by?
• Is there anything to worry about?
• Are there any steps I should take to reduce these attempts?

Solution 1

Is this normal?

Yes. This is happening all the time.

What is it likely to be cause by?

Bots trying to get access to your system. If they are successful, they might abuse your system to do the same thing to other machines.

Is there anything to worry about?

In a nutshell: If you have disabled password based login, then no.

Are there any steps I should take to reduce these attempts?

You can use something like fail2ban.

Solution 2

Yes, I'd be more concerned if you didn't.

It's a good idea to...

• change your ssh port (common)
• drop packets from unknown IP address if you have a reliable source range.
• add multi factor authentication
• port knocking
• scheduled firewall/service (only run ssh when you need it, emergency access via console)
• install fail2ban to reduce repeat offenders

Comments

[Alicia]

Thanks very much, really helpful. Should the port just be anything other than the default 21?

[Andrew]

SSH is default on 22, but yes, if you want to change it, pick a number that doesn't conflict with something already running on your system and that doesn't overlap with a different known service. netstat -anpt can be used to show what is actively listening on your box.

[Alicia]

"A great solution to clean this up though, is to set up automation so that the owner of the originating network gets a notification" - No thanks!! I don't want 5000 notifications a day, reminding me that bots like to ping stuff 😂

[yagmoth555]

@Dagelf No, it's not a good idea as a botnet will make you down, as you answer it, just use something like fail2ban like other answer tell, so the local firewall & ssh daemon will no longer handle those packets at all, as it will be dropped at /dev/null.

[spotchi]

That is what is called "doctoring the symptom instead of the cause." How will that ever improve the situation? So you are in effect saying we should just sit on our hands until password authentication is no longer a thing?...

[spotchi]

@Alicia It's not for ICMP probes, it's for actual brute forcing, which is against the AUP of every single service that I've ever seen an AUP for, unless previously arranged via a security audit. Can you honestly not see a prudent automated way of dealing with this properly? Is the internet equivalent of 1000 people/day trying to break open your front door normal? No. If people who do this are cut out, unless they have a permit to do security audits, wouldn't all our data be safer? Yes, it's not going to fix everything, but it will set the bar for data theft and breaches higher.

[spotchi]

@yagmoth555 It will make it near impossible to set up a botnet in the first place - unless every network agrees to host botnets and to receive botnet traffic. I'm simply proposing a way to more elegantly deal with something that is being dealt with very informally, currently.

[spotchi]

@yagmoth555 There will always be networks that don't care - if you're on a network that hosts botnets, shouldn't you know about it? Rather than just randomly finding out you can't access some sites, and having to do regular captchas, or changing providers being your only recourse, with no transparency or other info? (Unless you pay some dodgy security firms?) I'm simply considering whether there is a more elegant way to deal with something that is being dealt with very informally, currently. I'm just saying, explore automation, before the authoritarians see an excuse to do it for us.