A brand new Linux VPS starts getting probed by bots within minutes of going online. The good news: almost every successful attack uses a handful of well-known doors, and you can close them in under an hour. Work through these in order.
1. Update everything first
Before anything else, patch the system:
sudo apt update && sudo apt upgrade -y
(Use dnf upgrade on Rocky, Alma or Fedora.) Most break-ins exploit known bugs that already have fixes, so staying current is the highest-value habit on this list.
2. Create a non-root user
Never do daily work as root. Create a user and give it sudo:
adduser deploy
usermod -aG sudo deploy
Log in as that user from now on.
3. Switch to SSH keys and turn off password login
Passwords get brute-forced; keys do not. Generate a key on your own machine and copy it up:
ssh-copy-id deploy@your-server-ip
Then in /etc/ssh/sshd_config set PasswordAuthentication no and PermitRootLogin no, and restart SSH. The full walkthrough is in Connecting to your Linux VPS over SSH.
Test a new SSH session before closing your current one. If something is wrong, you still have a way back in.
4. Set up a firewall
Allow only what you use. With UFW:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw enable
Open extra ports (web, game) only as you need them.
5. Install fail2ban
fail2ban watches your logs and bans IPs that fail to log in repeatedly:
sudo apt install fail2ban -y
The defaults already protect SSH and cut brute-force noise dramatically.
6. Move SSH off port 22 (optional)
A different SSH port will not stop a determined attacker, but it removes almost all of the automated noise hammering the default port. Update your firewall rule if you do this.
7. Turn on automatic security updates
So you are covered between manual patch sessions:
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades
8. Lock down what listens
See what is exposed:
sudo ss -tulpn
If a service does not need to face the internet, bind it to localhost or firewall it off. Databases especially should never listen on a public address.
9. Back up before you need to
Security includes recovery. Keep regular, off-server backups and test a restore once. A backup you have never restored is a guess, not a backup.
10. Keep an eye on it
Check journalctl and your auth logs now and then, or forward them somewhere central. You cannot react to what you never see.
Want this baked in? Vastrox VPS plans ship with DDoS protection at the network edge and optional managed hardening, so steps like firewalling and patching can be handled for you.
FAQ
What is the single most important step?
SSH keys with password login disabled, plus staying patched. Those two close the doors attackers use most.
Do I still need a firewall behind a host's DDoS protection?
Yes. DDoS protection handles floods at the network edge; a firewall controls which services are reachable at all. They solve different problems.
Is changing the SSH port enough on its own?
No. It cuts noise but is not real security. Use it on top of keys, a firewall and fail2ban, never instead of them.
Need a hand hardening yours? Talk to our team. Security tuning is part of every managed plan.