* 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. -- 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/
