Hide Forgot
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
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.
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