Date: Mon, 26 Feb 1996 12:26:22 -0700 From: Nate Williams <nate@sri.MT.net> To: Poul-Henning Kamp <phk@critter.tfs.com> Cc: stable@freebsd.org, current@freebsd.org Subject: Re: IPFW (was: Re: -stable hangs at boot) Message-ID: <199602261926.MAA00360@rocky.sri.MT.net> In-Reply-To: <11931.825357016@critter.tfs.com> References: <11931.825357016@critter.tfs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I have tried to collapse three threads here, sorry for the cross-posting No problem, I like it this way and appreciate the extra work you've done. > PHK: > If you have IPFW in your kernel, you don't want it to pass any packets > PHK: > you haven't approved in your filters. > PHK: > > PHK: > QED: Setup your filters before anything gets passed. > > Nate: I can't do this on my box at all. It's a PPP connection, and *all* of > Nate: the filtering is done on my PPP interface, which can vary depending on > Nate: incoming calls. So, by having a default 'global' firewall entry I have > Nate: a couple problems. > > Nate: 1) There is no established way to have it be on a per-process. This is > Nate: *bad* news for me since my PPP box is also my DNS/router. I can't wait > Nate: for my PPP connection to come up before I add entries, and I want all of > Nate: my local machines to have access to *everything* on my router box. > > Yes you can. Add this to the top of /etc/netstart: > > ipfw add 65000 pass all from any to any. OK so far, but it needs to be in doable from a sysconfig or netstart hook (which you talk about later). > This changes your default policy to "pass everything". > Then later you can add the restrictions you want to. So far so good. :) > Nate: 2) There is no established method for adding IPFW entries in FreeBSD. > Nate: If we are going to make this the default method, I think we need some > Nate: hooks in /etc/netstart added to make this work. > This is next on my list of things. I'll be glad to see it go in. > Nate: 3) The code -stable is un-documented and incomplete w/regard to > Nate: -current. The documentation in -stable hasn't been updated yet. Here > Nate: is the last entry for the ipfw.8 man-page. > > Reality has overtaken you again. A couple of hours ago I committed a almost > complete synopsis and description to the man page. Glad to hear it, but it happened after I sup'd the CVS tree. It also appears that you need to add the patch you just made to -current into -stable as well. Don't you just hate having to keep two trees in sync sometimes? (Though the advantages outweigh the disadvantages). > PHK: Wrt to the rule #65535 "deny all from any to any", then you are correct, > PHK: you cannot delete it. It represents the default policy of "anything not > PHK: specifically allowed, is banned. > > Nate: While I understand why (see above), I still don't think this should be > Nate: the 'global' default behavior. > > I has to be the default, otherwise you leave a bunch of holes open in an > "secure" installation. Unless you require them to add a line similar to what you are requiring me to do in /etc/sysconfig. I think it should be sysconfig know to 'lock-down' the system, rather than have it be the default. It's just as easy to add a line to /etc/netstart to 'tighten up' the system as it is to 'loosen-up'. The latter will cause us much more support grief than the former. > Nate: I will dispute the design in that the current implementation *increases* > Nate: the liklihood of errors due to lack of documentation and flexibility. > Nate: The former may be the cause of the latter, but it's still a great cause > Nate: of concern. > > This I agree to, and I'm working as fast as I can to address it. I felt > it was very important though, to give people a tool to shut what seems > to be a published hole in the FreeBSD (ipfw) security. Comming up next :-) Waiting expectantly. (And I won't even bug you about reviewing the PC-CARD patches either. *grin*) > PHK: If you have IPFW in your kernel, you don't want it to pass any packets > PHK: you haven't approved in your filters. > > Wollman: Um, not necessarily. I have a situation here where there is /one/ > Wollman: network (out of three) that I need to isolate, and everything else > Wollman: should operate normally. > > And You can do that now, you couldn't before. Sure you could. I'm doing that now w/out the changes you've made. > You may not care about > the short time machines take to reboot, other people do. You can get > what you want now, and now: so can some other people. You could do it before, and can do it now if we add a line to /etc/netstart which is off by default which shuts down the entire machine. > PHK If you want to dispute this design, then please find at least one textbook > PHK or capacity in the area who agree with you first, that will save a lot of > PHK my time. > > Wollman: Appeal to irrelevant authority. Try again. > > Show me one sane authority on IP security that would defend "pass all" > as the boot time default... > I am seriously considering to make the filtering better than it is now. > > To be effective, we need to be able to apply multiple chains of rules, > something along the line of: "In" (per i/f), "Out" (per i/f), "routed", > "to me" and "from me". Doesn't the current code already do that? Obviously since it wasn't filtering outgoing packets before it didn't, but I'm not sure I could see the need for filtering differently for incoming vs. outgoing (except in the case of syn. packets). That reminds me. I haven't looked yet, but does the new code also filter out routing information? The old code didn't (and other firewall code I have used does). > Until then, rest assured that I'm not trying to make anybodys life misserable > intentionally, I'm have merely tried to close a security hole, and at the > same time improved your chances of doing so too... If you would have had the 'entire' solution in place at the same time as you made the changes I suspect most of this wouldn't be happening. Providing a solution I can't use simply makes it more difficult for me since I must do extra work to 'back out' the changes since I can't use them. I'm not tracking -current on my router box since that would be silly, but I can't even use the fixes you've put into fix holes w/out documentation. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602261926.MAA00360>