<\/span><\/h2>\n\n\n\nWith SSH secured, open what your workload genuinely requires \u2014 and nothing else. Every open port is a surface an attacker can probe.<\/p>\n\n\n\n
A standard web server needs HTTP and HTTPS:<\/p>\n\n\n\n
sudo ufw allow 80\/tcp comment 'HTTP'\nsudo ufw allow 443\/tcp comment 'HTTPS'\n<\/code><\/pre>\n\n\n\nPort 80 is still worth opening even on an HTTPS-only site, because Let’s Encrypt HTTP-01 validation uses it and most sites redirect 80 to 443 anyway.<\/p>\n\n\n\n
Other common patterns:<\/p>\n\n\n\n
sudo ufw allow 25\/tcp comment 'SMTP'\nsudo ufw allow 587\/tcp comment 'Submission'\nsudo ufw allow 993\/tcp comment 'IMAPS'\nsudo ufw allow 53 comment 'DNS'\nsudo ufw allow 51820\/udp comment 'WireGuard VPN'\n<\/code><\/pre>\n\n\n\nsudo ufw allow 53<\/code> without a protocol opens both TCP and UDP, which DNS needs. For almost everything else, name the protocol. Port ranges use a colon and require one: sudo ufw allow 60000:60010\/udp<\/code>.<\/p>\n\n\n\nPorts that should almost never face the world: 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), 27017 (MongoDB) and 9200 (Elasticsearch). If the database lives on the same server as the app, bind it to 127.0.0.1<\/code> and it needs no UFW rules at all. If it lives elsewhere, Rule 5 shows how to open it to one host only. Exposed databases remain one of the most common causes of real-world data loss.<\/p>\n\n\n\n<\/span>Rule 5 \u2014 Write Tighter UFW Rules with Sources, Subnets and Interfaces<\/span><\/h2>\n\n\n\nBasic allow rules open a port to everyone. The real power of UFW rules is restricting who<\/em> can reach them, using the from<\/code> and to<\/code> syntax.<\/p>\n\n\n\nAllow a single trusted IP address to reach your database:<\/p>\n\n\n\n
sudo ufw allow from 203.0.113.45 to any port 5432 proto tcp comment 'App server to Postgres'\n<\/code><\/pre>\n\n\n\nAllow an entire private subnet \u2014 typical for a provider’s internal network:<\/p>\n\n\n\n
sudo ufw allow from 10.0.0.0\/8 to any port 3306 proto tcp comment 'Private network to MySQL'\n<\/code><\/pre>\n\n\n\nRestrict SSH to your office or home IP, which eliminates essentially all brute-force noise:<\/p>\n\n\n\n
sudo ufw allow from 198.51.100.22 to any port 22 proto tcp comment 'Office SSH'\n<\/code><\/pre>\n\n\n\nBe careful with that last one on a dynamic home IP \u2014 if your address changes, you are off to the provider console. Keep a jump-host rule as backup, or rely on rate limiting (Rule 6) instead.<\/p>\n\n\n\n
You can also scope UFW rules to one network interface, useful on servers with public and private NICs:<\/p>\n\n\n\n
sudo ufw allow in on ens4 to any port 6379 proto tcp comment 'Redis on private NIC only'\n<\/code><\/pre>\n\n\n\ndeny<\/code> silently drops traffic and gives a scanner nothing. reject<\/code> sends an explicit refusal, which is friendlier on internal networks:<\/p>\n\n\n\nsudo ufw deny from 192.0.2.0\/24 comment 'Abusive range'\nsudo ufw reject from 10.0.5.0\/24 to any port 8080 comment 'Deprecated internal client'\n<\/code><\/pre>\n\n\n\nOrder matters: UFW rules are evaluated top to bottom and the first match wins, so a broad allow above a narrow deny makes the deny pointless. Insert by position to fix that:<\/p>\n\n\n\n
sudo ufw insert 1 deny from 192.0.2.66 comment 'Blocked scanner'\n<\/code><\/pre>\n\n\n\n<\/span>Rule 6 \u2014 Rate-Limit SSH and Other Brute-Forced Ports<\/span><\/h2>\n\n\n\nUFW has a built-in brute-force defence that almost nobody uses, and it is one line:<\/p>\n\n\n\n
sudo ufw limit 22\/tcp comment 'SSH rate limited'\n<\/code><\/pre>\n\n\n\nThe limit<\/code> verb denies a source IP that has attempted six or more connections to that port within thirty seconds. Legitimate users never trip it. Automated password-guessing bots trip it constantly, and once tripped they are dropped rather than being allowed to keep trying.<\/p>\n\n\n\nIf you already created a plain allow rule for SSH, replace it rather than stacking a second rule on top:<\/p>\n\n\n\n
sudo ufw delete allow 22\/tcp\nsudo ufw limit 22\/tcp comment 'SSH rate limited'\n<\/code><\/pre>\n\n\n\nRate limiting works on any TCP port, so it is equally useful in front of an admin panel. It is not a substitute for Fail2Ban, which bans on failed-login patterns from application logs \u2014 run both. One caveat: limits track source IPs, so many users behind one office NAT can collectively trip them. Allow that range explicitly above the limit rule.<\/p>\n\n\n\n
<\/span>Rule 7 \u2014 Read UFW Status Like an Auditor<\/span><\/h2>\n\n\n\nChecking UFW status is not a one-time formality. It is how you verify the UFW firewall does what you think it does.<\/p>\n\n\n\n
sudo ufw status verbose\nsudo ufw status numbered\n<\/code><\/pre>\n\n\n\nThe verbose UFW status shows active state, logging level, default policies and every rule. Read the policy line first \u2014 deny (incoming), allow (outgoing), deny (routed)<\/code> is the target \u2014 then ask whether you can still justify each rule. The numbered UFW status is what you use for editing and for auditing a server you inherited. Rules with Anywhere<\/code> as the source are open to the whole internet: fine for 80 and 443, suspicious for anything else. A (v6)<\/code> twin of every rule is normal \u2014 that is the IPv6 copy.<\/p>\n\n\n\nFinally, verify from the outside. An Ubuntu firewall that looks correct locally but behaves differently from the internet is one you don’t understand. From another machine:<\/p>\n\n\n\n
nmap -Pn -p 22,80,443,3306 your-server-ip\n<\/code><\/pre>\n\n\n\nOpened ports should report open<\/code>; everything else filtered<\/code> \u2014 exactly what a default-deny UFW firewall should produce. If a port you never opened reports open<\/code>, something is bypassing your UFW rules, which brings us to Rule 8. <\/p>\n\n\n\nThe nine-rule blueprint, from installation through long-term maintenance.<\/figcaption><\/figure>\n\n\n\n<\/span>Rule 8 \u2014 Handle Docker, IPv6 and Cloudflare Before They Bite<\/span><\/h2>\n\n\n\nThree situations routinely break an otherwise correct UFW firewall. Knowing about them in advance is far cheaper than discovering them in production.<\/p>\n\n\n\n
<\/span>Docker bypasses your UFW rules<\/span><\/h3>\n\n\n\nThis surprises almost everyone. When you publish a container port with -p 8080:80<\/code>, Docker writes its own kernel rules that are evaluated before<\/em> UFW’s. Your default-deny policy is never consulted, and the container is exposed even though the UFW status shows no rule permitting it.<\/p>\n\n\n\nThe clean fix is to bind published ports to localhost and put a reverse proxy in front:<\/p>\n\n\n\n
docker run -p 127.0.0.1:8080:80 my-image\n<\/code><\/pre>\n\n\n\nIn a Compose file, the same thing looks like this:<\/p>\n\n\n\n
ports:\n - \"127.0.0.1:8080:80\"\n<\/code><\/pre>\n\n\n\nThe container is now reachable only from the host, and the UFW firewall is back in control of what the outside world can touch.<\/p>\n\n\n\n
<\/span>IPv6 is on by default and often forgotten<\/span><\/h3>\n\n\n\nUFW manages IPv6 automatically when IPV6=yes<\/code> is set in \/etc\/default\/ufw<\/code>, which is the default \u2014 confirm with grep IPV6 \/etc\/default\/ufw<\/code>. The failure mode to avoid is disabling IPv6 in UFW while it stays enabled on the network interface: a server filtered on IPv4 and wide open on IPv6.<\/p>\n\n\n\n<\/span>Cloudflare and other proxies change what you are filtering<\/span><\/h3>\n\n\n\nBehind Cloudflare, all legitimate web traffic arrives from the proxy’s ranges, so you can allow 80 and 443 only from those ranges and stop attackers hitting your origin directly. Automate the range updates, and remember that blocking a proxied visitor in the Ubuntu firewall blocks the proxy, not them \u2014 those bans belong at the edge.<\/p>\n\n\n\n
<\/span>Managing UFW Rules After the Firewall Is Live<\/span><\/h2>\n\n\n\nServices change and stale UFW rules quietly accumulate. Delete by number \u2014 the safest method, because you see what you are removing:<\/p>\n\n\n\n
sudo ufw status numbered\nsudo ufw delete 4\n<\/code><\/pre>\n\n\n\nDeleting renumbers everything below, so re-check the numbered UFW status between deletions. You can also delete by matching the rule, as in sudo ufw delete allow 8080\/tcp<\/code>. There is no in-place edit: delete and re-add. Rules persist across disable<\/code>\/enable<\/code> and reboots, sudo ufw reload<\/code> applies edits to config files, and sudo ufw reset<\/code> wipes everything \u2014 never run it over SSH without console access ready.<\/p>\n\n\n\nBack up before significant changes:<\/p>\n\n\n\n
sudo tar -czf ~\/ufw-backup-$(date +%F).tar.gz \/etc\/ufw \/etc\/default\/ufw\n<\/code><\/pre>\n\n\n\nBetter still, keep your UFW rules in a provisioning script. A UFW firewall you can rebuild from version control is one you can reason about.<\/p>\n\n\n\n
<\/span>Rule 9 \u2014 Log, Monitor and Maintain the Ubuntu Firewall<\/span><\/h2>\n\n\n\nA UFW firewall nobody watches tells you nothing when something goes wrong. Enable logging:<\/p>\n\n\n\n
sudo ufw logging on\n<\/code><\/pre>\n\n\n\nThe default low<\/code> level records blocked packets and suits most servers. medium<\/code> helps while debugging.