From owner-freebsd-ipfw Wed Mar 21 23:20:58 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id BFB7837B71C for ; Wed, 21 Mar 2001 23:20:29 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id JAA27797 for ; Thu, 22 Mar 2001 09:20:09 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: Subject: RE: cvs commit: src/sys/netinet ip_fw.c Date: Thu, 22 Mar 2001 09:20:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010321124416.A57754@sunbay.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Gents, If I may throw in my 2c worth - from the point of view of a user (I'd love to be a contributor, but will need to learn some C first ;-) I think the idea of being able to 'pin' some rules to survive a flush is excellent. The default rule (# 65535) behaves somewhat like that already. I guess it would be nice to be able to do something like: ------- ipfw -P add 1000 allow udp from any to any 53 # -P: permanent ipfw add 1100 allow tcp from 10.x.x.x to any 80 ------- and then when you wish to delete the fancy rules but keep the base system running you could do: ------- ipfw delete all ------- Which would delete ALL rules, but NOT those created the -P (permanent) flag. ipfw flush would still flush the lot. One great advantage of this would be that it could be much safer to remotely administer a firewall. If the rules enabling the remote administration are set up with -p then you cannot make the mistake of locking yourself out (well, you could still 'flush' yourself out, but a 'delete all' would be safe!) And, by the way, an option to 'delete #-#' would be nice too. Forgive me if I am sticking my nose where it does not belong - but please understand that I am 100% in support of the concepts of this change. Since I am not in a position to help with writing code at present, let me at least offer my support in testing of these changes if you need that. Patrick O'Reilly. -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Ruslan Ermilov Sent: 21 March 2001 12:44 To: Paul Richards Cc: ipfw@FreeBSD.ORG Subject: Re: cvs commit: src/sys/netinet ip_fw.c On Wed, Mar 21, 2001 at 09:20:21AM +0000, Paul Richards wrote: > Move to developers. > [Redirected to -ipfw, see Committer's Guide for -developers usage rules] > Ruslan Ermilov wrote: > > > > On Wed, Mar 21, 2001 at 12:19:32AM -0800, Paul Richards wrote: > > > paul 2001/03/21 00:19:32 PST > > > > > > Modified files: > > > sys/netinet ip_fw.c > > > Log: > > > Only flush rules that have a rule number above that set by a new > > > sysctl, net.inet.ip.fw.permanent_rules. > > > > > > This allows you to install rules that are persistent across flushes, > > > which is very useful if you want a default set of rules that > > > maintains your access to remote machines while you're reconfiguring > > > the other rules. > > > > > > Reviewed by: Mark Murray > > > > > You asked for a review and committed this while many of us were asleep! > > There's always people asleep in the project. This wasn't a major > architectural change, I just thought it worthwhile for a second pair of > eyes to look it over and Mark's more than qualified for that. > > > What I would really prefer is if we had a flag that marked individual > > rules as permanent. Then flush command would skip these rules, and > > another flush command would ignore this flag. > > I thought about that first, but there's no bits left in the flag. > Really? 0x80000000 is unused. Or, alternatively, you may change the IP_FW_F_COMMAND to 0x0000007F (we are unlikely to have more than 128 actions) and use 0x00000080. I propose the name IP_FW_F_PINNED. > This solution has minimal impact on the implementation whereas changing the > structure is a lot more intrusive. I'd also have had to fix the userland > parser to recognise a token for persistent rules, whereas a sysctl was > also a minimal impact change. > I think you should back this out and reimplement this. I can do this, if you wish. :-) > One thing I did think would be useful though is being able to pass a > range to flush, i.e. ipfw flush 1000-1999. > Nope, the flush command should flush all rules, and probably also check the IP_FW_F_PINNED bit in the flags. If the latter is set, it should delete pinned rules as well. The same should be done for "delete". Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message