Feature #6839
closed
Mechanism to prevent flooding log with entries from blocked packets
Added by Daryl Morse over 7 years ago.
Updated over 4 years ago.
Description
The firewall log is being filled with thousands entries from blocked packets: WAN / 10.197.248.27 / 224.0.0.1 / IGMP.
In this specific case, the packets being blocked are IGMP packets being sent to the broadcast address from a private address by the ISP. They are being blocked by one of the rules to block packets from private networks. I would prefer to only prevent logging these specific entries, but not entries from other packets from private networks.
There is no simple way to do this. It's not possible to create a rule to block the specific packets, but not log them, because the built-in rule is processed first.
Ideally, a feature that allows a user to select an entry in the log and create a rule that prevents it from being logged, without disabling the rule that caused it. There are other ways this could be done, such as providing a setting in the rule that causes it to be processed ahead of built-in rules.
You can create your own Private Networks alias, and then make an ordinary block rule on WAN to block that. Then you can put other more special block rules before (with or without logging or whatever) as you wish.
But maybe a flag could be made available on rules that sets them to be processed before the built-in rules. Then they could be displayed at the top of the rule list, followed by some indication of which built-in rules are active, followed by the ordinary user-specified rules for the interface. The code logic that build the rule set would just scan through first for any rules with the flag set, then add the built-in rules, then scan through again for all the other rules.
Phillip Davis wrote:
You can create your own Private Networks alias, and then make an ordinary block rule on WAN to block that. Then you can put other more special block rules before (with or without logging or whatever) as you wish.
If I was going to create my own rules to replace built-in rules, ideally there would be a mechanism to view or copy the built-in rules to use as a starting point to ensure that the replacement rules don't inadvertently leave any holes.
Phillip Davis wrote:
But maybe a flag could be made available on rules that sets them to be processed before the built-in rules. Then they could be displayed at the top of the rule list, followed by some indication of which built-in rules are active, followed by the ordinary user-specified rules for the interface. The code logic that build the rule set would just scan through first for any rules with the flag set, then add the built-in rules, then scan through again for all the other rules.
The benefit of this approach is it prevents the built-in rules from being inadvertently broken.
- Status changed from New to Closed
The solution is as others stated, disable the default rules (or logging of same) and create your own rules that do what you want.
There are already other open issues to address the concerns here (being able to override standard rules, etc).
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by