24

I've been monitoring my server's SSH logs and noticed a steady stream of login attempts from unknown IP addresses, mostly from different countries.

Heaps and heaps of account names are tried, and with some quick server stats I'd say, at least a quarter of the time they are valid usernames, which seems too coincidental to me. This may seem lucky, but there aren't that many common names such as 'John' in my system, as, without going into the details, my application is mostly for work, and people usually use their full names for formality.

No attempts have succeeded so far. Luckily my server has a strong password policy, and I've enabled two-factor authentication for all users.

How worried should I be about these attempts? Are they likely part of a botnet or a targeted attack? Are there any additional security measures I can take to prevent unauthorized access? I'm concerned about potential security risks and want to ensure my server remains secure.

So is this something I actually should be worried about, or am I just being paranoid and should I just ignore them?

3
  • 9
    What you are seeing in your logs is typical whenever you expose a service to the public internet. See the following links for more info, and for things you can do to harden your ssh service: security.stackexchange.com/questions/66441/… security.stackexchange.com/questions/39/…
    – mti2935
    Commented Apr 29 at 2:13
  • Why is your SSH port exposed to the whole world? Use a whitelist of trusted IPs only. Commented Apr 30 at 23:36
  • 2
    @DannyBeckett that is probably a good idea- however I am kind of new to server networking, and I actually did trial this, but when my real 'clients' tried to log in, only about half mathced to their previous white list ips, and the other half where denied, for some reason, so I had to modifie the list many many times. I definitely not saying it's not possible, because it sounds like a good idea, but I am probably just not adavnced enough to compile a white list than changes and updates automatically. Commented Apr 30 at 23:49

5 Answers 5

37

That's just "normal". Any exposed server on the Internet is going to be scanned by malicious (and benign) bots. What you are seeing is brute force attempts. They are usually not targeted; you are just a target among millions of others.

What you can do is set up CSF-LFD or Fail2ban, to ban offending IP addresses at firewall level. Even if your passwords are strong, there is no reason to permit this behavior, because it is wasteful. Your server is being pounded by attacks and wasting resources for nothing. (At times, I have witnessed hundreds of simultaneous attacks; that has to degrade performance a bit, I guess.)

You could also disable password authentication and use public key authentication instead.

Then, you have to consider the other exposed services. For example, SMTP servers are usually probed in the same way by spammers looking for vulnerable servers, that they can use as open relays. SMTP service can be protected by the same aforementioned tools.

If you have a web server running, it is quite likely that it will be visited by bots attempting to find and exploit SQL injections and other vulnerabilities.

The bottom line: check your logs, and use the free tools that are at your disposal. There are also tools that can monitor the logs, and send alerts when specific events are detected.

If you want to have fun with attackers, you could set up a honeypot to watch their actions - and frustrate them.

9
  • 1
    It would be kind of funny to put something like a billion laughs on a honeypot but probably some risk of attracting unwanted attention.
    – JimmyJames
    Commented Apr 29 at 15:44
  • 14
    Anecdotally, I changed my sshd port to a random number about a year ago and the number of invalid login attempts I've seen since then is zero.
    – sbrudenell
    Commented Apr 30 at 2:38
  • 7
    Note that while fail2ban used to work well, these days every login attempt I get is from a different IP, and they don't repeat for IPs for months. So in order to actually ban anyone you have to allow only 1 failed login attempt, and even then the ban doesn't achieve anything in practice.
    – canton7
    Commented Apr 30 at 8:45
  • 4
    I have a work host that needs to listen to 22/tcp from the internet with password auth, for Reasons. There's very roughly 1000 failed root logins a day. Its an AWS host, so I was able to define around 30 IP network blocks that legitimate connections could be sourced from, so adding a firewall rule (security group) to drop anything else cut it right down.
    – Criggie
    Commented Apr 30 at 9:30
  • 6
    Block by default is more security than allow by default. Instead of blacklisting ip addresses, white list them.
    – Questor
    Commented Apr 30 at 17:31
17

How worried should I be about these attempts?

Not particularly unless you are seeing specific usernames other than root which are actually found on your system.

Are they likely part of a botnet

Probably, but not necessarily. They are almost certainly automated though even if they’re not coming from a botnet.

