pfBlockerNG rule element modification and ordering
-
To begin, pfBlockerNG_devel 2.2.1_2 is awesome. Wow. Thanks.
tl;dr
I would like to see the rule element "Suspension"/White List system work along the lines of the Suricata SID Management interface. An interface is needed to Enable/Disable/Modify (and possibly Drop/Reject?) rule elements, globally as well as individually for each list. I don't know if Rule Ordering makes sense (i.e, Enable/Disable vs. Disable/Enable). Rule elements (i.e., IP's or DNS names) need to be culled from the lists permanently, and globally as well as individually. White Lists don't cut it (in all cases).Details
Certain feeds are naughty. For example, adding RFC 1918 (Private Address Space), Multicast addresses, etc., etc., etc., is just BAD. Blocking possibly necessary system addresses, including multicast addresses, etc., is just NASTY. Adding a WhiteList is not going to fix this issue. These rule elements need to be culled from the list(s), and I mean permanently.Why is it BAD? The number of posts from users who have lost access to their management console is simple testimony to the fact. The problem is largely due (or compounded) by the default behavior of pfBlockerNG to use Floating rules which take action immediately and puts Auto Rules in front of all other rules by default. But, rule ordering is not a solution.
Why is this NASTY? One of the feeds I use includes mDNS multicast address 224.0.0.251. In many environments (e.g., with macOS machines), this has consequences that are not pleasant. I am sure every user has had their grief with some particular rule element or other.
A suggestion has been, "Just put a White List before the offending rule". So, the suggestion is, "Add a rule, right up near the top, on Floating Rules (with immediate action), for ANY -> PRIVATE ADDRESSES? Or ANY -> Multicast?" I don't think so. This is not going to work.
Some of the recommendations suggest changing the Alias list to pfb_ from pfB_. From what I gather, the suggestion is to have a separate Alias from the default, pfB_, tied to the same system file as the original. I am unclear if pfb_ needs to be defined manually or if it exists automatically. It would be helpful if the Aliases page had a copy function. I have been using the prefix 4pfB_ myself until I receive clarification if pfb_ is automatically generated (though not listed under the Aliases page).
Rule Re-ordering is an issue. From what I can understand, IP block lists can use an alternate Alias and forego Automatic Rule generation and subsequent rule reordering (Thank Goodness). DNSBL lists do not appear to be so lucky. The interface suggests either the rule is Enabled (and then automatically added to Floating Rules, or with certain ordering possibilities) or it is added to each Interface rule set (only compounding the issue). Automatic DNSBL rule insertion and subsequent re-ordering need to be completely optional and take advantage of alternate Alias lists.
A couple of feature suggestions for automatic rule insertion: use rule Separators to bind automatic rule insertion to specific places in the rules. (Indeed, one of my pet peeves is that automatic rules re-arrange Separator organization in seemingly random ways.). Another suggestion would be that automatic rule insertion should not re-arrange rule ordering AT ALL (after their initial placement). Subsequent rule updates should update rules IN PLACE. I like the possibility that Separators could be used to bind automatic rule insertion. But, disabling all automatic rule insertion needs to be an option for DNSBL.
I would like to see the Suspension/White List system be improved: it should have its own page and an interface similar to the Suricata SID Management interface (or some simplication of it). White Lists don't work in all circumstances. This issue may be most relevant to IP block lists, given the recurring addition of Private Address spaces (and Multicast) etc. An interface to Enable/Disable/Modify (i.e., ADD/DELETE/MODIFY) rule elements both globally and individually for each list would do wonders. A global list could include presets for (each) Private Address space, (each) Multicast Address range, etc., as well as custom elements. Again, this would modify the lists (including feeds) during updates. White Lists have their usefulness, but actual modification of lists during update is needed.
-
@newyork10023 said in pfBlockerNG rule element modification and ordering:
To begin, pfBlockerNG_devel 2.2.1_2 is awesome. Wow. Thanks.
Thanks!
Certain feeds are naughty. For example, adding RFC 1918 (Private Address Space), Multicast addresses, etc., etc., etc., is just BAD. Blocking possibly necessary system addresses, including multicast addresses, etc., is just NASTY. Adding a WhiteList is not going to fix this issue. These rule elements need to be culled from the list(s), and I mean permanently.
By chance are you using Firehol Level1? That feed contains bogons and should not be used for Outbound blocking. You can also enable "Suppression" which will remove local/loopback addresss.
A couple of feature suggestions for automatic rule insertion: use rule Separators to bind automatic rule insertion to specific places in the rules. (Indeed, one of my pet peeves is that automatic rules re-arrange Separator organization in seemingly random ways.). Another suggestion would be that automatic rule insertion should not re-arrange rule ordering AT ALL (after their initial placement). Subsequent rule updates should update rules IN PLACE. I like the possibility that Separators could be used to bind automatic rule insertion. But, disabling all automatic rule insertion needs to be an option for DNSBL.
Firewall rule separators will be very difficult to implement with pfBlockerNG and auto rules...
