pfsense-rule-order: script to keep firewall rules in the right order automatically
-
@ngf said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
pfSense always adds new rules to the bottom of the list. Every time you add one and forget to drag it to the right position, your security policy silently breaks.
Good policy, if applied, can't be broken (it wouldn't be good to start with).
Let me explain with my 'policy' WAN rules :
You see the last two rules ? These are the final 'block all' rules, separated for IPv6 and IPv4.
And yes, these two rules are the same as the 'hidden' default behavior : block all.So, if you wanted to add a new WAN pass rule, it would be inserted at the bottom, being completely inoffensive. As soon as you see it, you have to drag it to to correct place, and save. Forgetting to do so won't get you fired. Policies won't get broken
@ngf said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
Tested on pfSense CE 2.7.2.
Now you are breaking one of the most important security rules. 2.7.2 was good, and now 'ancient'.
-
@Gertjan that is actually a good policy.. And a very valid reason to have extra block rule there at the end vs just the hidden last rule. Nice..
-
Ditto for any LAN interfaces on which outbound filtering is performed. Plus it adds an easy logging 'toggle' for troubleshooting.
-
@tinfoilmatt said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
Ditto for any LAN interfaces ..
Initially, I listed that one as well. But I spotted something strange, so I withdrew it.
So here it is :
After years of rule building ( I was in the past also a fan of "every packet needs its own rule", but then I found the cure and live was good again) I found rule number 3 and 4.
I added a final block all rule, but this one could never match, as the perfect rules 3 and 4 exist.
Still : rule 5 matches ones in a while 'something'. After a 'everything' there shouldn't be a 'something'.
Right ? -
Whatever it's catching, I agree, is worth filtering.
-
The actual issue I ran into was pfBlockerNG's cron job moving my "Block IoT" rule below some Allow rules every hour.
it was already in the right place, pfBlockerNG just kept pushing it down.
That's what the script is for.Regarding my version, yes, i know. i'm in the process of replacing the pfsense box.
-
There are package settings which address auto-added rule ordering. Do those not cover your situation?
-
@tinfoilmatt said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
There are package settings which address auto-added rule ordering. Do those not cover your situation?
I looked at the pfBlockerNG rule order settings but they control where pfBlockerNG places its own auto rules relative to manual ones, not the order of manual rules themselves.
my issue was specifically manual rules getting reordered relative to each other, so those settings didn't help in my case. -
my issue was specifically manual rules getting reordered relative to each other
This wouldn't be caused by pfBlockerNG's cron job. The order of non-pfBlockerNG auto-added rules (i.e., 'manual rules') could only be changed manually.
What do you have for that package setting—"
Firewall > pfBlockerNG > IP > IP Interface/Rules Configuration > Firewall 'Auto' Rule Order"? -
@tinfoilmatt said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
Firewall 'Auto' Rule Order
-
Interesting. So those last two settings in the drop-down can and do affect 'manual rule' ordering.
So then why not use the default setting which leaves "All other rules" unaffected by pfBlockerNG?
-
@tinfoilmatt I was not aware that this setting also affects manual rule ordering.
i will change back to the default and disable the script temporarily to see if that alone solves the problem.
thank you very much. -
Additionally (and with the default setting there)—if for whatever reason you need a pass rule above pfBlockerNG's auto-added block rules, then the way to do that would be by way of the "Permit" feed group action options (i.e., actions "
Permit Inbound" for WAN interface/s, "Permit Outbound" for LAN interface/s, or "Permit Both"). This would be the cleanest and most automated way to "whitelist" any pfBlockerNG false positives. -
@tinfoilmatt said in pfsense-rule-order: script to keep firewall rules in the right order automatically:
Additionally (and with the default setting there)—if for whatever reason you need a pass rule above pfBlockerNG's auto-added block rules, then the way to do that would be by way of the "Permit" feed group action options (i.e., actions "Permit Inbound" for WAN interface/s, "Permit Outbound" for LAN interface/s, or "Permit Both"). This would be the cleanest and most automated way to "whitelist" any pfBlockerNG false positives.
Thanks, I'll check with the default setting.
If that solves the reordering problem, the script is still useful as a general safety net for rule ordering, but the main reason here was clearly misconfiguration on my part. -
At one point, I would've spent a lot of time parsing that blue infoblock in my own mind. I'm certain there are good use cases for the non-default options. But it either never occured to me, or I had forgotten that those last two do affect non-pfBlockerNG rule ordering. Thanks for the refresher.
By the way, I like what you're doing with your blocklist-manager tool.
-
@tinfoilmatt same here, i had no idea that setting affected manual rules until now, good to know.
thanks for the kind words on blocklist-manager, glad it's useful! -
A newer pfSense will also give you access to the latest version pfBlockerng.
Your issue might auto solve itself.
