Date: Mon, 13 Oct 2014 22:52:40 +1100 (EST)
From: Ian Smith <smithi@nimnet.asn.au>
To: Hiroki Sato <hrs@freebsd.org>
Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org
Subject: Re: net.inet{,6}.fw.enable in /etc/rc
Message-ID: <20141013202423.J56328@sola.nimnet.asn.au>
In-Reply-To: <20141012.050211.468265599523763400.hrs@allbsd.org>
References: <542155FB.9020801@freebsd.org> <20141002.163913.1611863032602700090.hrs@allbsd.org> <20141003025830.D48482@sola.nimnet.asn.au> <20141012.050211.468265599523763400.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Oct 2014 05:02:11 +0900, Hiroki Sato wrote: > Ian Smith <smithi@nimnet.asn.au> wrote > in <20141003025830.D48482@sola.nimnet.asn.au>: > > sm> which rules will be flushed when /etc/rc.d/ipfw runs, but should enable > sm> DHCP to work? I'm not sure whether those rules are exactly correct or > sm> sufficient for DHCP, but principle is to anly allow what's necessary in > sm> the circumstances this addresses, vastly reducing vulnerable window. > sm> > sm> Using such a method, there should be no need to modify rc.d/ipfw? > > I created an experimental patch based on an idea installing a minimal > ruleset. Please review the attached patch. rc.d/ipfw0 script to > install such a ruleset is invoked before rc.d/netif. The following > two knobs are added: > > $firewall_minimal_rules_enable > Enable/disable installing a minimal ruleset. > > $firewall_minimal_ruleset > Ruleset number to be used for the ruleset. Hi Hiroki. Comments below. > sm> > Does ipfw have rules which depend on interface initialization? If > sm> > not, moving rc.d/ipfw to just before rc.d/netif may be a better idea. > sm> > sm> It can. If using (say) mpd with dialup or ADSL modems, as I do, the > sm> interface - here ng0 - needs to preexist, needing an IP address too. > sm> > sm> I think that by now, many will likely rely on netif preceding ipfw. > > AFAICC an IPFW rule for ng0 can be installed before the interface is > created. Do you have a specific rule which is problematic if IPFW > rules are loaded before rc.d/netif runs? I am also using mpd and a > lot of cloned interfaces on my router box but it worked fine. That's probably right. That box switched to mpd at 4.1, having run ppp for a long time previously. /etc/rc.d/ppp always had # REQUIRE: netif ppp has possibly changed a lot since I last used it, so I don't know if that's really still required; probably, unless architecture has changed. Anyway, looking at rcorder /etc/rc.d/* there are quite a few possible interdependencies to explore before considering moving ipfw, including its relationship to pf - some people do use both - and perhaps routing, bridge, defaultroute, among others? Hard to imagine all usage cases .. I think your patch adds some unnecessary complexity to what should be needed to solve this fairly singular problem of the firewall being in kernel or loaded early, default to deny, with DHCP (etc) access needed before netif can succeed. I like the general idea of running ipfw0 (ono) earlier to enable needed rules in this specific context - perhaps also testing whether rc.conf indicates that DHCP (or ipv6 equivalents, about which I know nothing) is actually required on at least one of the to-be-configured interfaces? I don't think it's necessary to use a special set, set 0 would be fine as any firewall script will begin with a flush anyway. I don't think this function need require any user configuration at all, if possible, as it really is coping with an (albeit important) edge case. Couldn't proposed additions to rc.firewall just go into rc.d/ipfw0? Can you explain why any layer2 rules are needed specifically? Apart from testing for dest mac ff:ff:ff:ff:ff:ff as well as 255.255.255.255/32 on the first rule, maybe overkill?, can't all these rules be run at layer3? For one thing, if running L2 routing (and/or bridging), it's long been practice and advice to set net.link.ether.ipfw (&| net.link.bridge.ipfw) in /etc/sysctl.conf, and sysctl is run early .. on 9.3, first. This way you'll have to get people to update L2 configs to use this new firewall_link_enable variable as well or instead. If L2 is really necessary, perhaps the previous setting of net.link.ether.ipfw could be remembered by ipfw0 and exported for rc.d/ipfw, seeing this is currently the only change to rc.d/ipfw, apart from clearing of the temporary rules - which I believe the subsequent flush makes unnecessary anyway. Just some thoughts, cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141013202423.J56328>