VPS Security Checklist: 12 Steps After Setup

A VPS security checklist is a repeatable sequence of hardening steps applied to a freshly provisioned virtual private server before it serves production traffic. Because a new VPS answers on a public IP address within minutes of creation, unpatched services and weak SSH authentication are exposed to automated scanning almost immediately. The order of the steps matters as much as the steps themselves: identity and access changes come first, network filtering second, and monitoring and recovery last. This guide covers prerequisites, twelve numbered hardening steps, verification commands, common problems, and answers to frequent questions about Linux server hardening, firewall choice, TLS and backups.

Before you start: prerequisites for VPS hardening

You need working SSH access, a sudo-capable account, and a maintenance window in which no one else depends on the server. If the provider gives you a web console or out-of-band access, confirm it works before you change SSH or firewall settings, because that console is your recovery path if a rule locks you out. BalHost virtual servers are provisioned with full root access, so you can perform every step below without asking support to unlock anything.

Make a list of the ports your application actually needs. A typical web server needs 22 (SSH, ideally moved or restricted), 80 and 443 (HTTP and HTTPS); a database server may need 3306 or 5432 only from specific application hosts. Writing this list down first prevents the most common hardening accident: enabling a default-deny firewall and forgetting the port you are connected through.

What is Linux server hardening?

Linux server hardening is the practice of reducing a server's attack surface by removing unnecessary services, restricting who can authenticate, and limiting which network traffic reaches each process. It is not a single tool or a one-time event; it is a set of configuration decisions that together shrink the number of ways an attacker can reach your data. Hardening complements patching rather than replacing it, because a fully patched server with password SSH logins open to the internet is still routinely compromised.

Hardening decisions fall into four groups: access (who can log in and how), network (which ports are reachable), service configuration (what each daemon exposes), and recovery (how you restore service after a failure). Treat them in that order. Access control is first because an attacker who cannot authenticate cannot exploit a vulnerable local service, and recovery is last because backups only matter once the other layers are in place.

How do I secure a VPS step by step?

The following twelve steps assume a Debian- or Ubuntu-based VPS and a non-root user with sudo rights. Commands are shown for that family; on RHEL-derived systems, replace apt with dnf and adjust package names. Run the steps in order and do not skip verification, because each step assumes the previous one succeeded.

1. Update the system. Apply all available patches first so later steps run against current packages.

sudo apt update && sudo apt upgrade -y

2. Create a non-root sudo user. Working as root removes the audit trail and makes a single stolen credential catastrophic. Create a named account and grant sudo.

sudo adduser deploy
sudo usermod -aG sudo deploy

3. Generate an SSH key pair on your workstation. Key authentication replaces a reusable secret with a cryptographic challenge. Use Ed25519 unless you must interoperate with legacy systems.

ssh-keygen -t ed25519 -C "deploy@workstation"

4. Install the public key on the server. This is what makes key login possible for the new account.

ssh-copy-id deploy@your-server-ip

5. Test key login before disabling passwords. Open a second terminal and log in as the new user. If this fails, fix it now rather than after step 6.

ssh deploy@your-server-ip

6. Disable password authentication and direct root login. This removes brute-forceable credentials from the SSH service entirely. Edit /etc/ssh/sshd_config, then reload.

sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo systemctl reload ssh

7. Enable a default-deny firewall. A default-deny policy blocks everything you did not explicitly allow, which is the opposite of how most fresh servers ship. UFW is a front end for nftables or iptables; choose UFW when you want readable rules and fast recovery, and choose raw iptables or nftables when you need packet-level control or integration with an existing rule set.

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

8. Install fail2ban. fail2ban watches log files and temporarily bans source addresses that repeatedly fail authentication, which reduces the noise and cost of automated attacks. It is not a substitute for key-only SSH; it is a second layer.

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban

9. Enable automatic security updates. Unattended upgrades close known vulnerabilities between your manual maintenance windows. Enable security-only updates so you are not surprised by feature changes.

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

10. Configure TLS for your web service. TLS encrypts traffic between clients and your server and is required for modern browsers and APIs. With nginx and Let's Encrypt, the certificate and renewal timer are configured in one step.

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

11. Set up off-server backups. Backups stored only on the server they protect are lost with that server. Push encrypted backups to a separate location and test a restore, not just a backup.

sudo apt install restic -y
restic -r sftp:backup-host:/srv/backups init

12. Record what you changed. A short changelog of ports opened, users created and services installed turns the next audit into a review instead of an investigation. Store it outside the server if possible.

How do I verify the VPS security checklist worked?

