RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1402932 - set-log-denied LOG rule is non-functional with the 'drop' zone
Summary: set-log-denied LOG rule is non-functional with the 'drop' zone
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: firewalld
Version: 7.3
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: 7.4
Assignee: Thomas Woerner
QA Contact: Tomas Dolezal
Mirek Jahoda
URL:
Whiteboard:
Depends On: 1298243
Blocks: 1421205
TreeView+ depends on / blocked
 
Reported: 2016-12-08 16:33 UTC by Patrick Talbert
Modified: 2020-04-15 14:57 UTC (History)
5 users (show)

Fixed In Version: firewalld-0.4.3.2-8.1.el7_3.2
Doc Type: Bug Fix
Doc Text:
Previously, when the drop or block zone was used, firewalld placed the logging rules for the LogDenied option after the final DROP or REJECT rule. Consequently, packets matching the DROP or REJECT rules were not logged. The placement of the logging rules has been fixed, and the log rules now works correctly.
Clone Of:
: 1421205 (view as bug list)
Environment:
Last Closed: 2017-08-01 16:22:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2800521 0 None None None 2016-12-08 17:09:58 UTC
Red Hat Product Errata RHBA-2017:1934 0 normal SHIPPED_LIVE firewalld bug fix and enhancement update 2017-08-01 17:55:15 UTC

Description Patrick Talbert 2016-12-08 16:33:09 UTC
Description of problem:

If the new --set-log-denied option is used when the 'drop' zone is being utilized, the LOG rule inserted into the IN_drop chain is *after* the DROP * rule. This means packets never hit the LOG rule.



Version-Release number of selected component (if applicable):
firewalld-0.4.3.2-8.el7.noarch


How reproducible:
Always.


Steps to Reproduce:
1. In RHEL 7.3, put an interface into the 'drop' zone and set the set-log-denied option:

[root@r73 ~]# firewall-cmd --zone=drop --add-interface=eth0
[root@r73 ~]# firewall-cmd --set-log-denied=all


2. Check the rules in the IN_drop chain:

[root@r73 ~]# iptables -xnL IN_drop --line-numbers -t filter 
Chain IN_drop (1 references)
num  target     prot opt source               destination         
1    IN_drop_log  all  --  0.0.0.0/0            0.0.0.0/0           
2    IN_drop_deny  all  --  0.0.0.0/0            0.0.0.0/0           
3    IN_drop_allow  all  --  0.0.0.0/0            0.0.0.0/0           
4    DROP       all  --  0.0.0.0/0            0.0.0.0/0           
5    LOG        all  --  0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "IN_drop_DROP: "



Actual results:

The LOG rule is below the DROP rule.


Expected results:

The LOG rule should be immediately before the DROP rule.


Additional info:

I "fixed" this by modifying fw_zone.py line 334 rule number from "5" to "4". Is this the best way to handle this?

  38 class FirewallZone(object):
  39     def __init__(self, fw):
  40         self._fw = fw
  41         self._chains = { }
  42         self._zones = { }
.....
 272     def gen_chain_rules(self, zone, create, chains, transaction):
 273         for (table, chain) in chains:
 274             if create:
 275                 if zone in self._chains and  \
 276                    table in self._chains[zone] and \
 277                    chain in self._chains[zone][table]:
 278                     continue
 279             else:
 280                 if zone not in self._chains or \
 281                    table not in self._chains[zone] or \
 282                    chain not in self._chains[zone][table]:
 283                     continue
.....
 323                 if self._fw.get_log_denied() != "off":
 324                     if table == "filter" and \
 325                        chain in [ "INPUT", "FORWARD_IN", "FORWARD_OUT", "OUTPUT" ]:
 326                         if target in [ "REJECT", "%%REJECT%%" ]:
 327                             transaction.add_rule(
 328                                 ipv, [ "-I", _zone, "5", "-t", table,
 329                                        "%%LOGTYPE%%",
 330                                        "-j", "LOG", "--log-prefix",
 331                                        "\"%s_REJECT: \"" % _zone ])
 332                         if target == "DROP":
 333                             transaction.add_rule(
 334                                 ipv, [ "-I", _zone, "4", "-t", table,
 335                                        "%%LOGTYPE%%",
 336                                        "-j", "LOG", "--log-prefix",
 337                                        "\"%s_DROP: \"" % _zone ])


After the fix:

Chain IN_drop (1 references)
num  target     prot opt source               destination         
1    IN_drop_log  all  --  0.0.0.0/0            0.0.0.0/0           
2    IN_drop_deny  all  --  0.0.0.0/0            0.0.0.0/0           
3    IN_drop_allow  all  --  0.0.0.0/0            0.0.0.0/0           
4    LOG        all  --  0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "IN_drop_DROP: "
5    DROP       all  --  0.0.0.0/0            0.0.0.0/0

Comment 1 Patrick Talbert 2016-12-08 17:49:21 UTC
Doh! This is already upstream. I swear I searched for this >:(.



commit 821f04205d505da14587896cf436cbab5dba4dd9
Author: Thomas Woerner <twoerner>
Date:   Fri Sep 16 16:11:53 2016 +0200

    firewall.core.fw_zone: Fix LOG rule placement for LogDenied
    
    The LOG rule needs to be placed exactly before the DROP or REJECT rule and not
    afterwards.

diff --git a/src/firewall/core/fw_zone.py b/src/firewall/core/fw_zone.py
index d72caa5..97596bc 100644
--- a/src/firewall/core/fw_zone.py
+++ b/src/firewall/core/fw_zone.py
@@ -325,13 +325,13 @@ class FirewallZone(object):
                        chain in [ "INPUT", "FORWARD_IN", "FORWARD_OUT", "OUTPUT" ]:
                         if target in [ "REJECT", "%%REJECT%%" ]:
                             transaction.add_rule(
-                                ipv, [ "-I", _zone, "5", "-t", table,
+                                ipv, [ "-I", _zone, "4", "-t", table,
                                        "%%LOGTYPE%%",
                                        "-j", "LOG", "--log-prefix",
                                        "\"%s_REJECT: \"" % _zone ])
                         if target == "DROP":
                             transaction.add_rule(
-                                ipv, [ "-I", _zone, "5", "-t", table,
+                                ipv, [ "-I", _zone, "4", "-t", table,
                                        "%%LOGTYPE%%",
                                        "-j", "LOG", "--log-prefix",
                                        "\"%s_DROP: \"" % _zone ])



I'll file a z-stream request.

Comment 11 errata-xmlrpc 2017-08-01 16:22:56 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/RHBA-2017:1934


Note You need to log in before you can comment on or make changes to this bug.