From owner-freebsd-security Wed Oct 20 9:51:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from modemcable156.106-200-24.mtl.mc.videotron.net (modemcable156.106-200-24.mtl.mc.videotron.net [24.200.106.156]) by hub.freebsd.org (Postfix) with SMTP id 9C5D514A00 for ; Wed, 20 Oct 1999 09:51:18 -0700 (PDT) (envelope-from patrick@mindstep.com) Received: (qmail 672 invoked from network); 20 Oct 1999 16:51:15 -0000 Received: from unknown (HELO patrak) (192.168.10.25) by jacuzzi.local.mindstep.com with SMTP; 20 Oct 1999 16:51:15 -0000 Message-ID: <002001bf1b1b$52ea0a80$190aa8c0@local.mindstep.com> From: "Patrick Bihan-Faou" To: "Dag-Erling Smorgrav" Cc: "matt" , References: <19991020104749.B17206@relay.ucb.crimea.ua> <009001bf1b08$05ad6040$190aa8c0@local.mindstep.com> Subject: Re: ipfw rule wrong in rc.firewall(?) Date: Wed, 20 Oct 1999 12:51:15 -0400 Organization: MindStep Corporation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, ----- Original Message ----- From: Dag-Erling Smorgrav > "Patrick Bihan-Faou" writes: > > I guess it would add a couple of keywords in the lines of: > > > > ipfw add allow udp from ${oip} to any 53 monitor 10 > > ipfw add allow udp from any to any established > > ipfw add deny udp from any to any > > > > where "monitor" indicates that we want to allow the return data flow, 10 is > > a time-out value (packets must be no more that 10 seconds apart from one > > another). > > Sounds like a good idea, but you may want to do something a little bit > more fancy than just accepting the packets unconditionally. > > If you teach ipfw the notion of temporary rules (add a ttl field to > the rule structure, and remove the rule when the ttl reaches 0), the > effect of a "monitor" rule would simply be to add a temporary rule > with a preselected rule number. That way, you can view and delete > automagic rules manually. You might also want to have those automagic > rules be 'skipto' rules rather than 'allow' rules, so you can do > arbitrarily complex processing of those packets. I was more thinking of something like: ipfw add monitored Here the keyword "monitored" (with a 'd'...) indicates where the packets matching the monitored connection list should be handled.... Sort of like the "established" keyword for TCP... This is why I wrote "established" for the UDP rule. Because in a way that feature extends the meaning of "established" beyond the scope of TCP sessions. Which is to say the keyword "established" indicates that ipfw can, by one mean or another, verify that the packet is part of a session. This leaves as much flexibility as one may want (or at least close enough), while not requiring major architecture changes in ipfw (sort of)... Of course the problem of removing "established/monitored" connections is not dealt with. Is it really a concern ? Now that I think of it, "monitored" might be a better word than "established" since the type of checking (which could be also applied to TCP connections) is somewhat stricter thant the "established" keyword for TCP (which relies on trust of the TCP header). As far as coding goes, I would find it fun to work on that. So if you do not have too much time to look at it, let me do some mods and submit them later (I am talking of a couple of weeks time frame). Patrick. -- Patrick Bihan-Faou MindStep Corporation www.mindstep.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message