Setting Up a Firewall on Ubuntu with UFW: A Practical Walkthrough

UFW, short for Uncomplicated Firewall, is the default iptables front-end shipped with Ubuntu for more than a decade. It exists because raw iptables syntax frightens newcomers, while UFW reads almost like plain English: allow this, deny that, default to dropping. For Australians running Ubuntu at home in Brisbane or Adelaide, or administering a small studio in Perth, UFW is the simplest way to put a sensible barrier between your machine and the open internet. The Australian Cyber Security Centre regularly reminds households and small operators that exposed services are among the most common entry points for opportunistic scanning, so the few minutes spent hardening a single Linux box pay back quickly.

This walkthrough assumes a fresh install of Ubuntu 22.04 LTS or 24.04 LTS on a desktop, laptop, or small server. The same commands work on Ubuntu flavours such as Lubuntu, Xubuntu, and Ubuntu Server, as well as community derivatives like Linux Mint. Throughout, the goal is to leave you with a working default-deny policy, a handful of deliberate allow rules, and the confidence to read what UFW is doing under the bonnet.

What UFW Is and Why It Matters

At its heart, UFW is a wrapper around the Linux kernel's netfilter framework. Every packet that touches your network interface flows through chains of rules, and UFW gives you a clean way to manage those chains without remembering the difference between INPUT, OUTPUT, and FORWARD, or worrying about table precedence. Behind the scenes it still calls iptables-restore, but you don't have to. That separation matters because most home and small-business users in Australia — whether on a Telstra-supplied modem in Hobart, an Aussie Broadband connection in Geelong, or a Starlink dish near Cairns — need protection that they can actually configure correctly on the first try.

The default policy matters most. When UFW is enabled with no extra rules, it blocks all incoming traffic that hasn't been explicitly allowed. Outbound traffic still flows freely, which is what you want for browsing, email, package updates, and video calls. This posture aligns with the ACSC's Essential Eight mitigation strategies, particularly the "deny by default" cousin that applies to Linux networking: deny first, then carve out the narrow openings your workflow requires. A media server needs different ports than a workstation, and UFW makes that distinction easy to express.

Installing and Verifying UFW

On a stock Ubuntu desktop, UFW is usually already installed but disabled. The package name is ufw, and you can confirm its presence with a quick check. Open a terminal and run dpkg -l | grep ufw. If nothing appears, install it with sudo apt update && sudo apt install ufw. The binary lives at /usr/sbin/ufw and the systemd unit is ufw.service, so it will start automatically on boot once enabled. You can verify the service status with sudo systemctl status ufw, which should report active (exited) — a quirk of UFW's design that confuses newcomers but is harmless.

Before you flip the switch, check the status with sudo ufw status verbose. On a fresh system you will see something like Status: inactive. This is the moment to decide whether any other firewall manager is active, such as firewalld on a converted CentOS box or nftables rules loaded manually. Running two packet filters at once produces confusing behaviour and can lock you out. If you have inherited a server from someone else, scan sudo iptables -S and sudo nft list ruleset to make sure nothing else is competing. Once you are satisfied that UFW is the only game in town, enable it with sudo ufw enable. The command will warn that it may disrupt existing SSH connections, which is exactly the topic of the next section.

Crafting Your First Rules

Rules are added with ufw allow and ufw deny, optionally followed by a port, protocol, and comment. A useful first habit is to allow SSH before enabling the firewall, otherwise you will lock yourself out of any remote machine. The command sudo ufw allow 22/tcp opens the standard SSH port using TCP. If you have changed your sshd_config to listen on a non-standard port — common practice among Australian sysadmins tired of port-scanning noise from overseas botnets — substitute that number. You can also restrict by source address, which is genuinely handy if you only ever administer a box from your office in Canberra: sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp.

