A beginner's guide to firewalld in Linux
Our world has never been more connected than it is right now. Every person, business, government, etc. uses the web to communicate, exchange currency and data, and generally go through the motions of daily life and operations. However, these connections are not inherently safe, and because of this, we have to put defensive measures in place to keep our location, information, and money protected. In times past, when someone wanted to secure their possessions, they erected gates and fences to keep intruders at a distance. Today, we accomplish these same goals with the use of firewalls. Most Linux systems made use of the iptables
utility, however, a new technology was on the horizon.
With the introduction of the Red Hat Enterprise Linux 7.0 (RHEL) in 2011, iptables was superceded as firewalld
was born. At its core, firewalld
is a zone-based firewall. Zone-based firewalls are network security systems that monitor traffic and take actions based on a set of defined rules applied against incoming/outgoing packets.
All about zones
Firewalld
provides different levels of security for different connection zones. A zone is associated with at least one network interface (eth0
, for example). We see the preconfigured zones by using the following command:
[tcarrigan@server ~]$ firewall-cmd --get-zones
block dmz drop external home internal libvirt public trusted work
As you see, the zones listed by default are:
- block
- dmz
- drop
- external
- home
- internal
- libvirt
- public
- trusted
- work
NOTE: I am using a RHEL 8.2 virtual machine for this demo.
Generally, the default rule of a firewall is to deny everything and only allow specific exceptions to pass through for needed services.
Many times, it is helpful to see what services are associated with a given zone. To display this information, use the following command:
firewall-cmd --list-all
Note that if you do not specify a zone, the default zone is queried. Here, the default zone is the public
zone.
[tcarrigan@server ~]$ firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3 enp0s8
sources:
services: cockpit dhcpv6-client mountd nfs rpc-bind ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
If you wish to specify a zone, you simply add --zone=zonename
For example, to see the external
zone, use the following:
[tcarrigan@server ~]$ firewall-cmd --zone=external --list-all
external
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
If, for some reason, you wanted to change the default zone, you can easily do so by using the following command:
firewall-cmd --set-default=zonename
Allow and deny by service
Now, the good thing about firewalls is that they keep our networks safe. The bad thing is that there is no "one-size fits all" firewall that fits every situation. Because of this, firewalls are customized to fit the exact needs of the situation that they are employed in. For example, if I need to allow FTP (File Transfer Protocol) transfers in the external
zone so that I can move a file over port 21, I might use something like this:
firewall-cmd --zone=external --add-service=ftp
Here is the actual example from my VM:
[tcarrigan@server ~]$ sudo firewall-cmd --zone=external --add-service=ftp
[sudo] password for tcarrigan:
success
We see that the daemon returned success, so we should have the FTP service allowed in the external
zone. To verify this, we need to check the external
zone services list:
[tcarrigan@server ~]$ firewall-cmd --zone=external --list-services
ftp ssh
But, what happens when we reload the firewall configuration?
[tcarrigan@server ~]$ sudo firewall-cmd --reload
success
[tcarrigan@server ~]$ firewall-cmd --zone=external --list-all
external
target: default
icmp-block-inversion: no
interfaces:
sources:
services: ssh
ports:
protocols:
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
The new allow rule doesn't survive the reinitialization of the firewalld
configuration. To ensure that our new rule persists, we need to add the --permanent
option. The new command is:
# firewall-cmd --permanent --zone=external --add-service=ftp
Once you use the permanent
command, you need to reload the configuration for the changes to take hold.
To remove a service, we make one small change to the syntax. Here, I am going to remove the FTP service from the external
zone permanently:
[tcarrigan@server ~]$ sudo firewall-cmd --permanent --zone=external --remove-service=ftp
Warning: NOT_ENABLED: ftp
success
We see that the system warns me that FTP has been disabled and that the operation was a success.
Allow and deny by port
Now, what happens when you need to allow traffic over a non-standard port? Imagine you have a backup service that needs to run over a dedicated UDP port. How would you add this exception to your zone? The syntax is very user friendly and is only slightly different from what we used for services. To add a port to your zone configuration, use the following:
[tcarrigan@server ~]$ sudo firewall-cmd --permanent --zone=external --add-port=60001/udp
success
We check the allowed ports with the following command:
[tcarrigan@server ~]$ sudo firewall-cmd --zone=external --list-ports
60001/udp
And to remove the port rule, you guessed it... simply switch --add-port=x
to --remove-port=x
[tcarrigan@server ~]$ sudo firewall-cmd --permanent --zone=external --remove-port=60001/udp
success
What's next?
If, after reading this article, you're wondering what to do with the information, I highly recommend firing up your favorite VM (RHEL, Fedora, CentOS, etc.) and start experimenting with the commands above. The best way to learn is to get hands-on experience. If you found this content interesting, keep an eye on Enable Sysadmin for part two, where you'll dive into creating custom zones and more advanced rule creation.
[ Make network management easy. Check out Network automation for everyone, a free book from Red Hat. ]
![Give your Linux firewall a security boost](/sysadmin/sites/default/files/styles/card/public/2020-02/booster_cables%20Cropped.jpg?itok=UaNei8c0)
![Firewall testing and troubleshooting](/sysadmin/sites/default/files/styles/card/public/2020-03/firewall_on%20Cropped.jpg?itok=5VwaUjcl)
![Great wall](/sysadmin/sites/default/files/styles/card/public/2019-06/great-wall.jpg?itok=HM2E1_i1)
![Author’s photo](/sysadmin/sites/default/files/styles/user_picture_square/public/pictures/2019-09/Tyler_C.png?itok=dHhdsxRk)
Tyler Carrigan
Tyler is the Sr. Community Manager at Enable Sysadmin, a submarine veteran, and an all-round tech enthusiast! He was first introduced to Red Hat in 2012 by way of a Red Hat Enterprise Linux-based combat system inside the USS Georgia Missile Control Center. More about me