The moment your VPS goes online, automated bots start probing it — scanning for open ports, guessing SSH passwords, and hunting for outdated software. Most compromised servers aren’t singled out by attackers; they simply failed basic hygiene. The good news: half an hour of hardening shuts out the vast majority of those automated attacks. Below is a practical, copy-paste-ready checklist.
1. Update the System and Enable Automatic Security Patches
Unpatched packages are the easiest way in. Start with a full upgrade:
sudo apt update && sudo apt upgrade -y
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgradesOn RHEL/CentOS-based systems, use dnf upgrade -y and the dnf-automatic package instead.
2. Create a Sudo User and Stop Using Root
Running everything as root means one mistake, or one leaked credential, hands an attacker full control:
adduser deploy
usermod -aG sudo deployLog in as this user from now on, and reach for sudo only when you actually need it.
3. Harden SSH: Keys Instead of Passwords
Generate a key pair on your local machine and copy it to the server:
ssh-keygen -t ed25519
ssh-copy-id deploy@your-server-ipThen edit /etc/ssh/sshd_config and set:
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yesOptionally move SSH off the default port (e.g. Port 2222) to cut down on log noise. Restart with sudo systemctl restart sshd — but keep your current session open and confirm you can log in from a fresh terminal first.
4. Set Up a Firewall with UFW
Deny everything by default and open only what you actually run:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # your SSH port
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verboseIf your database only serves local apps, never expose port 3306/5432 to the public.
5. Block Brute-Force Attacks with Fail2ban
sudo apt install fail2ban -y
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localIn jail.local, enable the sshd jail and set sensible limits:
[sshd]
enabled = true
port = 2222
maxretry = 5
bantime = 1hStart it with sudo systemctl enable --now fail2ban, and check active bans any time with sudo fail2ban-client status sshd.
6. Back Up Before You Need It
Hardening lowers the risk; backups are what actually save you when something goes wrong. At minimum, schedule a nightly database dump shipped off-server:
0 3 * * * mysqldump -u root dbname | gzip > /backup/db-$(date +\%F).sql.gzUse your provider’s snapshot feature weekly, and test a restore at least once — an untested backup is just a hope, not a plan.
FAQ
Is changing the SSH port real security?
Not by itself — it’s obscurity, not protection. But paired with key-only login and Fail2ban, it noticeably cuts the automated scan noise in your logs.
Do I still need Fail2ban if password login is disabled?
Yes. It also guards other services (web login pages, mail, FTP) and stops bots from burning your server’s CPU and bandwidth on endless attempts.
How often should I audit my VPS?
Monthly is a reasonable baseline: review last and auth logs, check listening ports with ss -tulpn, and confirm your backups actually restore.
Stuck on any step, or want a deeper guide on a specific tool? Drop a comment on fenij.com and we’ll help you work through it.
