Bug 1772208

Summary: firewalld not falling back to interface zone
Product: Red Hat Enterprise Linux 8 Reporter: mcolombo
Component: firewalldAssignee: Eric Garver <egarver>
Status: CLOSED ERRATA QA Contact: Tomas Dolezal <todoleza>
Severity: medium Docs Contact: Marc Muehlfeld <mmuehlfe>
Priority: high    
Version: 8.1CC: ajohn, cutaylor, egarver, huali, kwalker, mabrown, orion, ptalbert, spanjikk, todoleza, toneata
Target Milestone: rcKeywords: Regression, Reopened, ZStream
Target Release: 8.0   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: firewalld-0.8.0-3.el8 Doc Type: Bug Fix
Doc Text:
.A configuration parameter has been added to `firewalld` to disable zone drifting Previously, the `firewalld` service contained an undocumented behavior known as "zone drifting". RHEL 8.0 removed this behavior because it could have a negative security impact. As a consequence, on hosts that used this behavior to configure a catch-all or fallback zone, `firewalld` denied connections that were previously allowed. This update re-adds the zone drifting behavior, but as a configurable feature. As a result, users can now decide to use zone drifting or disable the behavior for a more secure firewall setup. By default, in RHEL 8.2, the new `AllowZoneDrifting` parameter in the `/etc/firewalld/firewalld.conf` file is set to `yes`. Note that, if the parameter is enabled, `firewalld` logs: ---- WARNING: AllowZoneDrifting is enabled. This is considered an insecure configuration option. It will be removed in a future release. Please consider disabling it now. ----
Story Points: ---
Clone Of:
: 1796055 1797546 (view as bug list) Environment:
Last Closed: 2020-04-28 16:51:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1796055, 1797546    

Description mcolombo 2019-11-13 22:04:00 UTC
Description of problem:
Incoming packets do not continue to get processed by the default firewalld zone after going through the source zone. 

Version-Release number of selected component (if applicable):
firewalld-0.7.0-5.el8

How reproducible:
Every time 

Steps to Reproduce:
1.add interface to default firewalld zone 
2.add source address to another zone specifying a specific service to be accepted
3.test incoming packet from the source zone for the a sevice accepted on the default zone

Actual results:
Packet is not processed by default zone

Expected results:
Packet to continue being processed by default zone

Additional info:

Reproducer with firewalld-0.6.3-7.el8:
--------------------------------------

Clients:
========
# hostname; ip a | grep ens3
rhel-76.example.com
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 10.12.213.67/22 brd 10.12.215.255 scope global noprefixroute dynamic ens3

# hostname; ip a | grep eth0
r72_tg3.example.com
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    inet 10.12.214.85/22 brd 10.12.215.255 scope global dynamic eth0

Server:
=======
[root@rhel-80 ~]# uname -r
4.18.0-80.el8.x86_64

[root@rhel-80 ~]# rpm -q firewalld
firewalld-0.6.3-7.el8.noarch

[root@rhel-80 network-scripts]# hostname; ip a | grep ens3
rhel-80.example.com
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 10.12.212.168/22 brd 10.12.215.255 scope global dynamic noprefixroute ens3

SSH (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 10.12.213.67/32
  services: ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources: 
  services: cockpit dhcpv6-client http
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 


Test:
=====
[root@rhel-76 ~]# ssh 10.12.212.168
root.212.168's password: 
Last login: Wed Nov 13 15:19:41 2019 from 10.12.213.67

[root@rhel-80 ~]# ss -tln
State       Recv-Q        Send-Q                Local Address:Port               Peer Address:Port       
LISTEN      0             128                         0.0.0.0:22                      0.0.0.0:*          
LISTEN      0             128                            [::]:22                         [::]:*          
LISTEN      0             128                               *:80                            *:*   

[root@rhel-76 ~]# curl 10.12.212.168:80 | head -1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3985  100  3985    0     0  2016k      0 --:--:-- --:--:-- --:--:-- 3891k
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
[root@rhel-76 ~]# 

     Attempt from another host that is not allowed from the SSH firewall zone. 

[root@r72_tg3 ~]# ssh 10.12.212.168
ssh: connect to host 10.12.212.168 port 22: No route to host

[root@r72_tg3 ~]# curl 10.12.212.168:80 |head -1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3985  100  3985    0     0   218k      0 --:--:-- --:--:-- --:--:--  228k
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">



Reproducer after updating to firewalld-0.7.0-5.el8:
---------------------------------------------------

[root@rhel-80 network-scripts]# yum update firewalld

[root@rhel-80 network-scripts]# firewall-cmd --reload
success
[root@rhel-80 network-scripts]# rpm -q firewalld
firewalld-0.7.0-5.el8.noarch
[root@rhel-80 network-scripts]# 

SSH (active)
  target: default
  icmp-block-inversion: no
  interfaces: 
  sources: 10.12.213.67/32
  services: ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources: 
  services: cockpit dhcpv6-client http
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 



Connection to 10.12.212.168 closed.
[root@rhel-76 ~]# ssh 10.12.212.168
root.212.168's password: 
Last login: Wed Nov 13 15:20:04 2019 from 10.12.213.67
[root@rhel-80 ~]#

[root@rhel-76 ~]# curl 10.12.212.168:80 | head -1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0curl: (7) Failed connect to 10.12.212.168:80; No route to host
[root@rhel-76 ~]# 



[root@r72_tg3 ~]# ssh 10.12.212.168
ssh: connect to host 10.12.212.168 port 22: No route to host


[root@r72_tg3 ~]# curl 10.12.212.168:80 |head -1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3985  100  3985    0     0   219k      0 --:--:-- --:--:-- --:--:--  228k
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Comment 1 Eric Garver 2019-11-13 23:06:38 UTC
This is not a bug. It's by design. In zone based firewalls (e.g. firewalld) packets ingress one and only one zone.

See bug 1713823 and upstream issues; https://github.com/firewalld/firewalld/issues/258, https://github.com/firewalld/firewalld/issues/441, https://github.com/firewalld/firewalld/issues/535.
Upstream documentation: https://firewalld.org/documentation/zone/

To get the desired behavior you'll need to add the necessary services/ports/etc to the source-based zone.

Comment 24 Eric Garver 2020-01-14 00:11:46 UTC
*** Bug 1790681 has been marked as a duplicate of this bug. ***

Comment 25 Orion Poplawski 2020-01-14 00:24:04 UTC
What's the status of this then?  Is it a regression or expected behavior?  It's certainly a notable change which doesn't appear to be in the 8.1 release notes.

Comment 26 Eric Garver 2020-01-16 20:22:03 UTC
(In reply to Orion Poplawski from comment #25)
> What's the status of this then?  Is it a regression or expected behavior? 
> It's certainly a notable change which doesn't appear to be in the 8.1
> release notes.

It's still currently being investigated and discussed.

Comment 35 Eric Garver 2020-01-30 22:25:38 UTC
Upstream commits:

bca4e6af91fc ("test: verify AllowZoneDrifting=yes")
1f7b5ffcd40d ("feat: ipXtables: support AllowZoneDrifting=yes")
517a061c5886 ("feat: nftables: support AllowZoneDrifting=yes")
afadd377b09d ("feat: AllowZoneDrifting config option")

Comment 38 Eric Garver 2020-01-31 14:00:22 UTC
Upstream blog post:

https://firewalld.org/2020/01/allowzonedrifting

Comment 53 errata-xmlrpc 2020-04-28 16:51:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:1836