UFW Firewall on Ubuntu and Debian: A Safe Setup Checklist

UFW is useful because it makes a host firewall readable, but readability is not the same as safety. On Ubuntu and Debian servers, the dangerous part is usually not the syntax. It is enabling a default-deny policy before SSH, monitoring, application ports, and IPv6 behavior have been checked as one release change.

A DigitalOcean tutorial updated on June 22, 2026 lays out the current UFW workflow for Ubuntu and Debian: install or confirm UFW, handle IPv6, set defaults, allow required services, deny what should stay closed, enable the firewall, and verify the result. That sequence lines up with the Ubuntu UFW documentation, the Ubuntu 24.04 LTS ufw(8) man page, and the Debian UFW wiki. The checklist below turns those commands into a production-safe rollout pattern for cloud hosts.

Use UFW as a host firewall, not a whole security program

Ubuntu’s community documentation describes UFW as the default firewall configuration tool for Ubuntu and a user-friendly way to create an IPv4 or IPv6 host-based firewall. Debian’s wiki describes UFW as a frontend for iptables and a command-line interface for managing netfilter. In practice, that means UFW controls traffic that reaches the machine. It does not replace security groups, load balancer rules, VPN policy, application authentication, patching, logging, or incident response.

What UFW is good at

UFW is strongest when the host has a small, intentional set of exposed services: SSH for administration, HTTP and HTTPS for a web server, a private monitoring agent, or a database port limited to a known address. The ufw(8) man page lists the core verbs operators need for this work: default, allow, deny, reject, limit, status, show, reload, reset, and numbered rule deletion.

What UFW does not solve

A firewall rule can block unwanted network paths, but it cannot tell whether an allowed web request is malicious or whether a valid SSH key has been stolen. Treat UFW as the host-level allowlist that supports the rest of the stack. Keep cloud firewall rules, reverse-proxy controls, application logs, and account security in the same change plan.

Target system and assumptions

The commands in this guide target Ubuntu Server 24.04 LTS-style systems and current Debian systems using the ufw package. Run them as a sudo-capable user. If you are working over SSH, keep a provider console, recovery shell, serial console, or out-of-band access path open before changing rules.

Version context

The Ubuntu 24.04 LTS man page used for this checklist identifies ufw version 0.36.2-6 and shows --dry-run support for several commands. Debian’s wiki was last modified in April 2026 and specifically warns that installing UFW does not automatically turn it on or create a rule set. Those two details are important: you can stage the policy first, and you should not assume that a package install changed the machine’s exposure.

Pre-flight information to collect

• The management path: SSH port, source IP ranges, jump host, VPN, and emergency console.
• The services that should be reachable from the internet, such as 80/tcp and 443/tcp.
• Private ports that should be limited to a subnet or exact source address.
• Whether the server has IPv6 addresses and public AAAA records.
• The rollback window and who can regain access if the firewall blocks SSH.

The safe baseline sequence

Do not start by enabling the firewall. Build the policy in a way that protects the active management session. Debian’s wiki gives the core warning plainly: if you configure over SSH, allow SSH before enabling the firewall or you may lock yourself out.

1. Install or confirm UFW

If UFW is not already installed, install the package before adding rules. Debian’s wiki shows the explicit apt install ufw step, and the same command is safe to use on Ubuntu when you need to confirm the package is present.

sudo apt update
sudo apt install ufw
sudo ufw status verbose

The first status check is not a pass or fail. It tells you whether UFW is inactive, already active, or carrying rules from a previous administrator. If rules already exist, export the state to the change ticket before editing.

2. Set default policy before opening services

The common baseline is to deny unsolicited inbound traffic and allow outbound traffic. Ubuntu’s documentation shows the resulting status as Default: deny (incoming), allow (outgoing), while Debian’s wiki recommends the same defaults for normal users.

sudo ufw default deny incoming
sudo ufw default allow outgoing

For most single-purpose cloud servers, this is the right starting point. Routing hosts, Kubernetes nodes, VPN gateways, and appliances are exceptions; those should be handled from their platform documentation instead of copied from a generic host checklist.

3. Allow management access first

Use the OpenSSH application profile if it matches your service, or name the exact port and protocol. If SSH is restricted to a corporate egress address or bastion host, express that in the rule rather than opening management to the world.

