VPS Firewall Basics: Set Up UFW and Close Open Ports

Run ss -tulpn on a fresh VPS and you'll usually find more open ports than you expected — a database listening on 0.0.0.0, a stray dev server, maybe Redis wide open to the internet. If you haven't set up a firewall yet, every one of those is reachable by anyone who scans your IP, and on the public internet, someone always is.

Symptom: your server is getting probed constantly

Check /var/log/auth.log or /var/log/secure on a brand-new VPS and you'll see SSH login attempts within hours of it going live — sometimes minutes. Run netstat -tulpn or ss -tulpn and you might find MySQL on port 3306, Redis on 6379, or a Node app on 3000, all bound to 0.0.0.0 instead of 127.0.0.1. None of that is malicious by itself, but it's an open door you didn't mean to leave unlocked.

The giveaway that you have no firewall active: sudo ufw status returns Status: inactive, or iptables -L shows an empty ACCEPT-everything policy.

Cause: most VPS images ship with no firewall enabled

Getwebup VPS images — like most providers' base Ubuntu/Debian/AlmaLinux images — don't enable a firewall by default. That's intentional; the provider doesn't know which ports your app needs. It's on you to lock it down after first boot. Skip that step and every service you install (database, cache, admin panel, monitoring agent) is exposed the moment it starts listening, whether or not you meant to expose it publicly.

UFW (Uncomplicated Firewall) is the friendliest front end for iptables/nftables on Ubuntu and Debian. It's not installed by default on every image, but it's in the standard repos, and it turns a page of iptables rules into a handful of readable commands.

Fix: install UFW and set a default-deny policy

Connect over SSH and work through this in order — the order matters, because getting it wrong can lock you out of your own server.

1. Install UFW (if it's not already there)

sudo apt update
sudo apt install ufw

On AlmaLinux/CentOS-based images, UFW isn't available; use firewalld instead (sudo dnf install firewalld) with the equivalent firewall-cmd commands. The rest of this guide assumes Ubuntu/Debian with UFW.

2. Allow SSH before you enable anything

This is the step people skip and then regret. If you enable UFW with a default-deny policy and haven't explicitly allowed SSH, you'll cut your own session and lock yourself out.

sudo ufw allow OpenSSH

If you've moved SSH off port 22 (a good idea — see our SSH hardening guide), allow your actual port instead:

sudo ufw allow 2222/tcp

3. Set default policies

sudo ufw default deny incoming
sudo ufw default allow outgoing

This is the core of the whole exercise: nothing gets in unless you explicitly allow it, and your server can still reach out for updates, API calls, and package installs without restriction.

4. Allow only the ports your app actually needs

For a typical web server:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

For a mail server, database, or anything else, add only what's genuinely required — and scope it where you can. If only your office IP needs phpMyAdmin or a database port, restrict the rule to that source instead of opening it to the world:

sudo ufw allow from 203.0.113.10 to any port 3306

For services that should never be public — MySQL, Redis, MongoDB, admin dashboards — the better fix is usually to bind them to 127.0.0.1 in their own config and skip the firewall rule entirely, since nothing external can reach localhost anyway.

5. Enable UFW

sudo ufw enable

You'll get a warning that this may disrupt existing SSH connections. If you completed step 2, you're fine — confirm with y.

6. Verify

sudo ufw status verbose

You should see your allowed ports listed, default incoming denied, and default outgoing allowed. Open a second terminal and test a fresh SSH connection before you close your current session — that way, if something's wrong, you still have a way in to fix it.

Common mistakes that cause a lockout

If you do get locked out

Don't panic — UFW rules live on the server, not in the network layer, so your hosting provider's VNC/console access still works even with SSH blocked. Log in through the Getwebup VPS console, run sudo ufw allow OpenSSH (or your custom port), reload with sudo ufw reload, and SSH will open back up.

Prevention: treat firewall rules as part of your deploy checklist

• Enable UFW as one of the first things you do on a new VPS, right after creating a non-root sudo user.
• Every time you install a new service, ask whether it needs to be reachable from the public internet at all — most databases and internal tools don't.
• Run sudo ufw status numbered periodically and delete rules for ports you no longer use: sudo ufw delete <number>.
• Pair UFW with Fail2Ban for SSH — the firewall controls which ports are open, Fail2Ban handles repeated failed attempts on the ports you did open.
• If you run Docker on the same box, know that Docker manipulates iptables directly and can bypass UFW rules for published container ports — that's a separate configuration step, not something UFW handles automatically.

Fifteen minutes of firewall setup on day one saves you from finding an unfamiliar process bound to an open port six months later. It's one of the few security steps that's genuinely quick and genuinely effective.