3

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
Improve this question
7
  • 1
    You can either limit ssh access by ip address or change the port from 22 to something random.
    – SpiderPig
    Oct 6, 2017 at 18:06
  • 2
    Are the attempts from the same URL? If so, block it,
    – DrMoishe Pippik
    Oct 6, 2017 at 18:06
  • 1
    btw. 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
    Oct 6, 2017 at 18:10
  • 3
    The 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.
    – Vomit IT - Chunky Mess Style
    Oct 6, 2017 at 20:29
  • 3
    You could use fail2ban to block IPs that exceed x number of failed login attempts.
    – Klinghust
    Oct 6, 2017 at 22:46

2 Answers 2

Reset to default
5

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.

Improve this answer
1
  • 1
    Hey 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
    Oct 7, 2017 at 20:03
3

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.

Improve this answer
2
  • 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
    Oct 7, 2017 at 20:06
  • 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
    Oct 7, 2017 at 20:52

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.