Subscribe to the feed
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. ]


About the author

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. Now that he has surfaced, he lives with his wife and son near Raleigh, where he worked as a data storage engineer before finding his way to the Red Hat team. He has written numerous technical documents, from military procedures to knowledgebase articles and even some training curricula. In his free time, he blends a passion for hiking, climbing, and bushcraft with video games and computer building. He is loves to read and enjoy a scotch or bourbon. Find him on Twitter or on LinkedIn.

Read full bio
UI_Icon-Red_Hat-Close-A-Black-RGB

Browse by channel

automation icon

Automation

The latest on IT automation for tech, teams, and environments

AI icon

Artificial intelligence

Updates on the platforms that free customers to run AI workloads anywhere

open hybrid cloud icon

Open hybrid cloud

Explore how we build a more flexible future with hybrid cloud

security icon

Security

The latest on how we reduce risks across environments and technologies

edge icon

Edge computing

Updates on the platforms that simplify operations at the edge

Infrastructure icon

Infrastructure

The latest on the world’s leading enterprise Linux platform

application development icon

Applications

Inside our solutions to the toughest application challenges

Original series icon

Original shows

Entertaining stories from the makers and leaders in enterprise tech