Does UFW replace iptables?

No — UFW is a front end that writes iptables (or nftables, on newer systems) rules for you. It's simpler to manage, but it's generating the same underlying rules; you can still drop to raw iptables for anything UFW's syntax doesn't cover.

Will UFW protect me from DDoS attacks?

Not on its own. UFW controls which ports and IPs can connect, but a volumetric DDoS attack against an open port (like 443) can still overwhelm your server. That's usually handled upstream by your host's network-level DDoS protection, not the server's own firewall.

Do I need UFW if Getwebup already provides a network firewall?

Yes, worth running both. A network-level firewall protects the edge, but UFW protects the server itself — including from misconfigured services that bind to all interfaces. Defense in depth means neither one alone is enough.

How do I check which ports are actually in use before writing rules?

Run sudo ss -tulpn to list every listening port along with the process using it. Cross-check that list against what you actually need publicly reachable before deciding what to allow.

Can I use UFW alongside Docker?

You can, but Docker inserts its own iptables rules for published ports and can bypass UFW's deny policy by default. You'll need to configure Docker's iptables integration or use a UFW-Docker compatibility script to keep the two in sync.

UFW Firewall Setup for VPS: 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. ufw allow: open only the ports your app 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

Mistake	What happens	Fix
Enabling UFW before allowing SSH	You're locked out immediately	Use your provider's web console/VNC to log in and run `ufw allow OpenSSH`, then `ufw enable`
Forgetting a custom SSH port	Same lockout, if you'd already changed the port	Allow the actual port, not the default 22
Blocking outgoing traffic too	Package installs, cron jobs, and API calls silently fail	Leave `default allow outgoing` unless you have a specific reason to restrict it
Opening ports "just in case"	Wider attack surface than you need	Only allow what a running service actually requires, and remove rules you no longer use

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.

VPS Firewall Basics: Set Up UFW and Close Open Ports