Swirling firewall

Comparing and contrasting Uncomplicated Firewall and FirewallD

I’ve recently moved all my computers and servers from Debian to Fedora Linux, and that brought along some new and interesting changes to the technologies I’ve relied on over the last few years. One of those new technologies is FirewallD, who introduces the firewall-cmd front-end to the firewall rule management program (iptables) for the Linux kernel.

Both firewalld and ufw are available in the Debian and Ubuntu package repositories, but only firewalld is available in Fedora’s repository. I’ve liked all the other changes Fedora have brought to my life, so I decided to sit down and learn about it and compare the two.

I’ve used Canonical’s Uncomplicated Firewall (ufw) to configure the iptables on every Ubuntu and Debian system I’ve used in recent years. The firewall is not enabled by default in Ubuntu nor installed by default in Debian. As its name suggest, it’s fairly uncomplicated to set up and maintain. It has an easy to remember syntax that is more friendly to human users than the underlying iptables rules. It doesn’t have too many features and there is nothing to configure but the rules for which services are allowed to receive incoming connections. After enabling its service script, an administrator need only enter a few short commands to tell it exactly what they want. I picked up the syntax after about five minutes and haven’t had any problems remember it since then.

Fedora and Red Hat Enterprise Linux uses and enables FirewallD by default. Its firewall-cmd front-end has almost the same feature set for basic firewall management as ufw, and adds network zone management to the mix. Zone management allows you to setup presets with rules for different network conditions/locations. For example “Home” and “Office” where all communications with local machines are allowed, and “Public Wi-Fi” where no communication with the same subnet would be allowed. Rules can be applied automatically per network interface, or used through NetworkManager and the GNOME network GUI.

Both front-ends come with pre-defined rules for common server services and protocols. These rules include a keyword/name and associated industry standards and default ports for running services publicly. They each come in their own formats that are not interoperable with each other, of course. ufw uses service-named files containing one line with port and protocol, and FirewallD uses six lines of XML to create the same profile.

ufw itself is a short command and relies on short arguments, firewall-cmd requires more typing and longer arguments. Here is an example for allowing remote access to a local web server and showing that the rule was added afterwards:

Uncomplicated Firewall:

ufw allow http,https
ufw status


firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --state

You’ll notice the verbosity of the firewall-cmd commands compared to ufw right away. In the above example, I glossed over the zone management and assumed the default firewall zone. If you read both commands carefully, you’ll notice that the command is called “firewall-cmd” and not “firewalld-cmd”. Naming the program FirewallD with a capital D at the end, and having another d at the end of the command line name but not calling it firewalld-cmd is enough to short-circuit the command-memory in the brain of most humans. At least for me, there is something in the way my brain sees patterns and recognizes words and commands that makes me type the wrong command as least as often as I type the correct one. I’ve had to create an alias pointing firewalld-cmd to firewall-cmd to capture and reduce all the times I type the command wrong.

Rate-limiting connections

The one feature I miss in firewall-cmd that I used on every system with ufw is the rate-limiting keyword. ufw can allow access to a service but reject connections if it exceeds six per 30 seconds from the same origin IP address. This is useful to discourage anything from brute-force login attacks on shell and web services, and to stop servers from delivering tons of spam comments in a very short time to a WordPress blog or email server.

Uncomplicated Firewall:

ufw limit ssh,smtp,submission
ufw status

This feature is not exposed in firewall-cmd. You can passthrough the iptables rules that are generated from the above command through firewall-cmd and directly into iptables using the --direct <iptables-rule> argument. There would be no benefit from using firewall-cmd to manage iptables if you start passing complex rules straight through it and it introduces a larger risk for mistyping as arguments aren’t validated as thoroughly as the main arguments. There are also plenty of configuration pitfalls  —  like not remembering to re-create each rule for IPv4 and IPv6 separately  —  that are much more likely to affect you when you do things this way. If iptables were ever to be replaced in a future version of Fedora or the Linux kernel, your direct firewall rules could stop working. On the other hand, ufw’s hard-coded six-connections-per-30-seconds is non-configurable. For certain types of traffic it would make sense to increase this limit and for other types of traffic you would like to expand the time window. Managing iptables rules around ufw is more complicated than using passthrough with FirewallD.

