Secure a Linux VPS: the complete checklist (2026)

Security checklist: overview

Apply these steps in order, each one reinforcing the next.

Action	Priority	Estimated time	Detailed guide
System updates	Critical	5 min	Section below
Create a non-root user	Critical	5 min	Section below
Harden SSH (key + disable root/password)	Critical	10 min	SSH key guide
Configure UFW (firewall)	Critical	5 min	UFW guide
Install Fail2ban	High	10 min	Fail2ban guide
Enable HTTPS (Certbot)	High	5 min	Certbot guide
Set up backups	High	15 min	Section below
Basic monitoring	Medium	5 min	Section below

1. System updates

Outdated packages are the leading cause of compromise. Apply updates as soon as you first log in, then automate them.

Initial update

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y

Automate security updates

The unattended-upgrades package applies security updates automatically without manual intervention. Source: wiki.debian.org/UnattendedUpgrades

sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Answer "Yes" to the question asked by the configurator. Security updates are then applied automatically every night.

2. Create a non-root user with sudo

Logging in and operating as root all the time is bad practice: a command mistake or a compromise has an immediate impact on the whole system. Create a dedicated user with sudo privileges.

adduser username
usermod -aG sudo username

Check that sudo works before closing the root session:

su - username
sudo whoami

The command must return root. Once confirmed, use this user for all subsequent operations.

Source: wiki.debian.org/sudo

3. Harden SSH

SSH is the most common attack vector on an exposed VPS. Three fundamental measures: key-based authentication, disabling root login, disabling password authentication.

SSH key authentication

Generate and deploy an SSH key from your local machine, then verify the connection before disabling passwords. The full procedure is in the dedicated guide: OuiHeberg SSH key guide.

Disable root login and password authentication

Once the key-based connection is confirmed, edit /etc/ssh/sshd_config:

sudo nano /etc/ssh/sshd_config

Change or add these directives:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Reload SSH:

sudo systemctl reload ssh

Source: man.openbsd.org/sshd_config

Change the SSH port (optional)

Changing the SSH port (for example from 22 to 2222) is not a security measure in itself: a port scan detects it within seconds. However, it significantly reduces the volume of automated attempts in the logs, which makes monitoring easier. If you change the port, open that port in UFW before reloading SSH, and do not close port 22 before you have verified the connection on the new port.

# In /etc/ssh/sshd_config
Port 2222

4. Configure the UFW firewall

UFW (Uncomplicated Firewall) is the recommended interface for managing iptables rules on Debian and Ubuntu. Basic rule: block all incoming traffic by default, open only the ports you need.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw enable

Full guide (per-service rules, connection rate limiting, verification): OuiHeberg UFW guide.

5. Install Fail2ban

Fail2ban watches the system logs and automatically bans IP addresses that pile up failed login attempts. Complementary to UFW: UFW filters ports, Fail2ban filters behavior.

sudo apt install -y fail2ban

Recommended configuration, monitoring and unbanning are covered in the dedicated guide: OuiHeberg Fail2ban guide.

6. Enable HTTPS with Certbot

A TLS certificate is essential for any exposed web service. Certbot automates obtaining and renewing Let's Encrypt certificates for Nginx and Apache.

sudo apt install -y snapd
sudo snap install certbot --classic
sudo certbot --nginx -d example.com -d www.example.com

Automatic renewal, wildcard certificates and troubleshooting common errors are covered in the dedicated guide: OuiHeberg Certbot guide.

7. Backups

An untested backup is not a backup. The 3-2-1 rule is the minimum standard: 3 copies of the data, on 2 different media, including 1 offsite.

Basic backup with tar

# Back up an application directory
tar -czf /root/backup-$(date +%F).tar.gz /var/www/mysite

# Back up a MariaDB/MySQL database
mysqldump -u root db_name > /root/backup-bdd-$(date +%F).sql

Automate with cron

sudo crontab -e

Add a line for a daily backup at 3 AM:

0 3 * * * tar -czf /root/backup-$(date +\%F).tar.gz /var/www/mysite

VPS snapshots

OuiHeberg VPS plans include backup slots and snapshots configurable from the management panel. A snapshot captures the complete state of the VPS (system + data) and allows a fast restore in case of a major incident.

Test the restore

Schedule a restore test at least once per quarter. A backup whose restore has never been verified cannot be considered reliable.

8. Basic monitoring

Monitoring does not require a complex tool to get started. The system logs contain most of the warning signals.

Monitor SSH login attempts

# Latest successful and failed logins
sudo journalctl -u ssh --since "24 hours ago" | grep -E "Accepted|Failed"

# Equivalent via auth.log (Debian/Ubuntu)
sudo grep -E "Accepted|Failed" /var/log/auth.log | tail -50

Active network connections

# Listening ports and established connections
sudo ss -tlnp

Check that only the expected ports are open. Any unknown port deserves investigation.

System load

# CPU load, memory, processes
top
# or, if installed:
htop

Warning signals to watch for

Unexplained CPU or memory spike
Unknown process consuming resources
Outgoing connections to unknown IPs
Recently modified files in /etc or /usr/bin

# Files modified in the last 24h in /etc
sudo find /etc -mtime -1 -type f

Frequently asked questions

In what order should these measures be applied?

Follow the order of the checklist at the top of this guide. System updates and creating a non-root user first, hardened SSH second, UFW third. Do not enable UFW before opening the SSH port: it is the most common mistake that locks you out of the VPS.

Should you install an antivirus on a Linux VPS?

Traditional antivirus software is a poor fit for Linux servers. The attack surface is better reduced by the measures in this guide (updates, hardened SSH, firewall, Fail2ban) than by an antivirus. ClamAV can be useful if the VPS hosts files uploaded by users (forms, file sharing), but remains optional for most cases.

How do I know if my VPS has been compromised?

The most common signals: unexplained CPU spike, unknown process in top, abnormal outgoing connections in ss -tlnp, suspicious entries in /var/log/auth.log, recently modified system files. In case of serious doubt, restoring from a clean snapshot is safer than an incomplete investigation.

Are these measures enough for a production VPS?

They cover the most common attack vectors and form a solid foundation. For environments with high requirements (sensitive data, regulatory compliance), additional measures come on top: regular security audits, intrusion detection (AIDE, auditd), network segmentation, volume encryption. This guide covers the fundamental level applicable to any VPS exposed to the Internet.

Will this VPS host a site currently hosted elsewhere? Secure it first, then follow the guide to migrating from shared hosting.