Firewalld on Red Hat: Configuring Server Firewall with Network Zones

The Role of Firewalls in Modern Linux Servers

Managing an internet-connected server requires the same care as locking the doors of a physical building. In the Linux ecosystem, Firewalld acts as this automated watchman, controlling which connections enter and leave the operating system. In practice, it functions as a digital traffic cop intercepting every data packet at the network boundary and deciding whether it gains free access or is summarily dropped based on predefined policies.

Historically, administrators relied on rigid tools that required rewriting entire rule sets for every minor modification. Firewalld changed this dynamic by introducing a dynamic management layer. This means you can adjust network permissions in real-time without dropping active connections or restarting the security subsystem, ensuring the operational continuity that modern enterprise applications demand to maintain high availability.

Understanding the Network Zone-Based Model

The core architectural genius of Firewalld is the concept of zones, which are logical divisions of network space categorized by trust levels. Think of them as office access badges: the public zone represents a reception area open to strangers, while the internal zone equals a restricted room for authorized personnel only. Each server network interface is assigned to one of these zones, instantly determining the default behavior for traffic passing through it.

By default, the public zone is the most common on internet-facing servers, applying a restrictive posture where all incoming traffic is denied except what is explicitly permitted. If your server runs on a closed corporate network, you can move the interface to the internal or trusted zone, relaxing certain restrictions to facilitate internal communication. This segmentation prevents an attack from a public network from compromising services meant only to talk to trusted machines within the same rack.

Installation, Verification, and Base Service Control

In Red Hat Enterprise Linux-based distributions, such as RHEL, Rocky Linux, and AlmaLinux, Firewalld usually comes installed by default. Before altering any configuration, the first practical step is to verify that the service is active and running on the operating system. For this, we use the system service management tool, systemctl, which controls background processes.

Run the command below in the terminal to check the current firewall status:

sudo systemctl status firewalld

If the service is inactive, you can start it and configure it to launch automatically during server boot using sudo systemctl start firewalld and sudo systemctl enable firewalld. Keeping this service always active ensures that no network interface remains unprotected if an unexpected machine reboot occurs due to power failure or maintenance.

Managing Ports and Services via Command Line

The default administration interface for Firewalld is the firewall-cmd command. With it, you interact directly with the firewall core without having to manually edit complex text files. The primary distinction when using this tool is the difference between applying immediate runtime rules and permanent rules that survive server reboots.

To grant access to the traditional web server on port 80, for example, we use the system's predefined service concept. The following command opens HTTP traffic permanently in the public zone:

sudo firewall-cmd --permanent --zone=public --add-service=http

After changing rules with the --permanent flag, the firewall must be reloaded for the core to absorb the new directives. We do this by running sudo firewall-cmd --reload. If you need to open a specific port that lacks a mapped service, such as port 8080 for a custom application, simply replace --add-service=http with --add-port=8080/tcp while maintaining the same operational rigor.

Creating Advanced Rules and Specific Blocks

When infrastructure grows, basic ports and services are no longer enough to contain sophisticated threats. This is where rich rules come in. They allow you to create surgical exceptions, such as allowing database access exclusively to a specific application server IP address while blocking the rest of the internet.

Imagine you need to authorize access to the MySQL port (3306) strictly for the IP 192.168.1.50. The command for this operation uses structured syntax:

sudo firewall-cmd --permanent --zone=public --add-rich-rule='rule family=