You can still mitigate excessive connections by supplementing firewall-cmd (or ufw) with Fail2Ban. Fail2Ban is a utility that reads log files, checks timestamps, and adds temporary blocking rules to iptables (by talking to FirewallD on Fedora) when it finds repeated connections from the same IP address. This depends on your services abilities to generate logs fast enough and your server to have enough memory to make Fail2Ban effective against larger sustained attacks. Dropping the connections as they attempt to connect means the machine will be able to survive a larger attack than one where each connection is established and needs additional processing on the server.

firewall-cmd has a feature called “rich rule” which does support rate-limiting, but it’s not meant to be used the same way as ufw’s limit argument. In rich rules, you can configure a rate-limit to and from given a port or service. However, there is no granular control in time nor automated hit-counting per origin IP. You’re limited to specify how many connections the service can receive from any IP within either 1 second, 1 minute, or 1 hour. You can supplement such rules per IP or IP range, but maintaining such whitelists or blacklists would soon become a maintenance problem. From what little documentation exists, the feature seems to have been implemented to rate-limit FirewallD’s local log-writing and not network traffic or external threats.

Update: I’ve chatted with FirewallD’s lead developer Thomas Woerner, and he was positive to adding support for per-IP rate limiting to FirewallD.

Graphical options

Gufw—the Graphical Uncomplicated Firewall front-end—is a simple desktop program for managing ufw. It introduces firewall profiles that are similar to FirewallD’s zones, but they have to be changed manually. These profiles are not integrated into Ubuntu Unity desktop’s network GUI. When you open Gufw it tells you the current firewall status and profile, and gives you a compact and easy-to-understand overview of the current firewall rules. It’s especially useful for troubleshooting purposes to have the firewall log tightly integrated into the interface.

FirewallD also offers a graphical front-end called firewall-config. Where Gufw offers a minimalist interface that’s easy to understand, firewall-config is focused entirely on configuring the firewall and not to give a quick status indication or troubleshooting. I found this utility much harder to get an overview of the firewall and harder to work with than firewall-cmd.


I’ve only discussed some basic examples in this article, but I believe they’re representative when comparing FirewallD to Uncomplicated Firewall. Both are fairly straight-forward but ufw will be less intimidating to inexperienced users. ufw’s shorter and self-explanatory syntax is probably going to be the better option for sysadmins and users who don’t want to configure a firewall but realize that they need one anyway. FirewallD is better suited for a roaming user on a laptop than ufw because of the automatic zone-management went paired up with NetworkManager.

For server administrators it doesn’t really matter which one you use. ufw is disabled by default in Ubuntu Server edition but is very trivial to learn and enable but FirewallD is enabled by default in Fedora and Red Hat Enterprise but the more complex syntax may require more learning.

4 thoughts on “Comparing and contrasting Uncomplicated Firewall and FirewallD”

  1. Nice article..

    About Fedora…. I just don’t get it!

    How come people use fedora as a server where each release lives for 12-18 months?? Why not the LTS distros?

    Upgrading? Every year or so?
    Why would anyone agrees to be in a position where he has to decide between ‘keep the server running without any security updates anymore.” and “taking your chances with upgrading” .. ?

    While you can totally forget about that headache for 5-10 years.!

    Which means upgrade when you want and ready to, not when you’re somehow being forced to.

    1. Because the technology, especially for web servers, is moving so damned fast. You need newer versions of Apache to take advantage of innovations like HTTP/2.

      I also don’t believe that you gain anything on postponing the upgrade cycle for years and years. It’s better to stay on top of the changing technology platform and adjust your setup a little by little. When you eventually upgrade an LTS distro, the landscape look so different that you end up spending way more time figuring out how to reconfigure it the way you want.

      1. Hi Daniel,

        Are those the main reasons you moved from Debian to Fedora?

        Are you planning to write an article that explain why you did that?

        I am learning Debian at the moment and got worried when reading your acticle that I was on the wrong track.

        1. Have you read “Migrated from Debian to Fedora”?

          “Newer software” and “more frequent updates” were my primary reasons, yes. Debian is a good solid choice, but the price you pay for having a stale/stable system is that you run older software and have to perform fewer and more complex updates. A more up-to-date distribution like Fedora forces you to pay attention and stay atop of things as they happen rather than having to spend a lot of time to investigate everything that has changed in the many years between Debian releases.

Leave a Reply

Your email address will not be published. Be courteous and on-topic. Comments are moderated prior to publication.