Changes in firewalld related to Zone Drifting

Disclaimer: Links contained herein to external website(s) are provided for convenience only. Red Hat has not reviewed the links and is not responsible for the content or its availability. The inclusion of any link to an external website does not imply endorsement by Red Hat of the website or their entities, products or services. You agree that Red Hat is not responsible or liable for any loss or expenses that may result due to your use of (or reliance on) the external site or content.

Table of Contents

• Overview
• What is Zone Drifting
• The AllowZoneDrifting configuration option
• Evaluating and Disabling AllowZoneDrifting

Overview

Previous revisions of the firewalld daemon included an undocumented behaviour now known as Zone Drifting. This article discusses the behaviour, the difference in default configuration state between versions of Red Hat Enterprise Linux, and what steps should be taken now in order to avoid future connectivity issues due to Zone Drifting default configuration changes.

What is Zone Drifting

Per the upstream firewalld project documentation ¹:

A user may configure a source-based zoneFoo - a zone to which you’ve added sources via --add-source. If zoneFoo uses a --set-target of default, then the packets will be allowed to ingress a second interface-based zone. This includes the catch-all default zone.

Due to the possibility that existing Red Hat Enterprise Linux installations are relying on the zone drift behaviour above, a new configuration option named AllowZoneDrifting has been introduced.

The AllowZoneDrifting configuration option

With the addition of the AllowZoneDrifting option, and the ability to enable or disable this functionality, the default state has been implemented in the following:

• Red Hat Enterprise Linux 7 - Default yes (enabled)
• Red Hat Enterprise Linux 8 - Default yes (enabled)
• Red Hat Enterprise Linux 9 - Not supported/ignored (disabled)
• Upstream versions - Not supported/ignored (disabled)

# awk '/AllowZoneDrifting/,/^$/' /etc/firewalld/firewalld.conf 
# AllowZoneDrifting
# Older versions of firewalld had undocumented behavior known as "zone
# drifting". This allowed packets to ingress multiple zones - this is a
# violation of zone based firewalls. However, some users rely on this behavior
# to have a "catch-all" zone, e.g. the default zone. You can enable this if you
# desire such behavior. It's disabled by default for security reasons.
# Note: If "yes" packets will only drift from source based zones to interface
# based zones (including the default zone). Packets never drift from interface
# based zones to other interfaces based zones (including the default zone).
# Possible values; "yes", "no". Defaults to "yes".
AllowZoneDrifting=yes

With the configuration option enabled, the following message will be visible in the system logs:

firewalld[<pid>]: WARNING: AllowZoneDrifting is enabled. This is considered an insecure configuration option. It will be removed in a future release. Please consider disabling it now.

Evaluating and Disabling AllowZoneDrifting

Per the above instruction, it is recommended to evaluate the systems firewall configuration, and verify if the current system configuration requires the configuration.

To verify that the configuration option is not necessary, review the firewall configuration to ensure that a specific interface or source IP range is associated with a particular Zone which includes all necessary rules.

In the example below, the previous zone drifting behavior is being used to allow access from a particular IP range for the http service, and relying on the AllowZoneDrifting configuration option to allow ssh access for all traffic that comes in on the ens5 interface. The expectation is that if ssh traffic is received from 192.168.0.1/24, it will still be allowed as the webserver access is going to be checked first, but then the ens5 interface zone rules will be checked as Zone Drifting takes place.

[root@firewalld-example ~]# ip a s ens5
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:45:68:91 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.253/24 brd 192.168.122.255 scope global dynamic noprefixroute ens5
       valid_lft 3394sec preferred_lft 3394sec
    inet6 fe80::c75a:e259:b03:a6a8/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

[root@firewalld-example ~]# firewall-cmd --zone public --list-all; firewall-cmd --zone webserver --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens5
  sources: 
  services: cockpit dhcpv6-client ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	
webserver (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 192.168.0.1/24
  services: http
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
	

To correct the above, it would be necessary to add all services to the webserver zone prior to changing the AllowZoneDrifting configuration to a disabled state.

[root@firewalld-example ~]# firewall-cmd --permanent --zone webserver --add-service ssh
success

[root@firewalld-example ~]# firewall-cmd --reload
success

[root@firewalld-example ~]# firewall-cmd --zone webserver --list-all
webserver (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 192.168.0.1/24
  services: http ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules:

This would retain the desired ssh connectivity for the webserver zone, while not relying on both the webserver and public zones being used.