Setting up a firewall on elementary OS with UFW

Australia's broadband landscape is a mixed bag. Households in Sydney and Melbourne typically have NBN fibre or HFC connections humming along at decent speeds, while folks out in the bush often rely on fixed wireless or satellite services that can be patchy at the best of times. Either way, every machine sitting behind a router is exposed to the wider internet in some form, and a Linux box running elementary OS is no exception. A simple, well-configured firewall is the easiest way to keep stray packets from wandering where they shouldn't, and UFW (Uncomplicated Firewall) is the tool most folks reach for first.

UFW lives in the terminal but doesn't demand a networking degree to operate. It wraps the more verbose netfilter rules in a friendlier interface, so you can open or close ports without typing arcane syntax. If you're new to the Pantheon desktop environment and want to understand what makes this distribution tick before diving into system hardening, the overview of elementary OS is a fair starting point. From there, locking down network access is a logical next step.

Understanding UFW and why it matters down under

UFW sits on top of iptables and quietly filters incoming and outgoing traffic based on rules you define. By default it denies anything that isn't explicitly allowed, which mirrors the same conservative posture that the Australian Cyber Security Centre recommends for home networks. That default-deny stance is reassuring for users concerned about the steady trickle of automated probes that sweep through Telstra and TPG IP ranges every day, looking for open SSH or SMB ports.

The firewall matters more than many realise because Linux desktops aren't invisible online. Bots don't care which desktop environment you're running when they scan port 22 or 3389. Even if you're running something as polished as Pantheon, those background scans will happily knock on your machine's door. UFW gives you a sturdy screen door you can actually latch.

There's another reason local users take this seriously: Australia's privacy legislation and the notifiable data breaches scheme mean that sloppy home network hygiene can have real consequences if a device gets compromised and leaks personal information. ACMA and the ACCC publish regular reminders through Scamwatch about securing home networks, and a working firewall is one of the cheapest lines of defence available. It costs nothing, runs in the background, and asks for very little attention once configured properly.

Installing and enabling UFW on elementary OS

Good news for anyone running a recent release: UFW is almost always already installed on elementary OS. It ships in the default repositories and most ISO images include the package, so a quick verification in the terminal is usually enough. Open the default terminal application and type sudo ufw status to see whether it's present. If you get a "command not found" message, install it with sudo apt install ufw and you're set.

Before enabling anything, it's worth making sure your existing connections won't be disrupted. If you're connected over SSH from another machine — perhaps tinkering with a headless box in the shed out the back — adding the SSH rule before enabling UFW will save you from locking yourself out. This is the kind of hard yakka nobody enjoys doing twice. Run sudo ufw allow OpenSSH first, then enable the firewall with sudo ufw enable. The system will confirm and warn you that the rules are now active.

elementary OS uses systemd, so you can also confirm the service is set to start at boot. sudo systemctl enable ufw makes sure the firewall survives reboots, power trips during a summer blackout in regional SA, or that inevitable firmware update on your router that knocks everything offline for a minute. This small habit turns a one-time setup into a permanent layer of protection.

Crafting your first set of rules

Rules in UFW follow a simple pattern: allow or deny, optional protocol, then the port or service name. Starting with the basics is sensible. sudo ufw default deny incoming and sudo ufw default allow outgoing mirrors the default policy that ships with most consumer routers from the big Aussie ISPs. Outbound traffic stays open so your browser, email client, and package manager all keep working, while incoming traffic is locked down unless you specifically poke a hole.

Common services get friendly shortcuts. sudo ufw allow http opens port 80 for web servers, sudo ufw allow https does the same for 443, and sudo ufw allow 25 is for SMTP mail. If you're running Nextcloud on a home server so the family in Brisbane can sync their calendars, you'll want to open 80 and 443 to the wider internet or just to specific IPs. Be specific about who needs access, though — a blanket allow on an SMB share is the kind of mistake that gets whispered about on Whirlpool forums for years.

For anything trickier, numbered rules help. sudo ufw status numbered lists each rule with an index, and sudo ufw delete <number> removes one in place. This is particularly handy when you're experimenting with rules for a game server, a Jellyfin instance, or a self-hosted git repository. Subnet restrictions are also worth using — sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp limits SSH to your local network only, which is a sensible default for a desktop machine that doesn't need remote shell access from the outside world.

Managing application profiles and defaults

UFW keeps a list of application profiles in /etc/ufw/applications.d/, and several common packages ship with profiles ready to go. You can see what's available with sudo ufw app list. If you've installed something like Transmission, Nginx, or Samba, there's usually a profile waiting. sudo ufw allow "Nginx Full" opens both HTTP and HTTPS in one go, while sudo ufw allow "Samba" covers the Windows networking ports for sharing across devices in the house. This shorthand beats memorising port numbers and keeps your rules file readable.

Logging is another switch worth flipping on. sudo ufw logging on starts writing dropped packets to the system log under /var/log/ufw.log. The default log level is low, so it won't fill your disk, but it records enough to spot unusual activity. If you're running a server exposed to the internet, bumping the level to medium with sudo ufw logging medium gives a clearer picture of what's being blocked. Logs grow though, so a periodic cleanup keeps things tidy.

Resetting everything back to a clean slate is occasionally necessary, especially after a rule explosion. sudo ufw reset disables the firewall and clears every rule, returning UFW to its factory state. It's the digital equivalent of pulling out the NBN box for thirty seconds and plugging it back in, which is the standard troubleshooting move most Aussies reach for anyway. After a reset, you can rebuild your rules carefully, knowing exactly what's allowed and what isn't.

Troubleshooting common UFW headaches

The most common panic moment is being locked out after enabling the firewall. It happens to nearly every sysadmin at some point, usually late on a Sunday arvo when nobody else is around to help. The fix depends on access: if you have physical access to the machine, just boot into a TTY or recovery mode and run sudo ufw disable to lift the rules. If you're remote and have console access through a hosting provider, the same command works. Prevention beats recovery though, so always allow SSH before flipping the switch.

A second common issue is rules that appear to do nothing. This typically means the service isn't listening on the port you think it is. sudo ss -tlnp shows every open port and the process behind it, which is the quickest way to confirm whether your rule even targets a real service. If you've allowed port 8080 but your application listens inside Docker, UFW's rules won't apply because Docker manipulates iptables in ways that bypass UFW entirely. The fix is to run the application on the host network or use Docker's own firewall integration.

Finally, some users notice UFW doesn't survive reboots even after systemctl enable ufw. The culprit is usually AppArmor or another security tool interfering with the systemd unit. sudo systemctl status ufw reveals whether the service is active, and sudo journalctl -xeu ufw shows recent log entries that might explain a failure. On a freshly installed elementary OS box this rarely happens, but on machines that have been through several upgrades or PPA installs, a quick check saves an afternoon of head-scratching. If all else fails, the community forums on elementarynow remain the best places to dig into specifics.

UFW rewards a small amount of upfront effort with years of quiet protection. The default-deny approach, a handful of explicit allow rules, and enabled logging together create a hardened desktop that shrugs off most opportunistic scans. Whether you're in a townhouse in Perth with gigabit NBN, a fibro cottage in Hobart with fixed wireless, or anywhere in between, the same few commands apply. Keep your rules tidy, document anything unusual, and revisit your setup whenever you install a new service. That habit alone keeps most Australian elementary OS users ahead of the curve.