You say this:
The past month, my personal web server has received thousands of these
notices.
Don’t panic! Just disable the root account on the system.
Welcome to the modern Internet! Do not take any of these notices personally and do not take any of these as a sign of a targeted attack against your web server. Rather this is a normal part of any web server existing online in some way: Armies of botnets are constantly scanning web servers for weaknesses and then sometimes exploit those weaknesses for various reasons/hacks.
If you are concerned, the best, simplest and easies thing you can do to remedy this situation is to disable the root user on the server and then assign sudo rights to another user on the system. By simply doing that, you kill off the issue without having to install any additional software.
Yes, some will recommend installing software like Fail2ban on your server and while I do not think it is a bad tool in an online defense arsenal, it can give you a false sense of security if you have not done something as basic as disabling the root user account on the system.
The simplest way to do this on your system, is to first assign sudo rights to any other user on the system other than root. And once that is done, login as that user via SSH and run this command:
sudo passwd -l root
This will effectively lock the root user’s account. So let those bots attempt to login via root from now until forever… With root disabled, the efforts are futile.
That said… Maybe you should be concerned.
But then you say this; emphasis is mine:
These attacks started by attempting root, but have since progressed
to attempting user accounts where I am not certain how they even
guessed the correct usernames (albeit wrong passwords).
Don’t worry if randomly named accounts are being “hacked” even if a few usernames match users on your system.
So you say they are attempting “user accounts” but what users? Do they match valid users on the system? If they don’t match valid users on the system, then don’t worry… Even if every now and then you see an attempt to login as tomcat or testuser. These bots are just cycling through whatever dozens/hundreds/thousands of user names they have in their library to see which account they might be able to get into… And I wouldn’t lose sleep over this.
But if the “hack” attempts are against purely specific/known accounts? Then you should worry.
But that said, if somehow the attacks are targeted only to users that exist on your system, then you can assume the hackers somehow got a copy of your /etc/passwd file. First—despite it’s history name of passwd that file does not contain user passwords, but rather basic user information. And if the attackers have that /etc/passwd file, then you have a MUCH bigger problem.
If specific/known accounts are being “hacked” your web application is possibly hacked.
Typically on web servers, the main point of compromise is not via SSH or something like that but via the web application/server itself. Meaning if your website is based on a known CMS system like WordPress or Joomla! the hackers managed to weasel their way into your system via that web application, which then got into the system on a deeper level that is the equivalent of having SSH access but not deep SSH access.
Meaning, web servers running on software like Apache are managed by a non-root user like www-data or something like that. A compromise of your web application would mean a hacker has the same level of access Apache has, but not anything massively deep on a “write” level… But still a scary level of access on a “read” level.
So it is completely conceivable that a web application on your server was hacked, a payload was dropped on your server at an Apache-user level and they somehow got the /etc/passwd file via that compromised access. And now they are trying to gain entry via usernames in that /etc/passwd file.
What to do if your web application has been hacked.
So should you be scared? If that scenario is the case, yes. But Fail2ban won’t save you now. Disabling root can still save you to an extent. But if your web application is compromised it should be cleaned up. The SSH attempts are just hacking “gravy” on top of a server that is already infected with something.
How to go about cleaning up your web application? There is no simple answer, but if you are using WordPress—for example—consider reinstalling WordPress and then reinstalling your site customizations via backups.
And yes… Stuff like this is why backups and code recovery management is a big deal. But nobody here can explain how you should approach that at this point. It’s a whole other question entirely and based on your use of cPanel might require additional help from an outside tech. But have to mention it.
