Rule order bug?
-
@viragomann said in Rule order bug?:
Basically, why not? It would enhance security in my opinion.
How? If you do not allow the traffic, then the default deny will block it. What is the point of using any in block, when they are blocked anyway.. The habit should be to always use the source network in your rules. explicit rules are best, even just just the admin looking at the rules. Any or cidrs should be limited to where they are actually needed, ie a transit network where there would be downstream networks to be allowed.. If you were putting rules on a transit, I would create an alias or use a cider that covered my downstream networks that would be using this transit network.. So again if your allows are only allowing your networks be it directly attached or your downstream.. using any as source for deny don't really do anything, other than make your rules inconsistent when looking at them.
if you wanted to log specific traffic, ok - if you were not logging the default deny and you wanted to use the rule to catch stuff in your logs for misconfiguration of devices on the network, maybe..
I see no point in created block rules with any as source, when it makes no sense to do so. I just makes the rules inconsistent.. Sure it works and all, I just don't see the point. And it doesn't make it any more secure..
If you would provide an example scenario where it would make it "more" secure - I am all ears..
So for example here is example set of locked down network rules.
How would changing my rejects there to an any for source in any way enhance security?
if some source other than test subnets was inbound into this network, it would be denied by the default deny anyway. What would be the point in using any in my reject?
-
@johnpoz
Of course, there is all correct with your rule set. :-)How? If you do not allow the traffic, then the default deny will block it.
The point is, the TO has an allow any-to-any rule, but has the block rules restricted to the subnet.
-
@viragomann yeah the OP rules lack clarity that is for sure.. if your going to use any on your source for your allow, makes no sense to use a specific source in your deny.
Unless you had no control over what the downstream networks were using your transit. And you wanted to block a specific source network, etc. But then again all of those blocks after an any any allow are never going to be evaluated anyway.
There are many different ways to create rules that "work" but my question was to your statement to always use any in blocks.
It's recommended to enhance security to limit the source in pass rules to the respective subnet, but use any in block rules.
I am not understanding the point to that statement.
Good habits are to always be as explicit as possible in your rules.. I would never suggest an any any anything on even on a transit allow.. You should create an alias or use a cider that allows just your downstream networks using the transit.
-
Please keep replys on-topic, and discuss other issues in pm, or make a new topic. Thanks.
-
I updated the firewall to the latest version
From 23.05.1-RELEASE (amd64)
To 23.09.1-RELEASE (amd64)After i did that, and rebooted. The rules ware re-aranged wrong once again.
But then i aranged them correctly, saved and applyed. And then it seems to work now. As well in the config (thanks for that suggestion @SteveITS )
-
@fero1233 said in Rule order bug?:
From 23.05.1-RELEASE (amd64)
To 23.09.1-RELEASE (amd64)Possibly:
https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#rules-nat
"Fixed: Changes in Ethernet ruleset can lead to incorrect rule and separator order #14705"
-> https://redmine.pfsense.org/issues/14705 -
@SteveITS said in Rule order bug?:
Changes in Ethernet ruleset
@fero1233 were you using "ethernet" rules - do you even have it enabled?
-
I checked the rules today, and now the rules are ordered wrong again. All the "block" are pushed to the buttom, and the allow is on top again.
I created the RFC yesterday as well, as recommended. And added it above the "Any any" rule, and it seems after a while yesterday (and if i looked in the config) that it saved the order. But this morning, it was all re-arranged again.
Are there any other/better way to achive this setup?
-
@fero1233 said in Rule order bug?:
But this morning, it was all re-arranged again.
have a look at the "config.xml" file.
There is a section that start with :
From then on, for every interface (WAN is called WAN, LAN is called LAN, the second LAN is called opt1, etc), in order ( ! ), you rules are listed as they should list in the GUI, and way more important, in the order the firewall rules are listed in 'pf'.
Having a last "pass all" rule, and then it gets listed at the top, that's a security issue (for me).
So : question : is the order in the config.xml also changed ?
If so, that would explain the miss ordering.
The question now becomes : who/what is saving the config, and what impacts the the firewall rules to be ordered differently ?What pfSense packages do you have installed ?
-
In config, it is also wrong order today. It was correct yesterday just after update/reboot/edit/save/apply
But i found this in config:
<revision>
<time>1707220801</time>
<description><![CDATA[(system): pfBlockerNG: saving DNSBL changes]]></description>
<username><![CDATA[(system)]]></username>And i am using pfblocker. So wondering if it is pfblocker, that changes the firewall(?) I might wanna try disable it.
Other plugins
-
@fero1233 said in Rule order bug?:
And i am using pfblocker. So wondering if it is pfblocker, that changes the firewall(?) I might wanna try disable it.
pfBlockerNG creates rules and rearrange the order on each update according due its settings. That's why I asked, if your have manually created the rules in my second question.
-
@viragomann said in Rule order bug?:
That's why I asked, if your have manually created the rules
Yes, on this interface all rules are created manually. There are no pfblocker rules at all, on this interface.
-
@fero1233 IIRC pfBlocker logs a config change at every cron interval. Is that when the reordering happens? Disable/reschedule its update to double check.
-
@SteveITS said in Rule order bug?:
Disable/reschedule its update to double check
I have completely disabled pfblocker for now, to test.
Will let it run like this, for a day or so. And if it works, i will try to look in to, if it is posible to disable update on that specific interface. -
@fero1233 said in Rule order bug?:
I have completely disabled pfblocker for now, to test.
Will let it run like this, for a day or so. And if it works, i will try to look in to, if it is posible to disable update on that specific interface.One thing we cannot see as you cropped the image that way is if that allow any rule is the default allow any from the LAN interface or if it's one you created yourself.
So another thing you can try would be to actually create another "pass any any" rule with a custom description so you know which one is which. Then move that below the Blocks and check if only the default/old allow is getting pushed up or if the blocks are actually pushed down to the bottom.Rule order switching is a thing I've only ever seen with pfBlocker moving rules to the top/bottom when creating automatic rules, but normally it only touches rules with "pfB_xy" aliases in them. So that would be weird. Also one thing you could check is the "Backup & Restore" / Config History Tab in case something is rolling back your configuration because of an error or something (or if someone/-thing commits a new config) - that should show who/what changes the config and why.
Cheers
-
@JeGr said in Rule order bug?:
One thing we cannot see as you cropped the image that way
There is nothing else.
This is the full image, after using RFC rule instead
So i re-enabled pfblocker again, and then removed "Guest" interface from "outbound Firewall Rules" in pfblocker
,as i really only need pfblocker on wan interface - and then it seems to be staying in order.
So for future refrence: pfblocker is the problem, and the solution is to remove that specific interface from "outbound firewall rules" in pfblocker :)
-
@fero1233 Did you change pfB off the default option? see:
Edit: if I ever don't want the default "block on top" I create lists as Alias Native which then allows me to create my own rules however I want.
There's not a default allow any rule on networks aside from LAN.
-
@fero1233 said in Rule order bug?:
So for future refrence: pfblocker is the problem, and the solution is to remove that specific interface from "outbound firewall rules" in pfblocker :)
Or even better: Don't use automatic rules at all, as the options are quite limited with the moving around of rules.
Just set the IP Lists to "Alias Deny" or "Permit" etc. instead of "Block Deny" and just create your own rules with the pfB_xy Aliases to reject or block or allow traffic as needed. Especially when having larger or more complex rulesets, that's definetly necessary.
Cheers
