Firewalld

Click here to set up this language box

Dynamic firewall with FirewallD

firewalld provides a dynamically managed firewall with support for network/firewall zones to define the trust level of network connections or interfaces. It has support for IPv4, IPv6 firewall settings and for ethernet bridges and has a separation of runtime and persistent configuration options. It also supports an interface for services or applications to add firewall rules directly.

The former firewall model with system-config-firewall/lokkit was static and every change required a complete firewall restart. This included also to unload the firewall netfilter kernel modules and to load the modules that are needed for the new configuration. The unload of the modules was breaking stateful firewalling and established connections.

The firewall daemon on the other hand manages the firewall dynamically and applies changes without restarting the whole firewall. Therefore there is no need to reload all firewall kernel modules. But using a firewall daemon requires that all firewall modifications are done with that daemon to make sure that the state in the daemon and the firewall in kernel are in sync. The firewall daemon can not parse firewall rules added by the ip*tables and ebtables command line tools.

The daemon provides information about the current active firewall settings via D-BUS and also accepts changes via D-BUS using PolicyKit authentication methods.

The Daemon

Applications, daemons and the user can request to enable a firewall feature over D-BUS. A feature could either be one of the predefined firewall features like services, port and protocol combinations, port/packet forwarding, masquerading or icmp blocking. The feature can be enabled for a certain amount of time or can be disabled by again.

With the so called direct interface other services (like for example libvirt) are able to add own rules using iptables arguments and parameters.

The netfilter firewall helpers, that are for example used for amanda, ftp, samba and tftp services, are also handled by the daemon as long as they are part of a predefined service. Loading of additional helpers is not part of the current interface. For some of the helpers onloading is only possible after all connections that are handled by the module are closed. Therefore connection tracking information is important here and needs to get into account.

Static Firewall (system-config-firewall/lokkit)

The actual static firewall model with system-config-firewall and lokkit will still be available and usable, but not at the same time as the daemon is running. The user or admin can decide which firewall solution should be used. By enabling the corresponding services.

Planned is to add a selector for the firewall solution to be used at install time or in first boot. The configuration of the other solution will stay intact and can be enabled simply by switching to the other model.

The firewall daemon is independent to system-config-firewall, but should not be used at the same time.

What is a zone?

A network zone defines the level of trust for network connections. This is a one to many relation, which means that a connection can only be part of one zone, but a zone can be used for many network connections.

Most zones are mutable, but there are also immutable zones. Immutable zones are not customizable and there is no way to overload them.

The zone defines the firewall features that are enabled in this zone:

Predefined services

A service is a combination of port and/or protocol entries. Optionally netfilter helper modules can be added and also a IPv4 and IPv6 destination address.

Ports and protocols

Definition of tcp or udp ports, where ports can be a single port or a port range.

ICMP blocks

Selected Internet Control Message Protocol (ICMP) messages. These messages are either information requests or created as replys to information requests or in error conditions.

Masquerading

The addresses of a private network a mapped to and hidden behind a public IP address. This is a form of address translation.

Forward ports

A port is either mapped to another port and/or to another host.

Which zones are available?

These are the zones provided by firewalld sorted according to the default trust level of the zones from untrusted to trusted:

drop (immutable)

Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.

block (immutable)

Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated within this system are possible.

public

For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

external

For use on external networks with masquerading enabled especially for routers. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

dmz

For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only selected incoming connections are accepted.

work

For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

home

For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

internal

For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.

trusted (immutable)

All network connections are accepted.

Which zone should be used?

A public WIFI network connection for example should be mainly untrusted, a wired home network connection should be fairly trusted. Select the zone that best matches the network you are using.

How to configure or add zones?

To configure or add zones you can either use one of the firewalld interfaces to handle and change the configuration: These are the graphical configuration tool firewall-config, the command line tool firewall-cmd or the D-BUS interface. Or you can create or copy a zone file in one of the configuration directories. /etc/firewalld/zones is used for default and fallback configurations and @PREFIX@/lib/firewalld/zones is used for user created and customized configuration files.

How to set or change a zone for a connection

The zone is stored into the ifcfg of the connection with the ZONE= option. If the option is missing or empty, the default zone set in firewalld is used.

If the connection is controlled by NetworkManager, you can also use nm-connection-editor to change the zone.

Working with firewalld

To enable or disable firewall features in zones, you can either use the grahical configuration tool firewall-config or the command line client firewall-cmd

Using firewall-cmd

The command line client firewall-cmd supports all firewall features. For status and query modes, there is no output, but the command returns the state.

• Get the status of firewalld

 firewall-cmd --state

This returns the status of firewalld, there is no output. To get a visual state use:

 firewall-cmd --state && echo "Running" || echo "Not running"

• Reload the firewall without loosing state information:

 firewall-cmd --reload

If you are using --complete-reload instead, the state information will be lost. This option should only be used in case of severe firewall problems for example if there are state information problems that no connection can be established but the firewall rules are correct.

• Get a list of all supported zones

 firewall-cmd --get-zones

This command prints a space separated list.

• Get the default zone set for network connections

 firewall-cmd --get-default-zone

• Set the default zone

 firewall-cmd --set-default-zone=<zone>

All interfaces that are located in the default zone will be pushed in the new default zone, that defines the limitations for new external initiated connection attempts. Active connections are not affected.

• Get active zones

 firewall-cmd --get-active-zones

The command prints the interfaces that are set to part of a zone in this form:

 <zone1>: <interface1> <interface2> ..
 <zone2>: <interface3> ..

• Enable panic mode to block all network traffic in case of emergency

 firewall-cmd --enable-panic

• Disable panic mode

 firewall-cmd --disable-panic

• Query panic mode

 firewall-cmd --query-panic

This returns the state of the panic mode, there is no output. To get a visual state use

 firewall-cmd --query-panic && echo "On" || echo "Off"

The current firewalld features

D-BUS Interface

The D-BUS interface gives information about the firewall state and makes it possible to enable, disable and query firewall settings.

Zones

A network or firewall zone defines the trust level of the interface used for a connection. There are several pre-defined zones provided by firewalld. Zone configuration options and generic file information are described in the firewalld.zone(5) man page.

Services

A service can be a list of local ports and destinations and additionally also a list of firewall helper modules automatically loaded if a service is enabled. The use of predefined services makes it easier for the user to enable and disable access to a service. Service configuration options and generic file information are described in the firewalld.service(5) man page.

ICMP types

The Internet Control Message Protocol (ICMP) is used to exchange information and also error messages in the Internet Protocol (IP). ICMP types can be used in firewalld to limit the exchange of these messages. ICMP type configuration options and generic file information are described in the firewalld.icmptype(5) man page.

Direct interface

The direct interface is mainly used by services or applications to add specific firewall rules. The rules are not persistent and need to get applied after receiving the start, restart or reload message from firewalld using D-BUS.

Runtime configuration

The runtime configuration is not persistent and will only be restored for a reload. After restart or stop of the service or a system reboot, these options will be gone.

Persistent configuration

The persistent configuration is stored in config files and will be restored with every machine boot or service reload or restart.

Tray Applet

The tray applet firewall-applet visualizes the firewall state and also problems with the firewall for the user. It can also be used to configure settings by calling firewall-config.

Graphical Configuration Tool

The configuration tool firewall-config is the main configuration tool for the firewall daemon. It supports all features of the firewall besides the direct interface, this is handled by the service/application that added the rules.

Command Line client

firewall-cmd provides (most of) the configuration features of the graphical tool for the command line.

Support for ebtables

ebtables support is needed to fullfill all needs of the libvirt daemon and to prevent access problems between ip*tables and ebtables on kernel netfilter level. All these commands are accessing the same structures and therefore they should not be used at the same time.

Default/Fallback configuration in /usr/lib/firewalld

This directory contains the default and fallback configuration provided by firewalld for icmptypes, services and zones. The files provided with the firewalld package should not get changed and the changes are gone with an update of the firewalld package. Additional icmptypes, services and zones can be provided with packages or by creating files.

System configuration settings in /etc/firewalld

The system or user configuration stored here is either created by the system administrator or by customization with the configuration interface of firewalld or by hand. The files will overload the default configuration files.

To manually change settings of pre-defined icmptypes, zones or services, copy the file from the default configuration directory to the corresponding directory in the system configuration directory and change it accordingly.

It is not possible to overload immutable zones, because these may not get changed. If you are loading the defaults for a zone that has a default or fallback file, the file in /etc/firewalld will be renamed to <file>.old and the fallback will be used again.

Planned and Proposed Features

Firewall Abstraction Model

Adding an abstraction layer on top of ip*tables and ebtables firewall rules makes adding rules simple and more intuitive. The abstraction layer needs to be powerful, but also simple, which makes this not an easy task. A firewall language has to gen invented for this. Firewall rules have a fixed position and querying generic information about access state, access policies for ports and other firewall features is possible.

Support for conntrack

Conntrack is needed to be able to terminate established connections for features that get disabled. For some use cases it might not be good to terminate the connection: Enabling of a firewall service for a limited time to establish a persistent external connection.

User interaction mode

This is a special mode of in the firewall the user or admin can enable. All requests of applications to alter the firewall are directed to the user to get notified and granted or denied. It is possible to set a time limit for the acceptance of a connection and to limit it to hosts, networks or connections. It can be saved to behave the same in the future without notification.

An additional feature of this mode is direct external connection attempts on preselected services or ports to the user with the same features as the application initiated requests. The limitation on services and ports will also limit the amount of requests sent to the user.

User policy support

