From owner-cvs-all Wed Mar 21 13:58:46 2001 Delivered-To: cvs-all@freebsd.org Received: from VL-MS-MR002.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 6D5B637B724 for ; Wed, 21 Mar 2001 13:58:39 -0800 (PST) (envelope-from patrick@netzuno.com) Received: from jacuzzi ([24.200.106.26]) by VL-MS-MR002.sc1.videotron.ca (Netscape Messaging Server 4.15) with ESMTP id GAKHEH04.CW7; Wed, 21 Mar 2001 16:37:29 -0500 Received: from cognac (cognac.local.mindstep.com [192.168.10.4]) by jacuzzi (Postfix) with SMTP id 6F3F73DA5; Wed, 21 Mar 2001 16:42:21 -0500 (EST) From: "Patrick Bihan-Faou" To: , Subject: Re: cvs commit: src/sys/netinet ip_fw.c Date: Wed, 21 Mar 2001 16:38:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Paul, > The problem is that it's difficult to flush the rules of a remote server > because you'll get cut off. What seemed intuitive to me would be to be > able to specify what the default rule was so that rather than it just > being deny or allow all it could be something useful. To be useful it > needs to be more than one rule so we're heading towards the idea of > groups as you suggest but a very simple solution is to just protect the > first few rules and treat them as built-in defaults. I did that with > 10-15 lines of code which were easily audited, having minimal impact on > the design of IPFW and zero impact on existing installations. I can completely understand what the reasoning is behind your changes, but rather than treating the first few rules as "static", I would see a better point for treating the LAST few rules as static. Hopefully your ipfw rule set is defined by some sort of script. In such things, even if I know that the default compiled in rule is a deny all, I explicitely specify my own deny all rule to terminate the rule set. In such a setup, having a few rules near the end of the table (after the "normal" deny all rule) and making sure that they are not flushed can be a life saver (been there, done that). The reason why having them near the end is properly more usefull, is because in a normal setup you may want to have other things done before the "allow tcp from any to me 22" that I need to ensure I don't loose access to the box. These things include nat, various anti-spoof rules etc. They should be done before, the new default rule should be used only when everything else is in limbo. Maybe the real configuration setting should be a range: low-high, everything between the 2 values is flushed. Having only the low value is not really useful. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message