On Wed, Aug 07, 2013 at 10:34 +0200, Henning Brauer wrote: > * Maxim Khitrov <[email protected]> [2013-08-06 19:08]: > > On Thu, Aug 1, 2013 at 8:23 AM, Henning Brauer > > <[email protected]> wrote: > > > * Maxim Khitrov <[email protected]> [2013-08-01 13:50]: > > >> On Thu, Aug 1, 2013 at 4:44 AM, Stuart Henderson <[email protected]> > > >> wrote: > > >> > On 2013/07/31 09:04, Maxim Khitrov wrote: > > >> >> On Wed, Jul 31, 2013 at 3:53 AM, Stuart Henderson <[email protected]> > > >> >> wrote: > > >> >> > On 2013/07/30 14:41, Maxim Khitrov wrote: > > >> >> >> I expected a "match quick ..." rule in pf.conf to terminate ruleset > > >> >> >> evaluation without changing the pass/block state. > > >> >> > > > >> >> > "match quick" seems like a config error to me, what use would it > > >> >> > have? > > >> >> > maybe it should just be rejected? > > >> >> > > >> >> I think it's nice way of preventing errors. It gives you a way of > > >> >> applying the default block rule, unless something else was matched, > > >> > > > >> > The default rule in PF is not block, it's "pass flags any no state" > > >> > which is > > >> > likely to trip people up if they accidentally use it with tcp and > > >> > window > > >> > scaling (this default rule is probably responsible for the majority of > > >> > PF configuration mistakes that I've seen..) I'm just a bit leery of > > >> > changing > > >> > syntax in a way which allows this to be hit more easily. > > >> > > >> You're right - I meant the default "block" rule that should be at the > > >> top of every pf.conf. This mechanism is more general than just > > >> applying the default. Whichever pass/block rule was matched last, > > >> that's what gets applied. It's no different than falling off the end > > >> of the ruleset, so I don't think it exacerbates any existing problems. > > > I couldn't agree more. > > So what's the verdict on this? > > your diff should go in. > to commit it, I need oks. guys, you know who you are :) >
i have performed some scrunity tests with anchors and couldn't find a case where it would do the wrong thing. same results from studying the code itself. in other words, i think it's fairly safe to make this change. ok mikeb. > -- > Henning Brauer, [email protected], [email protected] > BS Web Services GmbH, http://bsws.de, Full-Service ISP > Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully > Managed > Henning Brauer Consulting, http://henningbrauer.com/
