RE: Rule lookup strategies (Was: Rationale for BSD (I)PF rule order?)

["Stewart, John" <johns () artesyncp com>]

Mikael wrote:
> I've never worked with this myself, but I've heard people say
> "it works for small configs, but can do unexpected/unwanted things 
>  for large ones".
>
> What'd your thoughts on that be?
>
> I'm thinking along the lines of 
> "do foo to 0.0.0.0/0 -> 10.0.0.2/32, port 80-81",
> "do bar to 0.0.0.0/0 -> 10.0.0.2/31, port 80".
>
> Which one is more specific? There's one IP and two ports
> in the first one, and two IPs and one port in the other one.
> (Or subtitute for various other IP and/or protocol/port
>  combinations for other interesting problems).

Well, as for "foo" and "bar", there are only two actions in Raptor that you can take, pass or drop. So assuming foo is 
pass and bar is drop, we have:

0.0.0.0/0 -> 10.0.0.2/32, port 80-81 -> PASS
0.0.0.0/0 -> 10.0.0.2/31, port 80 ----> DROP

I'm not quite sure what the precedence would be. I'm pretty sure that the network/host would be of higher precedence 
than the services, so in this case because the first rule is more specific in the from/to area, then it would take 
precedence. Because deny is implied, then rule 2 is redundant.

If we reverse the actions:

0.0.0.0/0 -> 10.0.0.2/32, port 80-81 -> DROP
0.0.0.0/0 -> 10.0.0.2/31, port 80 ----> PASS

Then in this case because of implicit deny, then port 81 is redundant here. A preferable rule would be:

0.0.0.0/0 -> 10.0.0.2/32, port 80 ----> DROP
0.0.0.0/0 -> 10.0.0.2/31, port 80 ----> PASS

There is no need to deny something (port 81) which has not been allowed in the first place.

> The reason I'm asking this is because it generally looks like a 
> cool and worthwhile idea, but one I'd like to know more about
> before deciding whether I actually like it or not :)

Well, I'm no Raptor sales droid; I've just used it for many years. I definitely hate some things about it, but the 
rule-matching is not one of them.

Yes, the biggest complaint that it is possible to create ambiguous/conflicting rules. However, in practice, in my 
experience, this just doesn't come up if you've got a clue. If there is ambiguity, then you probably didn't construct 
good rules.

No firewall architecture is going to save the clueless from themselves... except for perhaps a wire cutter.

As for the other complaint, that it doesn't scale well to large rulesets, I can't offer much of an opinion. We're a 
relatively small company, and it works quite well for our purposes. We have 65 rules now; I'm not sure how that 
compares to other sites.

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