VPS Security Checklist: 10 Steps to Harden Your Server

Fresh VPS instances are scanned within minutes of getting a public IP. Run this checklist before you install your application and you will have already blocked the majority of attacks.

A new VPS with a public IP is scanned within minutes. Most of those scans look for the same handful of weaknesses: default passwords, open administration ports, unpatched services and over-permissioned users. Closing them takes under an hour and prevents the overwhelming majority of compromises. Work through this checklist before your application goes live.

1. Install SSH keys, then kill password login

Generate a key pair locally, install the public key in ~/.ssh/authorized_keys, confirm you can log in, then set PasswordAuthentication no and PermitRootLogin prohibit-password in /etc/ssh/sshd_config. Restart the daemon and test in a second session before you close the first one. This single change ends brute-force noise permanently.

2. Default-deny firewall

Enable UFW (or nftables) with an allow-all outgoing, deny-all incoming policy, then open only what you need: SSH (ideally on a non-standard port, restricted to your IP), your web server, and your application port. Database and admin ports should never be open to the world - bind them to localhost or a private network and reach them through SSH tunneling.

3. Ban repeat offenders automatically

Install fail2ban and enable the sshd jail. It watches auth logs and blocks IPs after repeated failures, which removes a surprising volume of background attacks. Add jails for your web application's login pages too, with sensible thresholds so you do not lock out legitimate users.

4. Patch aggressively and automate it

Run apt update && apt upgrade (or your distro's equivalent) weekly, immediately for critical CVEs. Consider enabling automatic security updates for base packages while reviewing application-level updates yourself.

5. Least privilege for every account

• Create named users with sudo rights instead of sharing one admin login.
• Never run application services as root; use dedicated system users.
• Restrict file permissions: application directories writable only by their owner.
• Disable direct root SSH and audit /etc/passwd for unexpected accounts.

6. Turn off everything you are not using

Every open port is an attack surface. Remove or stop services you do not use, disable unused PHP modules, and close the control panel port from public access. A minimal server with three open ports is dramatically safer than a kitchen-sink server with ten.

7. Protect the web layer

Force HTTPS everywhere, keep TLS configured with modern ciphers, hide server version headers, and place rate limiting in front of login and API endpoints. If you run PHP-FPM or a Node app behind Nginx, make sure the upstream is only reachable from localhost.

8. Monitor and log

Ship logs somewhere that is not the compromised box: a central log service, or at minimum daily rotation with off-server copies. Track disk, CPU, memory and outbound traffic, because a sudden bandwidth spike is the classic sign of a crypto-miner or spam bot. Set alerts on unusual process names and new listening ports.

9. Backups you have tested

An untested backup is a rumour. Keep automated daily backups off the machine, retain at least 7-30 days, and perform an actual restore into a fresh server once a quarter. Include configuration and databases, not just web files.

10. Have an incident response plan

Decide in advance: who gets paged, how you snapshot a compromised box for forensics, when you rebuild rather than clean, and how you rotate every credential afterwards. In practice, rebuilding from a known-good image is safer and faster than chasing an attacker through your filesystem.

Run this list once and your VPS will be hardened beyond the average target. Repeat the audit quarterly, because new services and updates quietly reopen doors.