Threat-model the server

A server is not secured by one hardening script. Start with what this machine runs and what would happen if it failed.

Threat modeling sounds like an enterprise ritual. For a single Ubuntu VPS it is one page of notes. You write down what the server holds, who can reach it, and which paths an attacker could take. Every control you add later should trace back to that page.

Inventory the machine

List public ports, applications, databases, credentials, backups, DNS, cloud-provider access, and people with administrative rights. Concrete beats complete:

host: blog-vps (Ubuntu 24.04 LTS at Hetzner)
public: 22/tcp ssh, 80/tcp + 443/tcp nginx
runs: nginx, node blog app, postgresql (local only)
data: posts, newsletter subscriber emails, TLS private key
admins: flavio (ssh key), provider console (password + MFA)
recovery: provider console, nightly off-site backup

Ten minutes of writing, and you already know which firewall rules make sense, which accounts need review, and which credentials are worth stealing.

Name the attack paths

Separate internet threats from a compromised application or a stolen provider account. Each path meets different controls:

internet -> sshd, nginx          firewall, patched packages, ssh keys
web app bug -> shell as app     service user, file permissions
stolen provider login -> root   console MFA, provider audit log

A public blog VPS and a private database host need different controls. A stolen provider account can also bypass a carefully hardened SSH service.

Rank each path by reachable assets and recovery cost. This keeps the exercise practical: provider MFA may matter more than another SSH tweak when the console can replace the server.

The mistake to avoid

The common failure is modeling only the SSH path. You spend an evening on it while the provider password is reused from an old forum account. You can recognize this by reading your own page: ten SSH mitigations and not one line about the console means the model is lopsided. Fix the cheap, high-value gaps first.

Draw the lab VPS, provider console, DNS, backups, public ports, and administrator paths. Remove one assumed control, such as SSH or provider MFA, and record the remaining exposure and recovery path.