Brute Force attack ticket
Hello,
this morning while I as drinking my coffee I received an ticket from Linode team that one of my Linodes is subject of a Brute Force attack and I need to point them out some steps that I took to prevent this activity in the future, IF NOT they will place network restrictions on my VM.
So..I immediately changed the root password(it was enough secured, but just in case..) and disabled the SSH login for the root. I have only one user inside the Debian who has root privileges, all the rest of the users are regular ones with no special access.
I checked the journactl and I have found dozens of random user names trying to open SSH session, I assume with random passwords. They even tried to enter with postgres user, but I've set a bit more complicated password and it should be fine. Just in case I've installed fail2ban and started the daemon, almost immedialty it started to ban IPs :(
Even right now there are still new attemps to open SSH sessions with the root.
Is that something that I have to be concerned? Do you have any suggestions how to improve my security?
Thank in advance!
1 Reply
There seems to be a pretty common misconception that these Terms of Service (ToS) are a warning about inbound malicious activity. Anytime we open one of these tickets, it actually means that someone has identified your IP address as the source of malicious/abusive behavior pointed towards them. In most cases, this is not intentional behavior on the Linode owners' part, but due to a system compromise.
Since public facing IPs are inherently less secure than private ones, the best defense is to immediately secure your Linode after it has been deployed.
Anytime a ToS Ticket is opened on your account, we require urgent response from you to make sure the situation has been identified and fully resolved. Depending on the nature of the activity identified, you may only have 24 hours before we are required to apply network restrictions to prevent the recurrence of that activity.
You've already described some great security methods, but just to aggregate some links for everyone else:
- Change your Root Password - Make sure that you use an adequately complex password that includes Capital/lower-case letters, numbers, and symbols - 1Password Browser password generator
- Setup Fail2Ban to block malicious SSH logins
- Configure a Firewall using either our Cloud Firewall or UFW (Debian/Ubuntu) or Firewalld (CentOS/RedHat)
- Scan for vulnerabilities/malware using ClamAV
- Setup SSH Key-pair authentication
Based on the steps you have specifically described, I would only recommend setting up SSH authentication and disabling root access via SSH (if you haven't already done so).