sudo ufw allow OpenSSH comment 'SSH management profile'
# Or, for a non-profile rule:
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'SSH from bastion'

Replace 203.0.113.10 with the real administration source. Do not copy the documentation address into production. If your SSH daemon listens on a non-standard port, use that port instead of 22/tcp.

4. Open only the application ports you intend to serve

For a normal web server, that usually means HTTP and HTTPS. For a private database or metrics endpoint, add a source constraint.

sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'
sudo ufw allow from 10.20.0.0/16 to any port 9100 proto tcp comment 'node exporter from monitoring subnet'

Prefer explicit ports and comments for production changes. Application profiles are convenient, but the change reviewer should still be able to see exactly what traffic is expected.

Rule examples to review before enabling

Handle IPv6 deliberately

IPv6 is a frequent source of false confidence. A host can look locked down over IPv4 while still exposing services over IPv6. DigitalOcean’s UFW guide notes that modern Ubuntu and Debian systems use IPV6=yes in /etc/default/ufw by default so UFW manages both IPv4 and IPv6 rules. Confirm that setting if the server has IPv6 connectivity.

Check IPv6 before the firewall goes active

grep '^IPV6=' /etc/default/ufw
ip -6 addr show scope global
sudo ufw status verbose

If you change /etc/default/ufw, follow the product guidance for reloading or disabling and re-enabling UFW so the change takes effect. Then test from an IPv6-capable client, not only from an IPv4 network.

Decide whether IPv6 should be served or removed

If the application is meant to support IPv6, make it part of the release test: HTTP, HTTPS, monitoring, and denial paths should all be checked over IPv6. If the host should not serve IPv6, remove the public address or upstream AAAA record instead of relying on a forgotten local exception.

Enable, verify, and keep the rollback small

The ufw(8) man page shows --dry-run as a supported option, and it also documents status verbose and status numbered. Use those checks to keep the activation boring.

Stage and enable

sudo ufw --dry-run enable
sudo ufw enable
sudo ufw status verbose
sudo ufw status numbered

The output should show the firewall as active, inbound denied by default, outbound allowed by default, and your intended rules. Keep the existing SSH session open while a second terminal confirms that a new SSH connection still works.

Test from outside the host

Local status output is necessary, but it is not enough. Check from a client that traverses the same path as users. For a web server, verify HTTPS. For private monitoring, test from the monitoring subnet and from a disallowed source. For SSH, test the allowed path and confirm that other sources are blocked.

Know the reset command, but do not make it your plan

DigitalOcean’s guide notes that sudo ufw reset backs up and removes user-defined rules, disables the firewall, and resets defaults. That is useful during a failed staging attempt. It is too broad for routine rollback on a production server. A better rollback is a small, numbered rule deletion or a documented revert to the previously exported rule set.

Operational checklist

• Record the target OS, UFW package version, management path, and recovery console.
• Confirm whether the server has global IPv6 addresses.
• Set defaults: deny incoming, allow outgoing.
• Allow SSH before enabling UFW, preferably constrained to known sources.
• Add application rules with comments and source limits where possible.
• Run sudo ufw --dry-run enable, then enable during a maintenance window or low-risk change window.
• Verify with sudo ufw status verbose, sudo ufw status numbered, and external connection tests.
• Keep the first SSH session open until a second login succeeds through the new policy.

The practical takeaway

UFW’s appeal is that it lets Linux administrators describe host firewall policy in commands humans can review. The production discipline is to make that review happen before activation. For Ubuntu and Debian cloud servers, the safe path is simple: identify management access, set conservative defaults, allow only required services, handle IPv6 explicitly, verify from outside the host, and keep rollback narrow.

If that sequence becomes part of every server build and deployment checklist, UFW stops being a one-time hardening command and becomes a repeatable release gate for network exposure.

Sources

• DigitalOcean: Set Up a Firewall with UFW on Ubuntu and Debian
• Ubuntu Community Help Wiki: UFW
• Ubuntu 24.04 LTS man page: ufw(8)
• Debian Wiki: Uncomplicated Firewall (ufw)
• Featured image source: Wikimedia Commons

Featured image: racks with network cabling in the NERSC data center by Derrick Coetzee, dedicated to the public domain under CC0 via Wikimedia Commons; cropped and converted to WebP.