or a targeted attack?

Unlikely unless there are attempts with actual user names other than root.

The common case for stuff like this is making attempts on a handful of ‘well known’ users (root, toor, pi, admin, etc) across a large number of servers, often trying known default login credentials, with the intent of finding systems that have not been well secured (because those are also the ones where an infection is least likely to be noticed).

Are there any additional security measures I can take to prevent unauthorized access?

The classic approach to mitigation is to run SSH service on a non-standard port (2222 and 2200 are popular alternatives). Most groups doing this kind of thing only check the default port, both because it’s faster, and because people who changed the port are probably paying better attention to their system (and thus will almost certainly notice a successful attack).

A more aggressive approach is to use a tool like fail2ban to block attacking hosts at the firewall level. This will give more complete protection, but it also runs the risk of users being locked out unintentionally (either by somebody attacking from the same IP, or by the user failing authentication a few times in a short period of time).

Additionally, disabling password-based authentication can trivially mitigate this issue (provided you ensure your users aren’t using known compromised SSH keys).

1
  • can confirm they hit non standard ports - I used to have 2222 and it got hit too. Commented May 2 at 3:43
2

Yes, you should be worried about these attempts. Chinese state programmers, Russian state programmers, and ransomware gangs write automated programs to search for servers and, when a server is found, try every possible vulnerability they know of on that server. There are zero-day vulnerabilities that you can't defend against.

On my server, I have written 10 mouse traps that detect these hackers and ban their IP address using iptables/ipset before their automated program to hack into a server finds a vulnerability I have overlooked. I store the banned IPs in a database. I am currently banning over 50,000 IP addresses. I wrote a program to read this database and ban the IP address on other servers. I also recommend running ssh on a non-standard port.

9
  • 1
    fail2ban is an existing tool to ban brute force attackers
    – schroeder
    Commented Apr 30 at 20:36
  • 3
    Another method to consider is to block ALL IPs except known-good ones. Maintaining the (likely small) known good list is probably more manageable than blocking them as they appear. As a commenter on the other answer mentions, IP addresses are easy to come by.
    – spuck
    Commented Apr 30 at 22:19
  • Do you have statistics about how often your bans work, i.e. your banned IP addresses try to do something else later? Commented May 1 at 1:06
  • 2
    @spuck my only concern about whitelisting is needing to access the server from a new location and not being able to because the IP is not on the whitelist. you can't always know ahead of time what IP address you'll connect from.
    – Michael
    Commented May 1 at 8:39
  • 1
    @phyrfox i run my own VPN server too, but it's on the same VPS
    – Michael
    Commented May 1 at 13:40
1

Completely different approach, not applicable in all situations though: Would a VPN server running on your host be possible? Users with valid credentials would start the VPN and only then be able to use ssh on your server. This can be achieved by removing port 22 from the public zone of the firewall and instead open the VPN server port there (e.g. UDP port 1194 for OpenVPN). Additionally the ssh server could be configured to listen only on the internal network of the VPN server. On my server this brought down the number of illicit ssh login attempts to zero while, to my astonishment, illicit logon attempts on the VPN server keep amounting to only a few per day.

As a side note, I would not look into banning IP addresses because as stated by various comments here, IP addresses in my logs more or less never re-occurred. Whitelisting IP addresses doesn't seem to be useful as well because the idea that IP addresses are fixed for legit users is frequently not valid anyway. Many users might use mobile devices with their IP addresses changing per location. Moreover, many internet providers change IP addresses of (A)DSL connections on a regular basis. This might explain why the original poster had to adjust the IP address whitelist so often that in the end it became unworkable.

1
  • Possibly... I'd have to check my firewall settings... it might not allow this but I'll look into it. Thanks! Commented May 2 at 2:33
1

In addition to all other answers, I'd like to point out that port knocking also exists as a solution to random IPs being able to access all kinds of ports they shouldn't. In my experience, it works quite well, and gives me just a little bit more peace of mind than simply moving SSH to a port that's a bit higher.

1
  • 2
    The problem here is that all the clients need to set up port knocking, too. And since we're talking about employees, there are other, more convenient and more secure options.
    – schroeder
    Commented May 7 at 11:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .