Date: Fri, 6 Nov 1998 00:09:28 +1300 (NZDT) From: Andrew McNaughton <andrew@squiz.co.nz> To: Open Systems Networking <opsys@mail.webspan.net> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Amazing wonder packet Part 2. Message-ID: <Pine.BSF.4.01.9811052345450.17028-100000@aniwa.sky> In-Reply-To: <Pine.BSF.4.02.9811050419420.26130-100000@orion.webspan.net>
next in thread | previous in thread | raw e-mail | index | archive | help
There was an earlier post that covered this which I think you haven't read or haven't understood. Assuming that the default policy is to deny all and assuming that rules are added in numerical order, the result of any rule being missing can only be to deny the packet, which should be safe for most purposes. In most cases there's no problem for your solution. I considered building a wrapper for ipfw to simplify firewall specification and allow for some automated dynamic manipulation of the rule table. If you are doing something like this then it might mean that it was easier to do as you suggest than to guarantee that rules be added in numerical order. Probably ipfw is not the building block you'd choose though. Andrew McNaughton On Thu, 5 Nov 1998, Open Systems Networking wrote: > Date: Thu, 5 Nov 1998 04:24:00 -0500 (EST) > From: Open Systems Networking <opsys@mail.webspan.net> > To: freebsd-security@FreeBSD.ORG > Subject: Amazing wonder packet Part 2. > > > Ok someone sent me this so I thought I would run it by the list i'll quote > the message here: > > "seeing how /etc/rc.firewall is a shell script, it is reasonable to assume > that most ruleset will include small raceable sections where some packets > that should be denied will not be. I kludged as bellow: > > put a '$fwcmd add 1 deny all from any to any' as the first rule and moved > the flush command to one line above it. > > put a '$fwcmd delete 1' right after my 65534 deny all. > > This should cut the available time for races down substantially. I've seen > packets hit the temporary rule but have never seen a magic packet that > made it too the last." > > What do you guys think about this as a possible solution/hack. > Short of tearing up ipfw which I don't have the time to do can anyone see > this having more negative actions rather than positive ones? > Im not really sure what else one could do. > > Chris > > -- > "You both seem to be ignoring the fact that the networking market is > driven by so-called 'IT professionals' these days, most of whom can't > tell the difference between an ARP and a carp." --Wes Peters > > ===================================| Open Systems FreeBSD Consulting. > FreeBSD 3.0 is available now! | Phone: (402)573-9124 / ICQ # 20016186 > -----------------------------------| 3335 N. 103 Plaza, Omaha, NE 68134 > FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net > http://www.freebsd.org | Consulting, Network Engineering, Security > ===================================| http://open-systems.net > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.01.9811052345450.17028-100000>