After SSH, think about what the machine actually serves. A workstation behind a home router usually needs nothing else, because NAT already hides it from the wider internet. A laptop on the road through regional NSW or the NT might occasionally run a local development server, in which case sudo ufw allow 8080/tcp comment "local dev" is the kind of rule you can safely add and remove. For a home media box running Jellyfin or Plex, opening the appropriate TCP range and the UDP discovery port keeps smart TVs and phones happy without exposing the rest of the filesystem. Each rule should arrive with a short comment so you can read your own work six months later.

Once a handful of rules exist, sudo ufw status numbered shows them with indices. The numbered view makes deletions painless: sudo ufw delete 3 removes rule three. If you ever want to start over, sudo ufw reset clears everything and returns UFW to its factory defaults, though the policy stays whatever you last set it to. The combination of numbered status, allow and deny symmetry, and reset gives you a safety net that raw iptables lacks.

Application Profiles and Service Shortcuts

UFW ships with a directory of application profiles under /etc/ufw/applications.d. Each profile is a small INI-style file that bundles ports, protocols, and a human description, so sudo ufw app list reveals what is already known. Profiles exist for OpenSSH, Apache, Nginx, Samba, CUPS, and many more. Where a profile exists, you can allow a service by name: sudo ufw allow "Nginx Full" opens 80 and 443 together, while sudo ufw allow "Nginx HTTPS" opens only 443. The string in quotes is the profile title, which app info will print in full.

The real power comes from writing your own profiles. If you self-host a Bitwarden vault, a Nextcloud instance, or a small Matrix homeserver for friends across Melbourne and Perth, a profile lets you describe the service once and reuse the rule. A profile file looks like this:

[Nextcloud]
title=Nextcloud
description=Self-hosted file sync
ports=80,443/tcp

Drop that into /etc/ufw/applications.d/nextcloud, run sudo ufw app update Nextcloud, and the service becomes available alongside the bundled ones. This pattern also makes rules portable: copy the profile between machines and your firewall policy travels with it. For small Australian studios where the same setup lands on two or three laptops, that portability is gold.

Logging, Monitoring, and Troubleshooting

UFW logs to syslog by default at a low level, which is fine until you actually need to investigate something. Raise the verbosity with sudo ufw logging medium or sudo ufw logging high. Medium is usually enough for a home user, while high is reserved for active incident response. Logs land in /var/log/ufw.log and are rotated by the logrotate package that Ubuntu installs by default. If you prefer journald, journalctl -k -g UFW filters the kernel ring buffer for the same events.

When something is not behaving, a small checklist helps. Confirm UFW is active with status verbose. Confirm the rule you think is in place is actually there with status numbered. Confirm the service is listening on the address and port you expect with sudo ss -tlnp. A frequent trap is a service bound to 127.0.0.1 only, in which case UFW cannot help you because the kernel refuses the packet long before netfilter sees it. Another trap is Docker: containers on custom networks can dodge UFW unless you configure the DOCKER-USER iptables chain, a topic worth a separate walkthrough on more tutorials on UbuntuNext.

For Australian operators mindful of the Notifiable Data Breaches scheme under the Privacy Act 1988, logging matters beyond curiosity. If a firewall breach happens on a machine processing personal information, having a record of connection attempts, sources, and timestamps is the difference between a clean report and an ambiguous one. The ACSC publishes guidance on log retention that is a sensible default even for home users: keep at least 90 days of UFW logs locally, longer if your threat model warrants it.

What you should carry away is simple. UFW's default-deny posture is the safest starting point for any Ubuntu installation. Allow only the services you genuinely expose, restrict them by source address where practical, and tag every rule with a comment so the next person — often you, three months from now — can read the policy. Keep logs at medium verbosity, review them occasionally, and remember that a firewall is one layer of a healthy setup, not a replacement for updated software, strong authentication, and sensible backups. With those habits, an Ubuntu box in Sydney, a small studio in Fremantle, and a remote workstation in Darwin can all share the same confident baseline.