The administrator can define which users are able to use the User Interaction Mode and can also limit the firewall features, that can be used with it.

Port metadata information (proposed by Lennart Poettering)

To have a port independent metadata information would be good to have. The current model with a static assignment of ports and protocols from /etc/services is not a good solution and is not reflecting current use cases. Ports in applications or services are dynamic and therefore the port itself does not describe the use case.

This metadata information could be used to form simple rules for the firewall. Here are some examples:

 allow external access to file sharing applications or services
 allow external access to music sharing applications or services
 allow external access to all sharing applications or services
 allow external access to torrent file sharing applications or services
 allow external access to http web services

The metadata information here could not only be application specific, but also a group of use cases. For example the "all sharing" group or the "file sharing" group could match all sharing or file sharing applications, for example torrent file sharing. These are examples, therefore it might be that they are not useful.

There are two possible solutions to get metadata information in the firewall:

The first is to add it to netfilter (kernel space). This has the advantage, that it can be used by everyone, but also limits the use. To get user or system specific information into account, all these need to be implemented in kernel space also.

The other one would be to add this to a firewall daemon. These abtract rules could be used together with informations like the trust level of the network connections, the user decision to share with as specific person/host or the hard rule of the administrator to forbid sharing completely.

The second solution would have the advantage that new metadata groups or changes in incorporation of trust levels, user preferences or administrator rules would not require to push a new kernel. Adding these kind of abtract rules to a firewall daemon would make it much more flexible. Even new security levels woule be easy to add without kernel updates.

sysctld

At the moment there are sysctl settings that are not properly applied. This happens if the module providing the setting is not loaded at boot time when rc.sysinit runs or it the module gets reloaded at runtime. Another example is net.ipv4.ip_forward, which is needed for example for specific firewall settings, libvirt and also user/admin changes. If there are two apps or daemons enabling ip_forwarding only if needed, then it could happen that one of them is turning it off again without knowing that there is anotherone, that still needs it tuned on.

The sysctl daemon could solve this by having an internal use count for settings, that will make it possible to turn it off or go to the previous setting again if the requester reverted the request to change it.

Firewall Rules

Netfilter firewalls are always susceptible to rule ordering issues, because a rule does not have a fixed position in a chain. The position can change if other rules are added or removed in a position before that rule.

In the static firewall model a firewall change is recreating a clean and sane firewall setup limited to the features directly supported by system-config-firewall / lokkit. Firewall rules created by other applications are not integrated and s-c-fw / lokkit does not know about them if the customs rules file feature is not in use. Default chains are used and there is no safe way to add and remove rules without interfering with others.

The dynamic model has additional chains for the firewall features. These specific chains are called in a defined ordering and rules added to a chain could not interfere with reject or drop rules in chains that were called before. This makes it possible to have a more sane firewall configuration.

Here are example rules created by the daemon in the filter table with ssh, ipp-client and mdns enabled in the public zone, all other zones have been removed to simplify and shorten the output:

 *filter
 :INPUT ACCEPT [0:0]
 :FORWARD ACCEPT [0:0]
 :OUTPUT ACCEPT [0:0]
 :FORWARD_ZONES - [0:0]
 :FORWARD_direct - [0:0]
 :INPUT_ZONES - [0:0]
 :INPUT_direct - [0:0]
 :IN_ZONE_public - [0:0]
 :IN_ZONE_public_allow - [0:0]
 :IN_ZONE_public_deny - [0:0]
 :OUTPUT_direct - [0:0]
 -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 -A INPUT -i lo -j ACCEPT
 -A INPUT -j INPUT_direct
 -A INPUT -j INPUT_ZONES
 -A INPUT -p icmp -j ACCEPT
 -A INPUT -j REJECT --reject-with icmp-host-prohibited
 -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
 -A FORWARD -i lo -j ACCEPT
 -A FORWARD -j FORWARD_direct
 -A FORWARD -j FORWARD_ZONES
 -A FORWARD -p icmp -j ACCEPT
 -A FORWARD -j REJECT --reject-with icmp-host-prohibited
 -A OUTPUT -j OUTPUT_direct
 -A IN_ZONE_public -j IN_ZONE_public_deny
 -A IN_ZONE_public -j IN_ZONE_public_allow
 -A IN_ZONE_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
 -A IN_ZONE_public_allow -d 224.0.0.251/32 -p udp -m udp --dport 5353 -m conntrack --ctstate NEW -j ACCEPT
 -A IN_ZONE_public_allow -p udp -m udp --dport 631 -m conntrack --ctstate NEW -j ACCEPT

Used is a deny/allow model to have a clear behaviour and at best no rule interferences. Icmp blocks for example will go to the IN_ZONE_public_deny chain if set for the public zone and will be handled before the rules in the IN_ZONE_public_allow chain.

This model makes it more easy to add or remove rules from a specifig block without interfering with accept or drop rules from another block.