ufw vs. firewalld: Choosing the Best Firewall for Your Linux Server.

ufw or firewalld? 15 minutes from now you’ll know which one is right for you

I got locked out of my own server last April.

One wrong rule, hit enter, and bang—SSH session gone. Thirty minutes of panic while I hunted down the cloud provider’s rescue console.

The mistake? I chose the wrong firewall tool for the job.

You only need two things to avoid that pain:

1. A clear picture of what ufw and firewalld actually do.
2. Thirty seconds to match them to your server.

Let’s do this quickly.

What are we even talking about?

Both tools are just friendly front doors to the same bodyguard: Linux’s nftables.

• ufw keeps the language simple—perfect if you hate manuals.
• firewalld adds zones—great if you like labelled boxes for everything.

That’s the whole story in one sentence.

My one-question test to pick between them

Q: Do you have one network cable and one job, or many cables and shifting jobs?

If the answer is “one,” ufw wins. If the answer is “lots,” firewalld wins.

Too vague? Here’s what that looked like when I helped a friend last month.

A real mini-case study

Emma runs a WordPress blog on Ubuntu. She pays Digital Ocean ten bucks a month for:

• a single IPv4 address
• SSH on port 22
• HTTP on 80, HTTPS on 443

We finished the whole setup in six commands:

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable

Done. Firewall locked, blog online. Total time: 90 seconds.

When zones start to matter

Contrast that with Marcus. He has a CentOS server with:

• a public IP hanging off the internet (eth0)
• a private subnet at home plugged into eth1
• docker networks juggling containers

Semaphores, drop rules, and shifting interfaces—too messy for flat rules.

With firewalld, he grouped stuff into zones:

• public for the web traffic from the scary internet
• internal for the safe home subnet
• trusted for the Docker bridge

Adding a new app inside a zone took one tool call instead of rewriting the entire ruleset. That flexibility is why Marcus sleeps well.

The 60-second side-by-side

No spreadsheet needed—just copy-paste the row that matches you.

My “don’t brick the server” checklist (I still use this)

Before you run ufw enable or firewall-cmd --reload:

1. Open two SSH sessions from different machines. If you kill one, the other still works.
2. Schedule a rescue console session with your provider as a back-up parachute.
3. Copy-paste the current rules to a scratchpad so you have an undo button.

Quick start snippets you can steal

ufw in 5 lines

# % sudo -i
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment "SSH from anywhere"
ufw limit 22/tcp   # get brute-force throttling for free

firewalld in 7 lines

# % sudo -i
firewall-cmd --permanent --zone=public --add-service=ssh
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --permanent --new-zone=management
firewall-cmd --permanent --zone=management --add-source=10.0.0.0/24
firewall-cmd --permanent --zone=management --add-service=ssh
firewall-cmd --reload   # keeps existing sessions alive

Still can’t decide? Cheat

Use the distro’s default. That’s why it’s the default—it fits the majority case:

• Ubuntu, Debian? Just type sudo ufw enable and move on.
• CentOS, RHEL, Fedora? sudo systemctl start firewalld and you’re set.

The one thing better than the “perfect” firewall

A backup of working rules.

ufw stores in /etc/ufw/user.rules. Firewalld stores in /etc/firewalld/. Copy either to your password manager’s notes section right now—before you need it at 3 a.m.

Do this once and future-you will thank you with chocolate.

TL;DR

Six words:

• ufw when things are simple.
• firewalld when things change.

Pick one, back up your rules, and you won’t star in tomorrow’s hacker headline.