# A Beginner VPS Security Checklist

- Link: https://offshorehosting.pk/a-beginner-vps-security-checklist/
- Published: 2026-10-25T10:23:00+00:00
- Author: admin

# 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.

## 1. Update Everything Before Anything Else

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.

    ```bash
    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.

## 2. Create a Non-Root User and Disable Root Login

Never administer a server as root over SSH. Create a dedicated user with sudo privileges,
and use that account for everything:

    ```bash
    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.

## 3. Switch to SSH Key Authentication

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](https://offshorehosting.pk/blog/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.

## 4. Configure the Firewall — SSH First

A firewall that blocks everything except what the server needs is the next layer.
On Ubuntu and Debian, UFW (Uncomplicated Firewall) makes this straightforward:

    ```bash
    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.

## 5. Install Fail2Ban

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:

    ```bash
    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.

## 6. Secure the Web Server and Applications

Server-level security is only half the job. The applications running on the server
need the same attention:

 * **Use HTTPS everywhere.** Obtain a free certificate from Let’s Encrypt and redirect
   all HTTP traffic to HTTPS. Unencrypted login pages and admin areas are an open
   invitation.
 * **Keep applications updated.** WordPress core, plugins and themes should be updated
   promptly — security releases exist because vulnerabilities were found. See [how to update WordPress plugins and themes safely](https://offshorehosting.pk/blog/how-to-update-wordpress-plugins-and-themes-safely).
 * **Remove unused software.** Every installed package is a potential vulnerability.
   Uninstall services you do not use, delete old applications and test sites, and
   remove default accounts and sample data.
 * **Set sane file permissions.** Web files should be readable by the web server
   but not writable by it, except for the specific directories that need uploads(
   such as `wp-content/uploads`). Files that are world-writable are a common path
   for attackers to plant malicious code.
 * **Disable directory listing** on the web server, so visitors cannot browse your
   file structure.

## 7. Set Up Backups Before You Need Them

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](https://offshorehosting.pk/blog/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.

## 8. Monitor and Log

You cannot respond to what you cannot see. At a minimum:

 * **Enable system logging and check it.** Review the authentication log (`/var/
   log/auth.log` on Debian/Ubuntu) periodically for unusual login attempts.
 * **Set up resource monitoring and alerts.** Unusual CPU or network activity can
   be the first sign of a compromise — a crypto miner, for example, shows up as 
   sustained high CPU. See [how to monitor VPS CPU, RAM and disk usage](https://offshorehosting.pk/blog/how-to-monitor-vps-cpu-ram-and-disk-usage).
 * **Enable automatic security notifications.** Your operating system’s update tool
   and your hosting provider can both alert you to security issues. Make sure those
   alerts reach an inbox someone reads.

## 9. Limit What Runs and Who Can Reach It

A few final hardening steps that cost little and help a lot:

 * **Disable password authentication for all services**, not just SSH — database
   users, control panels and applications should all use strong, unique credentials.
 * **Use a non-standard SSH port** if you wish. This is not real security — it only
   reduces log noise — but less noise means real problems are easier to spot. If
   you change the port, update the firewall rule and your SSH configuration at the
   same time.
 * **Restrict SSH by IP** if you always connect from the same place. A firewall 
   rule that allows SSH only from your office or home IP address closes the door
   to the entire internet.
 * **Keep a list of what is installed.** Know which services are running (`sudo 
   ss -tlnp` lists listening ports) and why. Anything you cannot explain should 
   be investigated, not ignored.

## The Checklist, Summarised

 * [ ] System fully updated; automatic security updates enabled
 * [ ] Non-root sudo user created; root SSH login disabled
 * [ ] SSH key authentication working; password authentication disabled
 * [ ] Firewall enabled with SSH allowed first; only needed ports open
 * [ ] Fail2Ban installed and running
 * [ ] HTTPS enforced with a valid certificate
 * [ ] Applications updated; unused software removed
 * [ ] File permissions reviewed; directory listing disabled
 * [ ] Automated off-server backups configured; restore tested
 * [ ] Monitoring and alerts in place; logs reviewed regularly

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.

## Sources

 * Ubuntu UFW firewall documentation: https://wiki.ubuntu.com/UFW
 * Securing SSH on a Linux server: https://noc.org/learn/securing-ssh
 * Fail2Ban: https://www.fail2ban.org/
 * WordPress: Backing up your database: https://developer.wordpress.org/advanced-
   administration/security/backup/database/
 * Let’s Encrypt — getting started: https://letsencrypt.org/getting-started/

## Sources

 * {‘title’: ‘Ubuntu UFW firewall documentation’, ‘url’: ‘https://wiki.ubuntu.com/
   UFW’}
 * {‘title’: ‘Securing SSH on a Linux server (NOC.org)’, ‘url’: ‘https://noc.org/
   learn/securing-ssh’}
 * {‘title’: ‘Fail2Ban — official project site’, ‘url’: ‘https://www.fail2ban.org/’}
 * {‘title’: ‘WordPress: Backing up your database (Advanced Administration Handbook)’,‘
   url’: ‘https://developer.wordpress.org/advanced-administration/security/backup/
   database/’}
 * {‘title’: "Let’s Encrypt — getting started", ‘url’: ‘https://letsencrypt.org/
   getting-started/’}