How to protect agains milions failed login attempts?

Every time I access my VPS using PuTTY, I see this:

Last failed login: Fri Oct  6 17:25:58 UTC 2017 from xx.xxx.xxx.xxx on ssh:notty
There were 2381935 failed login attempts since the last successful login.
Last login: Tue Sep 26 09:30:02 2017 from xx.xxx.xxx.xxx

I don’t know it it is related, but when I login, it takes more time to load, on other servers that don’t get as many login fails as this one, the load time is a lot smaller.

Can you tell me if this many login attempts affect the performance of the server? And is there any way I can protect against this? I mean, my password for the servers are kinda impossible to break, but is there a way to avoid this fail login attempts ?

System specs:

Icon name: computer-vm
Chassis: vm
Virtualization: kvm
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-514.26.2.el7.x86_64
Architecture: x86-64

Mirage

Posted 2017-10-06T17:38:15.000

Reputation: 43

You can either limit ssh access by ip address or change the port from 22 to something random.

– SpiderPig – 2017-10-06T18:06:20.837

2Are the attempts from the same URL? If so, block it, – DrMoishe Pippik – 2017-10-06T18:06:38.627

1btw. you may also want to check what causes the slow load times e.g. with htop. There is a possibility that there is already some malware on the server. – SpiderPig – 2017-10-06T18:10:52.907

3The most secure way to do this would be to block everything and only allow the IP address(es) you trust to connect to it. I thought there was a Fail2Ban software with Linux so look into that as well to block IP addresses from failed attempts as you get brute-forced. There are probably tons of kindergartners out there is some countries running scans are part of their elementary education in school. – Pimp Juice IT – 2017-10-06T20:29:30.237

3You could use fail2ban to block IPs that exceed x number of failed login attempts. – Klinghust – 2017-10-06T22:46:03.400

1@Klinghust Fail2Ban is fine. But a more effective solution that requires utterly no new software installation is to simply disable the root account by creating a new user with admin rights, disabling root and letting that unique Sudo user be the new pseudo-root on the system. – JakeGould – 2017-10-07T05:43:25.630

1Very helpful comments, thank you guys so much, I will try to use it in my favor. – Mirage – 2017-10-07T20:09:15.717

Answers

So, there might be a profoundly easier solution to this.

The info you posted shows there are 2,381,935 failed login attempts. Which is pretty insane. Let me guess: The user you are logging in as is… root? Well, while Fail2Ban is a decent solution to trap unwanted login attempts there is a far simpler solution: Create a new account with a new name that is not root, give that user admin rights via Sudo and then disable root.

In general, any Linux server in 2017 should simple not have the actual root account active and usable for any reason whatsoever. Every “script kiddie” in the world has tons of crappy exploit scripts that attempt to hack the root account. And every skilled hacker has tools that attempt to hack root.

By creating a new user account under some witty generic name you can come up with and disabling root you will instantaneously lessen your attack surface and close off this potential incursion point will little to no effort.

Some system admins don’t like to disable root out of sheer laziness, but unless you are somehow restricting access to the server by some other means—such as a firewall configs based on IP or MAC address filtered and such—you open your server up for risk.

JakeGould

Posted 2017-10-06T17:38:15.000

Reputation: 38 217

1Hey man, thank you so much for your help editing the question, my english is not very good. I could try to change the user and disable root, but this is a squid proxy server and I only know enough to make it run. I will research some way to do what you said, thank you very much. – Mirage – 2017-10-07T20:03:11.610

In addition to fail2ban (as suggested by others) I'd setting up an OpenVPN server on the VPS and then a client on your system and then using an OpenVPN client on your client(s) - and using a firewall to limit connections to coming from the VPN. This will help by adding an extra layer of protection/encryption and hiding SSH.

If people are trying and failing to connect this can chew up significant resources, but it could be something else (unconfigured reverse DNS, oversubscribed disk). Look at up time and top to see what's slowing things down.

davidgo

Posted 2017-10-06T17:38:15.000

Reputation: 49 152

This is just a small server running a squid proxy, don't know why someone would bother so hard to hack it... I will try to use what you guys told me, thank you very much, really appreciate. – Mirage – 2017-10-07T20:06:31.957

The thing is that they are not really trying hard, they have simply discovered SSH is open to them (probably by using a port scanner), and are running a program to try and brute force it. This kind of thing happens day-in and day-out all over the Internet. They most likely don't know and don't care what its running, and want to enlist its anonymity [ from their POV ] in enabling it to be used for something nefarious. – davidgo – 2017-10-07T20:52:44.103