Verification means proving each control is active, not assuming it from a configuration file. Run the checks below from a separate machine so you test the real network path rather than localhost. If a check fails, fix that step before moving on, because a partially applied checklist is harder to reason about than a fresh server.

# SSH should reject password auth
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no deploy@your-server-ip

# Firewall status and rules
sudo ufw status verbose

# fail2ban jails and banned IPs
sudo fail2ban-client status sshd

# TLS expiry and chain
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

# Pending security updates
sudo apt list --upgradable

Interpret the results concretely. The SSH test should fail with "Permission denied (publickey)", which confirms password authentication is off. ufw status verbose should show Default: deny (incoming) and only the ports you intended. fail2ban-client status sshd should list a jail with a non-zero total failed count over time, which proves the filter is matching log lines. The certificate output should show a notAfter date in the future, and apt list --upgradable should return nothing for security packages once unattended upgrades have run.

What are common VPS hardening mistakes?

The most common mistake is enabling the firewall before confirming SSH access, which locks the administrator out and forces a console or rescue-mode recovery. The second is disabling password authentication before testing key login in a second session; a typo in the authorized key file then becomes a full lockout. Both are avoidable by keeping one authenticated session open while you change access rules in another.

A third mistake is treating fail2ban as a substitute for key-only authentication. fail2ban reacts to failed attempts after they happen, while key-only SSH prevents password guessing from succeeding at all; use both. A fourth is backing up to the same disk or the same provider account, which fails exactly when you need it most. Finally, many administrators open a wide port range "temporarily" for testing and never close it; record every rule you add and review the list monthly.

How do I handle DDoS mitigation and backups on a VPS?

Linux DDoS mitigation on a single VPS is mostly about rate limiting and absorbing traffic you can legitimately serve, because a small virtual server cannot outrun a large volumetric attack. Configure connection limits at the web server or firewall level, and keep a provider-side path for filtering large attacks. For example, nginx can limit concurrent connections per address, and UFW can rate-limit SSH attempts.

sudo ufw limit 22/tcp comment 'rate-limit ssh'

Backups follow the same logic: assume the server will be unavailable and design for restore, not for backup. Keep at least one copy off the server, encrypt it, and verify restoration on a schedule. If your workload is Windows-based, the same principle applies with different tooling, and Windows server backup best practices emphasize image-level backups plus tested bare-metal recovery rather than file copies alone. On the access side, SSH key requirements are simple and worth stating explicitly: use Ed25519 or RSA of at least 3072 bits, protect the private key with a passphrase, and never reuse a key across unrelated servers.

FAQ

What is Linux server hardening?

Linux server hardening is the process of reducing a server's attack surface by restricting authentication, closing unused network ports, and removing unnecessary services. It includes access control, firewall rules, service configuration and patching. Hardening is continuous rather than one-time, because new services and updates change the surface over time.

UFW vs iptables: which should I use on a VPS?

UFW is a simplified front end for nftables or iptables and is the faster choice for a single server with straightforward rules. Use raw iptables or nftables when you need packet-level control, custom chains, or integration with existing infrastructure. Both produce equivalent filtering; the difference is manageability, not security strength.

How do I allow a specific port through UFW?

Run sudo ufw allow 8080/tcp to open a single TCP port, or sudo ufw allow from 203.0.113.10 to any port 5432 to restrict a database port to one source address. Always confirm with sudo ufw status numbered afterward, and prefer source-restricted rules over open ports whenever the client address is known.

How do I install an SSL certificate on IIS?

Import the certificate into the Windows certificate store, then bind it to the site in IIS Manager under Bindings, selecting HTTPS and the certificate. For public sites, a certificate from a trusted authority is required for browsers to accept the connection. After binding, verify the chain and expiry from an external client.

Do I need a passphrase on my SSH key?

A passphrase protects the private key if the file is copied or a laptop is lost, so it is recommended for interactive administrator keys. Use an SSH agent to avoid retyping it, and consider passphrase-free keys only for automated deployment keys stored with strict file permissions on a hardened host.

Conclusion

A VPS security checklist is only useful if it is executed in order and verified at each step. Start with access control, then the firewall, then fail2ban and patching, and finish with TLS and off-server backups. Keep one authenticated session open while you change SSH or firewall rules, and record every port and user you add so the next audit is a review rather than an investigation.

Your next step is to apply the same checklist to the server you already run, then provision a clean instance to confirm the process end to end. If you need a platform where full root access, NVMe storage and a 99.98% uptime commitment are part of the base configuration, review the virtual server options and run the twelve steps above on a fresh instance today.