I have just a quick question.
I just have noticed that my server is displaying these statistics for SSH:
Are those supposed to be users that are currently logged in, or are they just attempts? Because the only person using it is me and I have not been connecting to it.
SFTP counts as ssh access, so probaly this could be an explanation. Just a statistic will not help to find out, if your server is compromised or not - check the auth.log for ssh logins and their ip locations, also other steps may be a good idea.
I have not been using SFTP either… I will check
auth.log. Thanks for the suggestion.
In any case, I disabled SSH and the chart immediately became flat. I will have to reinstall the server just in case.
Attemps do also count as connections…
Thank you so much for confirming that, @eris.
In any case, what I have done is completely deactivate SSH until I have more time to investigate the issue.
To prevent that, fail2ban with long bans in the recidive policy might help. Also the firewall’s list of malicious IPs is a killer feature (that should be activated by default)
try “ps axu”, “top” and “uptime” commands
Look for high cpu or long execution time processes that should not be there.
I got a message of my provider taking measures to avoid a DDoS attack, which was what made me to inspect the status of the SSH connections.
Even with all the protection measures I have in place, there’s always a way to access to a server (there’s nothing infallible).
In any case, I think I will wipe the server and start over, just in case. I didn’t pay too much attention to it lately and I want to be sure it’s safe.
Thanks for your advice, guys!
Probably no need to reinstall the server.
To protect SSH service do the following:
First of all create a strong SSH key (4096 bit) and setup SSH access with SSH key authentication
In /etc/ssh/sshd_config file:
a) Uncomment “Port 22” directive and change port number to something difficult to find out (above 30000)
b) Uncomment “AddressFamily” directive and change value to “inet” (that disables listening on IPv6 protocol)
c) Set “PermitRootLogin” to “no”
d) Set “PasswordAuthentication” to “no”
e) Restart ssh service (sudo systemctl restart sshd)
(CAUTION: don’t close your current connection to the server! In the meantime, open a second shell and try to connect to the server with the new SSH port. If everything is ok, then you can close the first connection!)
Finally setup in HestiaCP IPtables panel, a firewall rule that allows access to the new SSH port only from your router outgoing IP address (you can find it with https://ipinfo.io/ip)