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, which introduces the firewall-cmd front-end to the firewall rule management program (iptables) for the Linux kernel. I’ve liked all the other changes Fedora Linux 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 isn’t enabled by default in Ubuntu nor installed by default in Debian. As its name suggests, it’s fairly uncomplicated to set up and maintain. It has an easy to remember syntax that’s more friendly to human users than the underlying iptables rules.
It doesn’t have too many features and there’s 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 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 set up 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 aren’t 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 examfple for allowing remote access to a local web server and showing that the rule was added afterward:
Uncomplicated Firewall:
ufw allow http,https
ufw statusFirewallD:
firewall-cmd --permanent --add-service=http --add-service=https
firewall-cmd --reload
firewall-cmd --stateYou’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’s 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 statusThis feature isn’t 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’s 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 Linux 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 Linux) 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’s 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 allow and block lists would quickly 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’ve to be changed manually. These profiles aren’t integrated into the 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 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 Linux and Red Hat Enterprise but the more complex syntax may require more learning.
Both firewalld and ufw are available in the Debian, Ubuntu, and Fedora Linux package repositories.