Home / Blog / VPS and Infrastructure / A Beginner VPS Security Checklist
A new VPS is probed by automated attacks within minutes of going online. Bots scan for open ports, try common passwords, and test known vulnerabilities — not because anyone targeted you personally, but because scanning the whole internet is cheap. Security on a VPS is therefore not optional and not something to do “later, when the site is ready”. It is the first job, before anything real is hosted.
This checklist covers the essential steps for a Linux VPS. Work through it in order on every new server. Each step is small on its own; together they remove the easy wins attackers depend on.
The moment you first log in, update the system. A fresh server image can be weeks or months behind on security patches, and known vulnerabilities in outdated packages are the first thing scanners test for.
sudo apt update && sudo apt upgrade -y
On RHEL-based systems (AlmaLinux, Rocky Linux, CentOS Stream), the equivalent is sudo dnf update -y. After updating, reboot if a kernel update was installed, and confirm the system comes back up cleanly.
Then enable automatic security updates so the server does not drift out of date. On Ubuntu and Debian, that is unattended-upgrades; on RHEL-based systems, dnf-automatic. Automatic updates for security patches are a sensible default. Automatic updates for all packages, including major version changes, are riskier — test those on a staging server first.
Never administer a server as root over SSH. Create a dedicated user with sudo privileges, and use that account for everything:
adduser deploy
usermod -aG sudo deploy
Then disable root login over SSH. In /etc/ssh/sshd_config, set:
PermitRootLogin no
Restart SSH afterwards (sudo systemctl restart ssh), and test that you can still log in as your new user before closing your current session. Losing access because of a configuration mistake is the most common self-inflicted VPS outage.
Passwords can be guessed; a properly generated SSH key cannot. Generate an Ed25519 key pair on your own computer, copy the public key to the server, and then disable password authentication entirely. This single change eliminates the entire class of brute-force password attacks against SSH.
The full procedure — generating keys, copying them, setting permissions, and disabling password login — is covered step by step in SSH keys and secure server access. Do not skip it: password-only SSH on a public server is the single biggest security hole in beginner VPS setups.
Warning: do not disable password authentication until you have confirmed that key login works. If you lock yourself out, recovery requires console access through your hosting provider — which is slow and stressful. Always keep a second SSH session open while you make the change, so you can revert it if something goes wrong.
A firewall that blocks everything except what the server needs is the next layer. On Ubuntu and Debian, UFW (Uncomplicated Firewall) makes this straightforward:
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
The order matters: allow SSH before enabling the firewall. Enabling UFW without an SSH rule cuts your own connection, and recovery requires console access. If SSH runs on a non-standard port, allow that port instead of 22. On RHEL-based systems, the equivalent tool is firewalld.
Open only the ports your services actually use. A web server needs 80 and 443; a database should not be reachable from the internet at all — it should listen only on localhost or a private network. Every open port is an opportunity; every closed port is one less.
Even with key-only SSH, bots will keep trying to log in, filling your logs and wasting resources. Fail2Ban watches the logs and temporarily bans IP addresses that show malicious patterns — repeated failed logins, for example. Install it and enable the SSH jail:
sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
Fail2Ban’s default configuration protects SSH out of the box. You can add jails for other services (Nginx, Apache, WordPress login attempts) as you add them to the server. Check banned IPs occasionally with sudo fail2ban-client status sshd to see what is being blocked — it is usually a sobering list.
Server-level security is only half the job. The applications running on the server need the same attention:
wp-content/uploads). Files that are world-writable are a common path for attackers to plant malicious code.A secure server can still fail — hardware faults, a mistaken command, a successful attack. Backups are the recovery plan. Configure automated backups of both files and databases, store them off the server, and test a restore. This applies to a VPS exactly as it does to shared hosting; see how to back up and restore WordPress for the WordPress-specific procedure. For a VPS, a provider snapshot is a useful extra layer, but it is not a substitute for file-level backups stored elsewhere — a snapshot on the same provider does not help if the provider has a problem.
You cannot respond to what you cannot see. At a minimum:
/var/log/auth.log on Debian/Ubuntu) periodically for unusual login attempts.A few final hardening steps that cost little and help a lot:
sudo ss -tlnp lists listening ports) and why. Anything you cannot explain should be investigated, not ignored.Security is not a one-time task. Revisit this checklist after every significant change to the server, and review the server’s state at least monthly. The goal is not perfection — it is to be a harder target than the thousands of unpatched, password-only servers the bots will try first.
Containers package an application with everything it needs, so it runs the same way on any server. This guide explains what Docker containers are, when they help on a VPS, and the basics of running them well.
GPU hosting rents you a server whose graphics processor does the heavy lifting — for AI models, rendering and other parallel work. This guide explains who actually needs it, who does not, and what to check before buying.
A dedicated server gives you the whole machine — and the whole responsibility for it. Know exactly which jobs are yours before you sign, or pay for a managed plan.