Securing your VPS: firewall, SSH and automatic updates

A VPS is yours to administer: myPandos runs the hardware, the network and the backups, but the operating system and everything on it is your responsibility. A server on a public IP is scanned within minutes of coming online, so this is worth an hour on day one.

These steps come from hardening a real customer VPS. Before the work, its authentication log held 1,721 failed SSH attempts, the busiest single source having tried 154 times.

1. Use SSH keys, not a password

This is the single highest-value change. A password can be guessed at thousands of attempts an hour; a key cannot. See How to create an SSH key and add it to your dashboard for how to create one and add it to your account.

Once key login works, turn passwords off in /etc/ssh/sshd_config:

PermitRootLogin no
PasswordAuthentication no

sudo systemctl reload ssh

Keep your existing session open while you test a new one from a second terminal. If the new session fails you still have the old one to undo the change; close it first and you are locked out.

2. Turn the firewall on

Ubuntu ships ufw installed and inactive. An inactive firewall is not a permissive firewall with good defaults — it is no firewall, and every port anything opens is reachable from the internet.

Allow before you deny. Enabling with a default-deny policy and no allow rule for SSH will disconnect you from your own server:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp     # SSH — do this FIRST
sudo ufw allow 80/tcp     # only if you serve a website
sudo ufw allow 443/tcp
sudo ufw enable

If you are working over SSH and cannot reach a console, arm a safety net first so a mistake fixes itself:

sudo nohup bash -c 'sleep 300; ufw --force disable' &

That disables the firewall in five minutes. Confirm you can still open a new SSH session, then cancel it with sudo pkill -f 'sleep 300'. If you did lock yourself out, wait five minutes and you are back in.

Check what is actually listening before you decide which ports to open:

sudo ss -tlnp

Anything bound to 127.0.0.1 is already local-only and needs no rule. Databases belong in that group — a MySQL or PostgreSQL port open to the internet is a breach waiting to happen.

3. Enable fail2ban

Ubuntu often has fail2ban installed but not enabled, which looks identical to having it until you check. It watches the auth log and bans addresses that keep failing:

sudo apt install -y fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

The defaults are weak against a patient attacker: five failures in a ten-minute window, banned for ten minutes. Anyone spacing their attempts never trips it, and anyone who does is back before you finish reading the alert. Create /etc/fail2ban/jail.d/custom.conf:

[sshd]
enabled  = true
maxretry = 5
findtime = 3600
bantime  = 3600

sudo systemctl reload fail2ban

An hour-long window catches a paced attacker; an hour-long ban is short enough that a colleague with a stale key is not locked out for the day. Verify it can actually ban, rather than assuming:

sudo fail2ban-client set sshd banip 203.0.113.99
sudo iptables -S | grep f2b
sudo fail2ban-client set sshd unbanip 203.0.113.99

4. Keep security updates applying themselves

sudo apt install -y unattended-upgrades
sudo systemctl status unattended-upgrades

Most breaches use a vulnerability that was patched months earlier. This is the cheapest protection on the list.

5. Check your work

sudo ufw status verbose        # Status: active, not inactive
sudo systemctl is-enabled fail2ban   # enabled, so it survives a reboot
sudo fail2ban-client status sshd     # jail present, bans counting
sudo ss -tlnp                        # only what you meant to expose

is-enabled matters as much as is-active: a service running now but not enabled disappears at the next reboot, and everything looks fine until it does not.

What myPandos does, and what is yours

• We handle: the physical hardware, the virtualisation platform, the network, power, and snapshot infrastructure.
• You handle: the operating system, everything installed on it, security updates inside the VPS, and firewall rules for your own applications.

Unlike Shared Hosting, nobody administers the operating system for you. If you would rather not, Shared Hosting is managed — see Which myPandos hosting product is right for you?

If you think you have been compromised

Open a ticket from dash.mypandos.io immediately. Do not reboot first: a reboot destroys the running processes and network connections that show what happened. Take a snapshot if you can, then tell us — we can isolate the machine at the network level while you decide what to do.