12 Essential UFW Firewall Commands to Secure Any Linux Server

Every fresh Linux server I set up gets the same treatment in the first five minutes: updates, a non-root user, SSH keys, and a ufw firewall configuration. UFW stands for Uncomplicated Firewall, and the name is accurate. It wraps iptables and nftables in a syntax you can actually remember, so blocking a port takes one short command instead of a chain of cryptic flags. These twelve commands cover everything I use in day-to-day server administration.

Why the ufw firewall beats raw iptables

Writing iptables rules by hand works, but the syntax punishes you. A single typo in a chain name silently does nothing, and rules vanish on reboot unless you persist them yourself. UFW handles persistence automatically and validates rules before applying them.

The tradeoff is granularity. If you need per-packet marking or complex NAT, you still want nftables directly. For a web server or a VPS that runs SSH plus two or three services, UFW does the job with a fraction of the typing.

Installing the ufw firewall

Ubuntu ships with UFW preinstalled but disabled. On Debian, grab it from the standard repos:

sudo apt install ufw

Fedora and RHEL use firewalld by default, but UFW is available there too:

sudo dnf install ufw

On Arch it lives in the official repos as well: sudo pacman -S ufw. The project itself is maintained by Canonical, and the source lives on Launchpad.

1. Check status before touching anything

sudo ufw status verbose

This shows whether the firewall is active, the default policies, and every rule currently loaded. The verbose flag adds logging level and default policy direction. Run it first on any box you inherit. I have seen production servers where someone enabled UFW years ago and nobody remembered.

2. Set sane defaults

sudo ufw default deny incoming
sudo ufw default allow outgoing

Deny everything inbound, allow everything outbound. This is the baseline for almost every server. Anything you want reachable from outside gets an explicit allow rule afterwards.

3. Allow SSH before you enable anything

sudo ufw allow 22/tcp

Do this before enabling the ufw firewall on a remote machine. Skip it and the enable step cuts your own connection. If SSH runs on a custom port, adjust accordingly: sudo ufw allow 2222/tcp.

4. Turn it on

sudo ufw enable

The ufw firewall warns you that existing SSH connections may drop. If you added the SSH rule in step 3, you are fine. The firewall now starts automatically on every boot, no extra persistence work needed.

5. Allow services by name

sudo ufw allow http
sudo ufw allow https

UFW reads /etc/services, so common service names resolve to their ports. It also ships with application profiles. List them with sudo ufw app list, then allow a whole profile at once:

sudo ufw allow "Nginx Full"

The Nginx Full profile opens ports 80 and 443 together in one rule.

6. Restrict a port to one IP address

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

My favorite rule type. SSH stays invisible to the rest of the internet and answers only to your static IP or VPN address. Subnets work too:

sudo ufw allow from 10.0.0.0/24 to any port 5432 proto tcp

That one lets your internal network reach PostgreSQL while everyone else gets dropped.

7. Rate limit brute force attempts

sudo ufw limit 22/tcp

The limit rule allows connections but blocks an IP that attempts six or more connections within thirty seconds. It is a cheap first line of defense against SSH brute forcing. For anything serious, pair the ufw firewall with fail2ban. I covered that setup in my fail2ban commands guide, and the two tools complement each other well.

8. Deny and reject are different

sudo ufw deny 23/tcp
sudo ufw reject 8080/tcp

deny drops packets silently, so a scanner sees a timeout. reject sends back an ICMP refusal, so the sender knows immediately that the port is closed. Deny is the better default for internet-facing boxes because it wastes the scanner’s time.

9. Delete rules cleanly

sudo ufw status numbered
sudo ufw delete 3

The numbered status output gives each rule an index. Delete by number rather than retyping the full rule text. Numbers shift after each deletion, so re-run the status command between deletes.

10. Manage ufw firewall logging

sudo ufw logging on
sudo ufw logging medium

Logs land in /var/log/ufw.log. The default low level records blocked packets that do not match any rule. Medium adds allowed connections and invalid packets. I keep production servers on low because medium gets noisy fast on a public IP. For watching outbound connections per application rather than per port, OpenSnitch is the better tool.

11. Test rules without locking yourself out

sudo ufw --dry-run allow from 192.168.1.0/24

The dry run flag prints the resulting iptables rules without applying anything. Useful when a rule involves subnets or interface names and you want to confirm what UFW will generate. And if you do break something, sudo ufw reset wipes all rules and disables the firewall so you can start over.

12. Handle IPv6 properly

grep IPV6 /etc/default/ufw

Check that IPV6=yes is set. When it is, every rule you add applies to both address families automatically. Servers with a public IPv6 address and an IPv4-only firewall are a classic misconfiguration, and attackers scan v6 ranges more than most admins expect.

When not to use the ufw firewall

Docker bypasses UFW by writing its own iptables rules, so published container ports stay reachable even when your ufw firewall denies them. Either bind containers to 127.0.0.1 or use the ufw-docker workaround. Kubernetes nodes, complex NAT gateways, and multi-homed routers also outgrow UFW quickly. For those, go straight to nftables.

For intrusion prevention that reacts to behavior instead of static rules, CrowdSec layers nicely on top of the firewall.

Where to go from here

Twelve ufw firewall commands is enough to secure most single-purpose servers. The Ubuntu UFW community documentation covers application profiles and advanced syntax in more depth, and the ufw man page documents every flag, including the route rules for forwarding setups I skipped here.

Start with the defaults in step 2, add your allow rules, enable, and check the logs a week later. That routine has kept my servers quiet for years.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts