On 5/4/05, Nick Holland <[EMAIL PROTECTED]> wrote: > Jonathan Camenisch wrote: > > This is sort of an academic question, I guess. Hopefully, this is an > > ok place to post it. > > > > Just wondering...it seems that most rule examples start out with > > "block in all/block out all", wouldn't it more efficient to put "block > > all" at the end of the rules and use "quick" to pass packets? That > > would be one less rule that gets parsed. > > Lopping off one rule doesn't matter in any real way. It will never be > the difference between a "too slow" system and a "fast enough" system. > It will never cause more work to be done in your office. It will never > be felt. It is unlikely to even be measured. (Insert Gentoo joke > here). This is a place where a human error will cost much more than any > savings of one rule. PF is plenty fast that for most apps, readability > should take precidence over "efficiency", especially an efficiency that > Just Doesn't Matter. > > The default of PF is to "pass all". > If you wish to have a tight firewall, you generally want to have a > "block all" default. Say it. Get it over with. Now, start passing the > stuff you want to pass, and only that stuff. I suspect more people will > find the results more "readable" that way. > > Your strategy mandates a "quick" on every pass rule. That may not be > desired; if you mandate that "every rule must include a 'quick'", you > cripple some of PF's flexibility. If that was desired, the "quick" > would be implied, and PF would be a "First matching rule wins", rather > than "Last matching rule wins" system. You can probably accomplish most > tasks either way, but PF gives you both. Plus, if you happen to forget > one of those "quick"s, you might spend a lot of time looking for the > problem... > > Nick. >
Thanks, everyone, for your thoughts. I think I'm seeing that the "Last matching rule wins" philosophy is something I haven't totally gotten used to yet. Since the quick option is there, it sort of gives you two ways to prioritize rules - and I suppose I haven't learned the advantage of that. I will say one word in my own defense - even if it has no practical point (since I intend to try to do things in a standard "pf way"). It really seems less readable to me to mix quick and non-quick rules. When there's a mixture, you have to read and comprehend a non-linear sequence. But with the way that pf works, I wouldn't want to throw away quick altogether, just because I don't want pf reading the whole file for every packet (well, minus skipped rules). E.g., if I want to pass everything out my firewall to ports >1024 except port 8080, I'd have to write two rules. I could write it two different orders: pass ... to port > 1024 ... block ... quick ... to port 8080 ... (or not quick, I suppose) or block ... quick ... to port 8080 ... pass ... quick ... to port > 1024 ... To me the second one seems more readable if most of my rules use quick, and thus the first matching rule usually wins. Or maybe I shouldn't be _usually_ using quick? In that case, it seems like it would be tricky, in terms of readability, to use it at all. I'm trying to think of a time when there's an advantage to mixing the order. Except maybe in the sense that many of you mention - that setting your default at the top is sort of like getting it out of the way before you get into writing all the "interesting" rules. ..
