How to Enable and Configure Firewall Rules with UFW on elementary OS

UFW (Uncomplicated Firewall) gives elementary OS a practical way to control network access without learning every corner of nftables or iptables. It presents a readable set of policies for incoming and outgoing connections, while the Linux kernel continues to do the detailed packet filtering. Used with sensible defaults, it can reduce the exposure of services running on your computer. It does not replace software updates, sensible accounts, or backups. That makes it particularly useful for an always-on Australian home server or a VPS with a public address, where exposed administration panels are scanned quickly.

The examples here use the terminal on elementary OS, whose Ubuntu foundation makes UFW available from the standard repositories. They apply equally to a desktop, a home server, or a small VPS. The main caution is remote administration: changing firewall policy while connected over SSH can lock you out, so every rule should be added before access is removed. Read every output before continuing; a rule that appears harmless may be broader than expected.

Prepare before changing network access

Start by refreshing the package lists and installing UFW if needed: run sudo apt update, followed by sudo apt install ufw. If you are installing the distribution for the first time, the step-by-step installation guide provides a sensible baseline before you change its network exposure. Then check the current state with sudo ufw status verbose and review any saved applications with sudo ufw app list. These packages come from elementary OS’s normal Ubuntu-derived repositories, so no third-party PPA or downloaded executable is required.

A blank result normally means UFW is inactive, which is worth confirming rather than assuming. Existing rules may have been created by an installer, a hosting provider, a container service, or a previous administrator. UFW commonly uses the nftables backend on current Ubuntu-based releases, and manually mixing rules made with another firewall tool can produce confusing results. Active rules are normally stored in /etc/ufw/user.rules and /etc/ufw/user6.rules, which also makes accidental hand editing worth avoiding unless you understand the format.

Before enabling UFW on a remote machine, check whether SSH is in use and whether it listens on a non-standard port. Keep the current SSH session open, add the matching SSH rule, and test a second session. On an Australian VPS in a Sydney or Melbourne region, the provider’s security group or virtual firewall is a separate perimeter layer; it must also permit the port even when UFW allows it. Where SSH is already active, key-based authentication and a restricted source address provide stronger protection than password access from any network.

Enable UFW with safe defaults

A suitable baseline is to deny incoming connections, allow outgoing connections, permit SSH where required, and then enable the firewall. The sequence is sudo ufw default deny incoming, sudo ufw default allow outgoing, sudo ufw allow OpenSSH, and sudo ufw enable. If SSH uses port 2222 instead, use sudo ufw allow 2222/tcp in place of the application profile. These policy commands can be prepared while UFW is inactive, and the saved rules remain in place when the firewall starts.

Once enabled, sudo ufw status verbose should show that it is active with the intended policies. The systemd service also starts UFW at boot, so sudo systemctl enable --now ufw is useful for confirming that behaviour. Recheck access after the change instead of closing the only live session immediately, because a typo in a port, interface, or source address can otherwise end remote access. An active firewall with no useful exceptions may also be a problem, particularly when administering a remote server.

UFW can manage IPv6 as well as IPv4 when IPv6 is enabled in /etc/default/ufw and the network provides it. This matters in Australia because a rule limited to IPv4 would not necessarily cover a machine with a working IPv6 address. Confirm the setting and avoid weakening IPv6 simply to make an IPv4-only rule appear correct. Do not edit the file blindly: first confirm that the host really has IPv6 connectivity and that the interface is managed by NetworkManager or systemd-networkd.

Allow the services you actually use

UFW application profiles are shortcuts for common services. The profiles live under /etc/ufw/applications.d, and sudo ufw app info OpenSSH shows the port and protocol behind one. For a public web server, typical entries are sudo ufw allow 80/tcp and sudo ufw allow 443/tcp; for remote administration, sudo ufw allow OpenSSH is clearer than an unexplained numeric rule. If a profile is missing, a specific port rule is usually safer than importing a definition from an unrelated distribution.

Most desktop applications need no incoming exception because they make outbound connections to fetch updates or contact servers. A local development project is different: if it listens on port 8000, an exception such as sudo ufw allow 8000/tcp makes it reachable from the network. On a home LAN, it is safer to restrict the source, for example sudo ufw allow from 192.168.1.0/24 to any port 8000 proto tcp, after checking the actual subnet with ip route. The example subnet must match your own gateway; otherwise it can provide no useful access or expose more than intended.

