A fresh VPS arrives with every port reachable from the entire internet. Most of them have nothing listening, but the moment you start a database, a cache, or a dev server bound to 0.0.0.0, it is exposed — and bots scan for exactly that within minutes. A firewall flips the default from "open unless I close it" to "closed unless I open it." On Ubuntu and Debian, ufw (Uncomplicated Firewall) makes that a five-minute job.
The golden rule: allow SSH before you enable
The single most common way people lock themselves out of a VPS is enabling a default-deny firewall without first allowing their own SSH port. Do it in this order, every time.
sudo apt install ufw # usually already present
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH # or: sudo ufw allow 22/tcp
default deny incoming blocks everything arriving from outside. default allow outgoing lets your server reach the internet (package updates, API calls) normally. The SSH rule is what keeps your session alive after you turn the firewall on.
Only now:
sudo ufw enable
sudo ufw status verbose
If you moved SSH to a custom port, allow that port instead of OpenSSH, and confirm it works in a second terminal before closing the one you are in.
Open the services you actually run
Add a rule per public service. A web server:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
# or the named profile if installed:
sudo ufw allow 'Nginx Full'
A game server usually needs a specific UDP and/or TCP port — for example a Minecraft Java server:
sudo ufw allow 25565/tcp
The principle is to map each rule to a service you are deliberately exposing. If you cannot name the service behind a port, you probably should not open it.
Keep databases private
The biggest win is not opening your datastore. Postgres (5432), MySQL (3306), Redis (6379) and friends should listen on 127.0.0.1 or a private network interface, never the public one. If your app runs on the same box as its database, the database needs no firewall rule at all — local traffic never traverses the public interface.
If you must reach a database from another server, scope the rule to that source address rather than the whole world:
sudo ufw allow from 203.0.113.10 to any port 5432 proto tcp
That one line is the difference between "my teammate's server can connect" and "the entire internet can try."
Rate-limit SSH against brute force
ufw has a built-in throttle that temporarily blocks an address making too many connections in a short window — handy for the constant SSH login attempts every public box receives:
sudo ufw limit OpenSSH
It is not a replacement for key-based auth and tools like fail2ban, but it is a free first layer.
Inspect, edit, and undo
sudo ufw status numbered # list rules with index numbers
sudo ufw delete 3 # remove rule #3
sudo ufw reload # reapply after edits
Because rules are numbered, you can remove a mistake without flushing everything. Keep the list short — a firewall you understand at a glance is one you will actually maintain.
A sensible default set
For a typical web VPS, the whole policy is four ideas: deny incoming by default, allow and rate-limit SSH, allow 80/443, and keep every datastore bound to localhost. That is enough to take a box from "exposed by default" to "exposes only what you chose," which is the entire point.
Closing note
A firewall is layer one, not the whole story — combine it with SSH keys, prompt updates, and least-privilege services. If you would rather start from a platform that already takes isolation seriously, overnight.host runs full-root KVM VPS in multiple regions (EU and US), where each tenant is genuinely isolated and the specs are honest — you still own your firewall, we just give you a clean, well-fenced box to run it on.
Top comments (0)