Common VPS Security Mistakes and How to Avoid Them

A fresh VPS can be reachable from the internet before you’ve even finished your first coffee. I’ve seen a forgotten database port turn a routine deployment into an incident; the fix was simple, but the cleanup wasn’t. This guide covers the common mistakes that make VPSs easy targets—and practical steps to avoid them.

1. Leaving more ports open than you need

A firewall rule copied from an old tutorial can expose SSH, a database, and a dashboard when your app only needs web traffic. Start with a short list: allow only the ports your services actually require.

On an Ubuntu server using UFW, first allow SSH before enabling the firewall:

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

If your SSH service listens on a nonstandard port, allow that port instead of OpenSSH. Keep your current SSH session open while testing a second connection; otherwise, a typo can lock you out.

Also check your provider’s cloud firewall or network security rules. Host-level firewall rules and provider-level rules are separate controls. A port may be blocked at either layer.

One easy-to-miss detail: Docker-published ports can bypass UFW’s normal filtering path, depending on how Docker and the host firewall are configured. Don’t assume ufw status tells the whole story. Avoid publishing internal services to every interface:

services:
  app:
    ports:
      - "127.0.0.1:8080:8080"

That binds the port to localhost, so a reverse proxy on the same host can reach it without exposing it directly to the internet.

2. Keeping password-based SSH login enabled forever

Password login is convenient during setup, but it also gives attackers a login prompt to hammer with guesses. Set up key-based access first, verify it works in a second terminal, and only then disable password authentication.

On your local machine, create a key if you don’t already have one:

ssh-keygen -t ed25519 -C "my-vps"
ssh-copy-id user@your-server

After confirming key-based login, configure the server. On current Ubuntu releases, you can add a small drop-in file:

sudoedit /etc/ssh/sshd_config.d/99-hardening.conf

Add:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Validate the configuration before reloading SSH:

sudo sshd -t
sudo systemctl reload ssh

Keep an existing session open and test a fresh login before closing it. SSH configuration and service names vary by distribution; on some systems the service is called sshd rather than ssh.

Disabling root login doesn’t mean losing administrative access. Create a normal user with sudo privileges and use that account for routine work.

3. Treating updates as a one-time setup task

A server that was patched when it launched can still become vulnerable months later. Enable automatic security updates where appropriate, and schedule a regular check for updates that need a reboot.

On Ubuntu, unattended security updates are commonly managed with unattended-upgrades:

sudo apt update
sudo apt install unattended-upgrades
sudo dpkg-reconfigure unattended-upgrades

This is not a substitute for checking the machine. Review pending updates periodically:

sudo apt update
apt list --upgradable

For production services, understand when a reboot is required and how you’ll handle it. Automatic updates reduce the time a known vulnerability remains unpatched; they don’t guarantee that every application or third-party package is covered.

4. Exposing databases and admin panels

A database usually does not need a public IP-facing listener. Bind it to localhost or a private network, then connect through the application or an SSH tunnel. For example, this forwards a local port to a database port on the server:

ssh -L 5432:127.0.0.1:5432 user@your-server

Your local database client can then connect to localhost:5432. Confirm your database’s own access rules too; a firewall is useful, but it shouldn’t be the only thing preventing unintended access.

The same principle applies to monitoring dashboards, queue managers, and development tools: if only you need the interface, put it behind a VPN, an authenticated reverse proxy, or an SSH tunnel instead of exposing it publicly.

5. Assuming a snapshot is a complete backup

A provider snapshot is useful for fast recovery, but it may not be independent of the VPS account, region, or provider. If the account is inaccessible—or an accidental deletion removes both the server and its snapshots—you may have no recovery path.

Keep a separate copy of important data somewhere outside the server. For a small app, that might mean scheduled database dumps uploaded to separate storage, plus a documented way to restore them. Back up configuration and deployment instructions too; a database dump is less useful if nobody knows how to rebuild the application around it.

The non-obvious practice that matters most: test a restore before you need one. Restore a recent backup to a temporary machine or isolated environment, and time the process. A backup you haven’t restored is an assumption, not a recovery plan.

6. Installing tools and services without checking what they expose

A quick install script may open a port, add a repository, or create a service that survives reboots. Before and after installing something, inspect what’s listening:

sudo ss -tulpn

Review which services start automatically:

systemctl list-unit-files --state=enabled

Remove software you no longer use, and check the firewall after adding a service. This is especially important with container stacks: a port mapping in a Compose file can publish a service even when you didn’t add a matching UFW rule.

A practical habit: keep a short record of the ports you expect to be open and why. Comparing that list with ss output takes a minute and often catches accidental exposure.

7. Relying on fail2ban as the whole security plan

Fail2ban can block repeated login attempts, and it may be useful on a server that still accepts SSH from the public internet. But it doesn’t replace SSH keys, updates, or sensible firewall rules. It also won’t help if a vulnerable web application is the entry point.

Start with the basics: expose fewer services, use key-based SSH, patch regularly, and check logs when something looks unusual. If you install fail2ban, verify that its SSH jail matches your system’s log setup and SSH port; defaults differ across distributions and logging configurations.

Choosing a VPS is part of the security setup

Provider features affect how you operate: look for clear firewall controls, usable recovery options, and a documented way to rebuild or access a server if SSH breaks. For general VPS workloads, PowerVPS is one option to compare. If a project needs GPU compute rather than a conventional web server, Vast.ai (GPU rental) is worth considering; GPU instances have different pricing and lifecycle trade-offs, so check the specific offer and storage arrangements before relying on one.

The Server Rental Guide is also a useful resource when comparing server types and rental options. Whichever provider you choose, verify its backup, firewall, and recovery behavior rather than assuming those features work a particular way.

A quick first-hour checklist

After provisioning a VPS:

1. Create a non-root user with sudo access.
2. Install updates and set up key-based SSH.
3. Test a second SSH session before disabling password login.
4. Allow only required ports at both the provider and host firewall layers.
5. Check listening services with ss -tulpn.
6. Set up backups and test a restore.
7. Write down how to regain access if a firewall or SSH change goes wrong.

Conclusion

Most VPS security problems don’t start with an elaborate attack. They start with a port nobody meant to expose, an update that never happened, or a backup that was never tested. Keep the public surface small, make recovery a routine task, and verify what the server is actually doing—not just what you intended it to do.