Linux VPS Security Checklist for Website Servers

To secure a Linux VPS that runs a website, log in with SSH keys instead of passwords, block direct root login, turn on a firewall that only opens the ports your site needs, add fail2ban, keep automatic security updates running, give the web server as little write access as possible, keep the database private, store backups off the server and set up monitoring. On Ubuntu LTS most of this takes an hour or two, and every step below uses tools that ship with Ubuntu or come from its own package archive.

This checklist is for business owners, agencies and developers who have moved a site from shared hosting to a VPS (a virtual private server, where you get your own slice of a machine and full control of it). Full control also means full responsibility: on a VPS, nobody patches or locks down the server unless you do. The commands are written for Ubuntu 24.04 LTS and 26.04 LTS and checked against Ubuntu's own documentation.

#Why a VPS needs its own security checklist

On shared hosting, the host looks after the operating system, the firewall and most updates. On a VPS you get a bare server with a public IP address, and automated scanners across the internet try SSH logins against any address they find. The common ways in are predictable gaps: password logins that can be guessed, software that was never updated, and services such as the database that were left open to the internet.

None of the steps below need special tools. They need care, and a habit of testing each change before closing your current session. Here is the order to work in:

#The checklist at a glance

Use this table as the quick audit. Each row is explained in the steps that follow.

#Steps 1 to 3: lock down SSH

SSH is the remote login to your server, and it is the door attackers try first. Fix it before anything else.

#1. Create an SSH key and add it to the server

On your own computer, create a key pair. Ubuntu's OpenSSH guide recommends the ed25519 type. Then copy the public half to the server:

ssh-keygen -t ed25519
ssh-copy-id username@your-server-ip

Many VPS providers let you paste the public key when you create the server, which does the same job. Log in once with the key to confirm it works.

#2. Use a named admin account, not root

Ubuntu disables the root account's password by default and expects you to use sudo from a normal account. Some VPS images still give you a root login. If yours does, create your own user, add it to the sudo group, and copy your key to it:

sudo adduser yourname
sudo adduser yourname sudo

Working as a normal user means a typing mistake does not run with full power, and every admin action is tied to a named person.

#3. Turn off password and root login

Put your settings in a small file inside /etc/ssh/sshd_config.d/. The sshd_config manual says the first value read for each setting wins, and files in that folder are read before the main file. Some cloud images add their own file there, so give yours a name that sorts first, such as 00-hardening.conf:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Then check the file and restart SSH:

sudo sshd -t
sudo systemctl restart ssh.service

#Steps 4 to 6: firewall, fail2ban and updates

#4. Turn on the ufw firewall

ufw is Ubuntu's default firewall tool, and it starts disabled. Allow SSH first, then web traffic, then enable it:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

If only your office uses SSH and it has a fixed IP address, Ubuntu's guide shows how to allow port 22 from that one address instead. Do not open database, cache or control panel ports to the world. Note that some VPS providers also offer a firewall in their dashboard; using both is fine, as long as the rules agree.

#5. Add fail2ban

fail2ban reads login logs and bans IP addresses that fail too many times, by adding firewall rules for a set period. Install it with sudo apt install fail2ban. Then confirm the SSH jail is running with sudo fail2ban-client status sshd. If it is not listed, enable the sshd jail in the configuration under /etc/fail2ban/ and restart the service.

Be clear about what it does. The fail2ban project itself says it cannot remove the risk of weak authentication, which is why step 3 matters more.

#6. Keep automatic security updates on

Ubuntu Server installs the unattended-upgrades package by default and applies security updates once a day. Check that it has not been removed or switched off: the file /etc/apt/apt.conf.d/20auto-upgrades should set both Update-Package-Lists and Unattended-Upgrade to "1". If the package is missing, install it with sudo apt install unattended-upgrades.

By default it installs security updates only, not every new version, which keeps surprise breakage low. Some updates, such as kernel fixes, only take effect after a reboot, so plan a quiet time each month to restart the server. Also note that updates only cover software from Ubuntu's archive. A WordPress site, its plugins, Node.js apps and anything you installed by hand still need their own updates.

#Steps 7 to 10: the web server, database, backups and monitoring

#7. Give the web server as little write access as possible

On Ubuntu, Nginx and Apache run as the www-data user. That user needs to read your site, but it should not be able to rewrite your code. WordPress's own hardening guide says core files and plugins should be writable only by your user account, recommends 755 for folders and 644 for files, and suggests 400 or 440 for wp-config.php. The upload folder is the exception that the web server must be able to write to.

The same idea applies to the database user: WordPress needs SELECT, INSERT, UPDATE and DELETE for normal running. Its guide warns against removing the schema-changing rights entirely, because plugin installs and major updates need them, so the safer step is one database user per site rather than one shared user with access to everything.

#8. Keep the database private

MySQL listens on port 3306 by default, and its own default setting accepts connections on every network interface. MySQL's security guidelines say this port should not be reachable from untrusted hosts. On a single server, make sure the database listens only on 127.0.0.1 (the bind-address setting), do not open 3306 in ufw, and use an SSH tunnel when you need to connect from your computer. If the database is on a separate server, allow only the web server's private IP.

#9. Store backups somewhere else

A backup on the same VPS disappears with the VPS. Keep at least one copy in another provider or region, include both files and the database, and test a restore before you need it. Provider snapshots are useful for quick rollbacks, but they usually live in the same account, so an account compromise or a billing problem can take them too. My website backup and disaster recovery plan explains how many copies to keep and where, and the backup and disaster recovery service is built around exactly this separation.

#10. Monitor the server

You cannot fix what you do not notice. At minimum, set up an outside uptime check, disk space and memory alerts, and a check that the SSL certificate renews. Send alerts to someone who will act on them, not a shared inbox nobody opens. My comparison of website monitoring tools covers the options, and the website monitoring setup service covers this if you want it done once and done properly.

#When to get help

You can work through this checklist yourself if you are comfortable in a terminal and have the provider's rescue console as a fallback. Get help when:

• The server already runs a live shop or client sites, and a lockout or a wrong firewall rule would mean downtime.
• You manage several servers and need the same settings and alerts on all of them.
• The server has been compromised, or you see users, cron jobs or files you did not create. Hardening a hacked server does not remove what is already there; start with the steps in my guide on cleaning up a hacked WordPress site.
• You run a control panel such as cPanel, which manages some of these settings itself (see cPanel and WHM explained).

My VPS and cloud server management covers set-up, hardening, updates and monitoring for website servers. If you are still deciding whether a VPS is right for you, read VPS hosting explained first, and for the application side of security, see the web application security checklist for business owners.