Dealing with Brute Force Attacks has been very challenging. In the end, I had to stop the VPS instance where my AlmaLinux server was deployed. I’ve been trying to improve the security, but I am quite new to Linux and server-side technical stuff.
I set up a firewall and Fail2Ban. Fail2Ban was blocking any IP address that used the wrong password, but even only after one failed attempt, for 24 hours. I also completely disabled the root user because many of the failed login attempts were targeting it. To enhance security, I created a new user with a randomly generated password and granted it root access.
Despite these efforts, my CPU usage shot up to 100%. I believe the brute force attack started around the time I configured the firewall and Fail2Ban. I now realize that accessing SSH in public can be risky, so I’ve closed all ports except for 22 (SSH) and 5000 (for those who need access).
Aside from these measures, could anyone suggest additional ways to enhance security? I’m eager to learn and find the best ways to block malicious hackers.
This script is a firewalld-based solution that allows only your country’s IP addresses and blocks the top sources of attacks (editable in the DROP_COUNTRY_LIST).
Please change the country code (e.g., JP for Japan) and other relevant parameters to match your country, then run the script on your server. The IP address list is automatically updated every day by cron.
Caution:
Only users from the allowed country will be able to access the server. If you travel abroad or use a foreign VPN, remember to adjust your settings accordingly.
You have already taken some very important steps, which show that you have tried to prevent brute force attacks. I recommend that you use passwords that are as complex as possible. Pay attention to users on the server.
What I can recommend:
1. Moving SSH to a less common port significantly reduces automated scans:
sudo nano /etc/ssh/sshd_config
Port (THE PORT YOU WANT)
sudo systemctl restart sshd
2. Key authentication is much more secure than password authentication: PasswordAuthentication no
Moving sshd to a higher port will certainly help to reduce log entries, but is not really a security measure as port-scanning is trivial.
The suggestion to use ssh-keys instead of passwords (at a minimum) should definitely be a priority on your list.
You may even go as far as installing wireguard VPN server, and only exposing ssh over that, so there’s no sshd running on your public IP. Instead, it can only be accessed via clients (which you control) on your VPN. Everyone who connects would need to either run wireguard locally too, or connect to a jump host first, - so this solution is not suitable for all situations.
If you’re not used to such things you you should definitely TEST thoroughly in Lab conditions before deploying to production as any mistake could leave you locked out and needing a reinstall. But it is a nice way to avoid ssh on a public server.