Date: Mon, 26 Feb 1996 18:50:16 +0100 From: Poul-Henning Kamp <phk@critter.tfs.com> To: stable@freebsd.org, current@freebsd.org Subject: IPFW (was: Re: -stable hangs at boot) Message-ID: <11931.825357016@critter.tfs.com>
next in thread | raw e-mail | index | archive | help
I have tried to collapse three threads here, sorry for the cross-posting 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. This changes your default policy to "pass everything". Then later you can add the restrictions you want to. 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. 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. 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. 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 :-) 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. 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. 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... IMB: I haven't checked this but .. what happens to a packet which matches a IMB: "reject" rule when it's not actually destined for the machine doing the IMB: filtering .. does it still generate an ICMP "host unreachable" ? IMB: This can happen, for example, with multiple subnets on one wire .. IMB: If so .. we have our incarnation of the M$ "sniper bug" that plagued WFW IMB: and WinNT boxes and which arbitrarilt shot down packets which were not IMB: theirs to kill :-( You decide if you want ICMP to be sent or the packet to silently be discarded. 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". I will probably post a strawman in tonight some time, then please take time to think over the issues and tell me your thoughts... 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... Poul-Henning
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?11931.825357016>