From owner-freebsd-audit Wed Mar 21 1:48:41 2001 Delivered-To: freebsd-audit@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id D99A537B73D for ; Wed, 21 Mar 2001 01:48:38 -0800 (PST) (envelope-from paul@freebsd-services.co.uk) Received: from freebsd-services.co.uk (lobster.originative.co.uk [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id EA7F31D149; Wed, 21 Mar 2001 09:48:37 +0000 (GMT) Message-ID: <3AB8792A.19308025@freebsd-services.co.uk> Date: Wed, 21 Mar 2001 09:49:30 +0000 From: Paul Richards X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Hagan Cc: Mark Murray , freebsd-audit@FreeBSD.ORG Subject: Re: ipfw permanent rules References: <3AB857E7.D4CEBD40@freebsd-services.co.uk> <200103210738.f2L7cof42204@gratis.grondar.za> <3AB85B6F.32E9EE7C@freebsd-services.co.uk> <3AB87590.FA684AE7@colltech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel Hagan wrote: > > > It sets a rule number below which rules will not be flushed. I've been > > using it to install permanent rules, like SSH access from the office to > > remote servers, so I can flush the majority of rules but keep those that > > are essential to allow me to maintain connectivity to the box. > > I'm a little concerned that this overrides the meaning of the rule > numbers. Now they will define what order rules are processed and > whether they can be flushed. Wouldn't it be more orthogonal to add a > flag to each rule (like the log keyword) to mark permanent rules? I > don't know anything about the ipfw code, so maybe this is impractical > (and I'm sure it would require more work), but it sounds worth it to me. The order of rules processing isn't affected unless you enable this feature. If you set the rule number above 0 then after a flush all the presistent rules will be at the front of the chain so in that situation it's possible for the rule order to get changed when you add back flushed rules but if you're using this feature then you're going to have your persistent rules together at the bottom of the number range anyway so the problem shouldn't arise. I looked at making it a per-rule setting but the flags field looks full so it would require extending the struct and modifying the userland parser. That was too much of a change for what I needed but I might take a look at extending the functionality later. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message