Re: Rationale for BSD (I)PF rule order?

["Bill Royds" <Bill () royds net>]

In a "best fit" rule scheme, there may be places where either of two rules
apply equally. The one system that I know implements this, Symantec (Raptor)
Enterprise Firewall, also gives a warning  message when you define the rule,
stating that there are conflicting rules.

 A system that allowed one to enter rules as a decision tree would allow
clear rules with relative ease of entering new ones without ambiguity and
possibility of mismatch. A first fit would be a subset of this, as would a
last fit (both we tree depth equal to number of rules).

----- Original Message ----- 
From: "Holger Kipp" <Holger.Kipp () alogis com>
To: <barney () databus com>; <Bill () royds net>
Cc: <mikael.olsson () clavister com>; <holger.kipp () alogis com>;
<volker.tanger () discon de>; <firewall-wizards () honor icsalabs com>
Sent: Saturday, May 10, 2003 9:29 PM
Subject: Re: [fw-wiz] Rationale for BSD (I)PF rule order?


: Barney Wolff (barney () databus com) wrote:
:
: >I am simply amazed at what people have been saying in this thread.
:
: me too.
:
: >Unless the firewall hardware actually has a CAM, rule evaluation is
: >going to be sequential, whether in the order configured or not.
: >Therefore, I for one will never accept a scheme where I have to think
: >hard about what the ruleset will actually do.  I want the simplest,
: >clearest relationship between what I see and what the firewall will do,
: >and that's sequential, first-match.
:
: I'd like to suggest that every sysadmin who creates rulesets (and wants to
: harden them) should in fact think hard about what the ruleset will
actually
: do - no matter what firewall and rule-scheme (s)he is using.
:
: Assume you have 3000+ rules on 12 interfaces and want to add another rule.
: Where do you insert the new rule? You have to find the(*) rule A that is
: less specific(+) and would override your rule B and add the new rule B
before
: that one. But if rule B is not a real subset of rule A? then it might
affect
: other rules further down. Happy hunting ;-) (that about simplest and
clearest)
: (*) might be several.
: (+) for sake of simplicity lets assume we know what 'less specific' means.
:
: I prefer a mixture of a) building a tree with appropriate rules which
: means I can control the flow of rule evaluation b) using "quick"
: where I think it is necessary and c) keep local and global complexity of
: the ruleset low.
:
: OK, that's what I like about ipf. If you dislike it, use something else
;-)
:
: Regards,
: Holger Kipp

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards