Date: Tue, 14 Oct 2014 01:49:36 +0900 (JST)
From: Hiroki Sato <hrs@FreeBSD.org>
To: smithi@nimnet.asn.au
Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org
Subject: Re: net.inet{,6}.fw.enable in /etc/rc
Message-ID: <20141014.014936.1483336189189184574.hrs@allbsd.org>
In-Reply-To: <20141013202423.J56328@sola.nimnet.asn.au>
References: <20141003025830.D48482@sola.nimnet.asn.au> <20141012.050211.468265599523763400.hrs@allbsd.org> <20141013202423.J56328@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Tue_Oct_14_01_49_36_2014_368)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Smith <smithi@nimnet.asn.au> wrote in <20141013202423.J56328@sola.nimnet.asn.au>: sm> Anyway, looking at rcorder /etc/rc.d/* there are quite a few possible sm> interdependencies to explore before considering moving ipfw, including sm> its relationship to pf - some people do use both - and perhaps routing, sm> bridge, defaultroute, among others? Hard to imagine all usage cases .. I do not think ordering of ipfw and pf is important. Configuration of routes and others can depend on netif, but not on ipfw and other packet filters. One possible obstacle is a packet filter rule requires ifname or ifindex before the rule is added. IPFW does not have such restriction, though. sm> I like the general idea of running ipfw0 (ono) earlier to enable needed sm> rules in this specific context - perhaps also testing whether rc.conf sm> indicates that DHCP (or ipv6 equivalents, about which I know nothing) is sm> actually required on at least one of the to-be-configured interfaces? sm> sm> I don't think it's necessary to use a special set, set 0 would be fine sm> as any firewall script will begin with a flush anyway. I don't think sm> this function need require any user configuration at all, if possible, sm> as it really is coping with an (albeit important) edge case. sm> sm> Couldn't proposed additions to rc.firewall just go into rc.d/ipfw0? I think such a testing is more complex in practice from my experience with improving network.subr. Users who want the default-deny rule at boot time should be strict about the rule set. So, I want to make clear what rules are applied and make it configurable, and then set it to a reasonable default which allow only DHCPv4 and IPv6 DAD. This is the reason why I use rc.firewall. And, rc.d scirpts must be as consistent as possible in terms of behaviors on start and stop. "ipfw set" is easiest way to remove the minimal rule set upon stop. These implementation choices are not harmful or complex for normal users after all in my opinion. Even if we need dynamically-added rules depending on configuration in the future, it can be supported easily in this framework. sm> Can you explain why any layer2 rules are needed specifically? Apart from sm> testing for dest mac ff:ff:ff:ff:ff:ff as well as 255.255.255.255/32 on sm> the first rule, maybe overkill?, can't all these rules be run at layer3? L3 rule cannot catch the outgoing DHCPDISCOVER with the source address 0.0.0.0 and the destination address 255.255.255.255. You can try this on your box. sm> For one thing, if running L2 routing (and/or bridging), it's long been sm> practice and advice to set net.link.ether.ipfw (&| net.link.bridge.ipfw) sm> in /etc/sysctl.conf, and sysctl is run early .. on 9.3, first. sm> sm> This way you'll have to get people to update L2 configs to use this new sm> firewall_link_enable variable as well or instead. If L2 is really sm> necessary, perhaps the previous setting of net.link.ether.ipfw could be sm> remembered by ipfw0 and exported for rc.d/ipfw, seeing this is currently sm> the only change to rc.d/ipfw, apart from clearing of the temporary sm> rules - which I believe the subsequent flush makes unnecessary anyway. Ah, I see. I agree with this. I will update the patch. -- Hiroki ----Security_Multipart(Tue_Oct_14_01_49_36_2014_368)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlQ8AqAACgkQTyzT2CeTzy1UugCfX4XGbbnFoGKv/at2L4ygZeHG pyQAn33ZhSPiJsBYP1b9lRMUujmfufgC =mnmp -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Oct_14_01_49_36_2014_368)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141014.014936.1483336189189184574.hrs>