How to prevent website hacking on VDS server?

Question

Node.js

Created a site with a simple NODE.JS backend, hosted it on VDS timeweb for educational purposes. Nothing special, a site with authorization, an admin panel that allows you to change content, a contact form... After some time, I get a message:
TIMEWEB> Malicious outgoing activity.

Dear Customer!

Malicious scripts have been detected on your account that carry out outgoing requests of a malicious nature, for which we received a complaint from the administrator of a third-party service. Here is a fragment of the logs of the server, to which there was outgoing malicious activity from your account:
Jan 23 22:29:51 web0 sshd[8853]: Address 185.178.47.54 maps to vds-***.ru, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Jan 23 22:29:51 web0 sshd[8853]: Invalid user old from 185.178.47.54 port 60056
Jan 23 22:29:51 web0 sshd[8853]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.178.47.54
Jan 23 22:29:53 web0 sshd[8853]: Failed password for invalid user old from 185.178.47.54 port 60056 ssh2
Jan 23 22:29: 53 web0 sshd[8853]: Received disconnect from 185.178.47.54 port 60056:11: Bye Bye [preauth]
Jan 23 22:29:53 web0 sshd[8853]: Disconnected from 185.178.47.54 port 60056 [preauth]
Jan 23 22: 33:04 web0 sshd[9392]: Address 185.178.47.54 maps to vds-***.ru, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Jan 23 22:33:04 web0 sshd[9392]: Invalid user public from 185.178.47.54 port 53556
Jan 23 22:33:04 web0 sshd[9392]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=185.178.47.54

And this is not the first time. I'm a front-end developer and I'm not well versed in the security of the site and the server side.
I would be glad if you tell me what the vulnerability might be, what needs to be checked, what to pay attention to so that attackers cannot hack the site?

Answer 1

If these are your IPs, then you have a virus on the server.

Answer 2

this is easiest to cover with firewall rules, but, most likely, the shell on the site with full rights

Answer 3

Let's see, canceled the root user - maybe this will help

Answer 4

Check the server with some kind of hijacker, change passwords for everything (ssh, ftp, admin) and check your application for vulnerabilities. Most likely old broken libraries and so on are used.
It makes no sense to close connections to ports 22, since you are being brute and you just turn off connections, and the virus will remain as it was, and the vulnerability through which it got to the server

Answer 5

This is nonsense, not activity. We found ssh and are trying to stupidly brute it. Set up iptables so that ssh is available only from the IPs you need - and that's it.

Answer 6

change all the passwords you have, check the list of users (maybe there are some new ones not created by you), check your application scripts, you may have implemented your script, check cron tasks
and yes, check application vulnerabilities, maybe somewhere there are places through which it was possible to inject the code, or maybe the password was too simple in the admin panel and through the admin panel you can implement something that should not be (extended rights, writing scripts, etc.)