Only expose ports for services that must receive connections. A development server, media indexer, or administration panel can reveal more information than its owner realises, and opening UDP as well as TCP may be unnecessary. The exception should match the application protocol rather than granting a broad range “just in case,” especially on a computer joined to a public or shared network. For ordinary web publishing, also terminate TLS correctly and keep the web server updated; opening a port does not make an insecure application safe.

Restrict access by source and interface

Where the client has a predictable address, an allow rule can be limited to that source. For example, sudo ufw allow from 203.0.113.10 to any port 22 proto tcp permits SSH only from the documented example address. The 203.0.113.0/24 range is reserved for documentation, so replace it with the real address before relying on the rule. For a small trusted office network, the source can be a CIDR range, but a narrower host address gives a clearer boundary.

Australian residential connections often use dynamic public addresses, while some mobile and business services use carrier-grade NAT, where an inbound public connection cannot be delivered at all. A rule tied to yesterday’s home address may fail after an address change; a business plan with a stable IP can be more predictable. Update the source address, use a secure tunnel, or restrict access at the router or cloud firewall instead of replacing the limit with access from anywhere. A DNS name is not a substitute for a stable source address because its resolution can change; obtain and record the actual endpoint used for administration.

For SSH, sudo ufw limit OpenSSH can reduce repeated connection attempts while still permitting normal use. UFW evaluates rules in their configured order, so a specific restriction placed before a broad allowance can prevent unintended access. Interface-specific rules offer another boundary, such as sudo ufw allow in on wlan0 to any port 22 proto tcp; use ip -br link to discover the current name, since wireless and Ethernet names vary between computers. Interface names can also change after a reboot or cable reconnection, so an interface rule should be checked along with the physical or virtual network it represents.

Inspect, edit and troubleshoot rules

Use sudo ufw status numbered when preparing to remove or reorder rules. Delete a known rule with sudo ufw delete 3, substituting the current number, then run the numbered command again because later numbers can shift. Rule comments are also valuable: sudo ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'office SSH' gives a future administrator context that the address alone does not provide. If the same service is represented by several similar entries, keep the narrowest rule and remove redundant ones to make later audits faster.

Before rebuilding a policy, copy /etc/ufw to a dated backup and record the output of sudo ufw status verbose. Most ufw commands update the saved configuration immediately, while sudo ufw reload is mainly needed after manual file edits. Avoid sudo ufw reset unless the intention is to disable UFW and erase its rules, since that command returns the host to a different security posture. For example, sudo cp -a /etc/ufw "/etc/ufw.backup-$(date +%F)" creates a dated copy of the saved configuration.

Troubleshooting works best from the service outwards. Use sudo ss -lntup to confirm that an application is listening, check the UFW rule, then examine the cloud security group and the Australian ISP-provided router or modem. Packet captures and sudo journalctl -u ufw can reveal dropped traffic. If you need to have a quick squiz at active rules, sudo ufw status verbose is the safest place to begin. Check name resolution separately with resolvectl status; a working web browser can still mask a local DNS issue, while ICMP tests may fail simply because ping is not a listed service.

Maintain a practical firewall policy

Treat the rule set as part of the system’s documentation rather than as a permanent pile of exceptions. Review it whenever a service, port, network interface, or hosting plan changes, and remove allowances for software that has been retired. Leaving every port wide open because it feels safer is not full marks; a small, understood policy is easier to audit and less likely to conceal an unnecessary service. A brief quarterly review is enough for a home computer, while a hosted or business system should be checked whenever its public exposure changes.

Keep elementary OS and installed applications updated, use strong authentication for remote accounts, and maintain tested backups outside the machine. A firewall supports the advice from Australia’s ASD cyber security guidance, but it does not make a system compliant with the Australian Privacy Act or secure on its own. For servers hosted in AWS’s Sydney region or Azure Australia East, keep the provider firewall, UFW, application access controls, and logging aligned. Backup schedules should also account for Australian daylight-saving transitions in Sydney, Melbourne, Adelaide, and Hobart, because an incorrectly configured job can run twice or be skipped.

The practical takeaway is to begin with denied incoming traffic and allowed outgoing traffic, add only the exact service or source that is needed, test remote access from a second session, and review the numbered rule list regularly so the policy remains small, current, and useful.