8 Essential Security Steps for Every Production VPS

A fresh server is exposed to the internet within seconds of booting, and automated bots start probing it almost immediately. Hardening is not paranoia — it is basic hygiene. The good news is that a handful of steps eliminate the overwhelming majority of real-world attacks. Here are the essentials for any production VPS.

1. Disable password and root SSH login

Password brute-forcing is the single most common attack against exposed servers. Use SSH keys and turn passwords off entirely. In /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no

Reload SSH with systemctl reload ssh — but confirm you can log in with your key in a second terminal before closing your current session.

2. Run a firewall with a default-deny policy

Only expose the ports you actually need. On Ubuntu, ufw makes this simple:

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

3. Keep the system patched automatically

Most breaches exploit known vulnerabilities that already have fixes available. Enable unattended security updates so you are not relying on memory:

apt install unattended-upgrades -y
dpkg-reconfigure --priority=low unattended-upgrades

4. Add fail2ban

fail2ban watches your logs and temporarily bans IP addresses that show malicious patterns, such as repeated failed logins. It is a lightweight, high-value addition:

apt install fail2ban -y
systemctl enable --now fail2ban

5. Use a non-root user for everything

Do your daily work as an unprivileged user and escalate with sudo only when needed. This limits the blast radius of any mistake or compromise, and it creates an audit trail of privileged actions.

6. Encrypt everything in transit

Serve all web traffic over HTTPS with a free Let’s Encrypt certificate, and make sure internal service-to-service traffic is encrypted too. There is no longer any excuse for plaintext on the public internet.

7. Back up — and test the restore

Security includes recovering from ransomware, hardware failure, and your own mistakes. Automate regular backups, store them off the server, and — crucially — periodically test that you can actually restore from them. A backup you have never restored is a hope, not a plan.

8. Monitor and alert

You cannot respond to what you cannot see. Track CPU, memory, disk, and — importantly — authentication logs. Set alerts for unusual spikes and failed-login surges so you learn about problems from your monitoring, not from your users.

The 20% that stops 80% of attacks

None of these steps requires deep security expertise, and together they close the doors that automated attacks rely on. Do them once, bake them into your server provisioning, and every new machine starts secure by default.