Table of Contents
Introduction
Linux firewalls provide a controlled gateway between your system and the network. At the kernel level, Linux uses packet filtering to decide which network packets are allowed and which are blocked. For most administrators, direct kernel-level management is unnecessary. Instead, user friendly tools such as UFW and firewalld are used to define and maintain firewall rules.
This chapter focuses on what is specific to these two tools, how they differ, and how you use them in practice on typical Linux distributions.
UFW: Uncomplicated Firewall
UFW, which stands for Uncomplicated Firewall, is a simple command line frontend commonly used on Debian and Ubuntu based systems. It is designed to make basic firewall setup quick and readable without deep knowledge of underlying packet filtering syntax.
UFW operates with a clear enabled or disabled state. When UFW is disabled, it does not enforce its rules, and packet filtering falls back to any other system configuration or defaults. When UFW is enabled, its rules are applied by the system.
A typical workflow with UFW starts with checking its status. The status shows whether it is active and lists currently applied rules in a human readable way. Next, you define what to allow and optionally what to deny. Rules are often expressed in terms of applications or ports and their associated protocols.
For example, allowing incoming SSH connections with UFW relies on either a named application profile or a direct port specification. Named profiles are defined in the system and encapsulate common settings, such as the default SSH port. Alternatively, you can base your rule on tcp or udp ports.
UFW can also restrict access based on source addresses. This enables you to only allow specific networks or hosts to reach a given service. UFW understands both IPv4 and IPv6 addresses and can match single hosts or entire subnets. When you specify a subnet, you use the familiar CIDR notation with a slash and prefix length, such as 192.168.1.0/24.
You can also control outgoing traffic with UFW, not just incoming connections. By default, many systems that use UFW allow all outgoing connections while restricting incoming ones. However, you can explicitly define default policies for incoming and outgoing traffic. Once default policies are set, more specific allow and deny rules override those defaults.
UFW stores rules persistently, so once you enable it and define your rules, they are applied automatically at boot. This simplifies administration on servers and desktops because you do not need to reapply rules after a restart.
With UFW, always confirm the status and rules before and after changes to avoid accidentally blocking your own access, especially when working over SSH.
Important rules:
- Enable the firewall only after adding at least one rule that permits your remote management method.
- Set default policies first, then add explicit allow rules for required services.
Managing UFW Rules
UFW rules are evaluated in the order they are shown. UFW lists them with numbers which allows you to delete or insert rules based on their position. Basic usage typically adds rules in sequence. More advanced usage benefits from controlling order, especially when combining broad and specific rules.
Rules can target applications, ports, and protocols, and can also distinguish between interfaces. For example, you might want a service to be reachable only on a specific network interface. UFW lets you bind rules to an interface name, both for incoming and outgoing traffic related to that interface.
Logging can be enabled in UFW so that the firewall records information about allowed or denied packets. This is helpful when diagnosing connectivity issues. The logging level can be adjusted to provide minimal or verbose details. Since logging can generate significant data, it should be tuned to the level necessary for your monitoring and troubleshooting.
Sometimes you may need to temporarily relax firewall restrictions for troubleshooting. With UFW, you can either disable it fully or selectively remove rules. Disabling temporarily is simple but risky if the system is exposed to untrusted networks. A more careful approach is to adjust only the rules that affect the service under test.
firewalld Overview
firewalld is a firewall management service that is common on Fedora, RHEL, CentOS and several other distributions. It provides a higher level abstraction around packet filtering and is designed to be dynamic. This means rules can be modified at runtime without disrupting existing connections.
The core concepts in firewalld are zones and services. Zones represent different levels of trust for network connections, and services group together port and protocol settings for common network services. By assigning interfaces and connections to zones, you apply different rules depending on where the traffic comes from or where it is going.
firewalld runs as a background service and manages firewall configuration through direct commands or through graphical and network management tools. It maintains both runtime and permanent configurations. The runtime configuration is what is active immediately, while the permanent configuration is what persists across reboots.
In many systems, firewalld is enabled and started by default. Administrators interact with it using the firewall-cmd utility or a graphical frontend. Through firewall-cmd, you query the current configuration, add or remove rules, and manage services, ports, and zones.
One of firewalld’s advantages is that changes to rules do not require a complete reload that breaks connections. Some actions still require a reload, but firewalld is designed to minimize disruption.
With firewalld, always distinguish between runtime and permanent changes.
Rules added with --permanent affect future boots only, while rules without this option affect only the current runtime state.
Important rule:
Always apply rule changes in runtime first, confirm they work, then make them permanent.
firewalld Zones
Zones in firewalld define sets of rules appropriate for different trust levels. Each network interface or source address can be bound to one zone at a time. Some typical zones include ones for very restricted public networks, for home or work networks with more trust, and for completely trusted environments.
Each zone can have its own configuration of allowed services, open ports, and other settings. When a packet arrives on an interface, the zone associated with that interface determines which rules are applied to that traffic.
New connections can be assigned to the default zone if no other specific mapping applies. The default zone is therefore important for systems that move between networks or add new connections dynamically. Changing the default zone adjusts how firewalld treats all connections that do not have a more specific rule.
Zones can also match traffic based on source addresses, not just interfaces. This is useful if a single interface serves multiple networks with different trust levels. In such a setup, firewalld chooses the most specific matching rule between interface and source definitions.
Managing zones involves listing existing zones, seeing which are active, and modifying which services and ports each zone allows. You can also change which zone an interface belongs to, either temporarily or permanently.
firewalld Services and Ports
Services in firewalld are predefined collections of ports and protocols that represent common network services such as SSH or HTTP. Instead of specifying port numbers manually, you typically allow or block these named services within a particular zone.
Services are defined in XML files under the firewalld configuration directories. Many standard services ship with the distribution, but administrators can create custom service definitions when needed. A custom service might represent an internal application with its own port number or protocol requirements.
Ports can also be managed directly without using named services. This is useful for nonstandard ports that do not correspond to any existing service definition or when you want to open a temporary port quickly for testing.
For each zone, you can add or remove services and ports separately. For example, you might allow SSH and HTTP in a more trusted zone but only allow SSH in a less trusted zone. Ports and services can differ between runtime and permanent configurations, reflecting temporary access changes or experiments.
firewalld also supports rich rules which allow very fine grained matching. These rich rules can combine conditions on source addresses, protocols, ports, logging behavior, and actions. They are more complex but increase flexibility when default zone and service configuration is too limited.
Managing firewalld Configuration
firewalld configuration management involves interaction with runtime and permanent states. Runtime changes take effect immediately and often do not require service restarts. Permanent changes are written to configuration files and are applied automatically when the system reboots or the firewall service restarts.
There is an explicit reload operation that reapplies permanent configuration to the runtime state. This is often used after editing configuration files directly or after a series of permanent changes. Reloading usually preserves established connections, but some complex scenarios may be affected.
Because firewalld is a system service, it is managed with the system’s service manager. Stopping or disabling it is possible, but on a network facing server that is rarely advisable. Instead of turning off the service, it is generally better to adjust rules and zones to achieve the desired access behavior.
Backups of configuration files are important for reproducible setups. firewalld stores both stock and customized zone and service definitions under its configuration directories. Copying these files to a safe location allows quick restoration if an experiment results in an unusable configuration.
firewalld also supports direct configuration mode, where rules are written directly into underlying packet filtering chains through its own interface. This mode is more advanced and is typically used when zone and service abstractions do not provide enough control. When direct configuration is used, care must be taken not to conflict with zone based rules.
Choosing Between UFW and firewalld
Most distributions choose one of these tools as the default. Ubuntu and some other Debian based systems favor UFW, while Fedora, RHEL, and derivatives typically enable firewalld. While it is technically possible to run other tools, using the default one is almost always the simplest approach.
UFW is often preferred when the goal is straightforward inbound filtering on a single machine with minimal complexity. It has concise commands and a clear model of defaults and explicit rules. This suits small servers and personal systems where the administrator wants low cognitive overhead.
firewalld is more suitable when you need multiple trust levels, dynamic adjustment, and integration with other system tools. Its zone concept matches common network architectures such as separating public and private interfaces. Its runtime and permanent distinction supports iterative configuration without requiring system reboots.
In general, using both UFW and firewalld on the same machine is discouraged. Since both tools manage the same underlying packet filtering system, they can conflict and make behavior difficult to predict. When you choose one, disable or uninstall the other from active management.
Never manage the same firewall stack with multiple frontends at the same time.
Important statement:
On a single system, use either UFW or firewalld as your primary firewall management tool, not both.
Practical Considerations
When deploying a firewall on a live system, especially a remote server, careful planning is essential. Before enabling strict filtering, confirm which services must remain reachable and on which interfaces. On a server managed over SSH, ensure SSH is explicitly allowed before you enable the firewall, regardless of whether you use UFW or firewalld.
Testing should include connecting from another system that represents the real client environment. This validates that the firewall rules align with actual traffic, rather than just local assumptions. It is important to test both successful connections and intended denials to confirm that the rules have the expected effect.
Logging is a powerful diagnostic aid but must be balanced against performance and storage. Both UFW and firewalld can log events related to accepted or dropped packets. Logs should be monitored when deploying new rules and periodically afterward, especially if users report connectivity issues.
Over time, firewall configurations tend to accumulate obsolete rules. Periodic review of UFW rules or firewalld zones and services helps maintain clarity. Removing unused exceptions reduces the system’s attack surface and makes future troubleshooting easier.
By understanding the specific models and commands used by UFW and firewalld, you can choose the appropriate tool for your environment and manage your Linux firewall in a predictable and maintainable way.