From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 13 16:55:32 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CFED689; Mon, 13 Oct 2014 16:55:32 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 702CFF74; Mon, 13 Oct 2014 16:55:31 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s9DGt7NY021279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Oct 2014 01:55:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s9DGt5Z8035882; Tue, 14 Oct 2014 01:55:06 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Tue, 14 Oct 2014 01:49:36 +0900 (JST) Message-Id: <20141014.014936.1483336189189184574.hrs@allbsd.org> To: smithi@nimnet.asn.au Subject: Re: net.inet{,6}.fw.enable in /etc/rc From: Hiroki Sato 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> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Tue_Oct_14_01_49_36_2014_368)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Tue, 14 Oct 2014 01:55:25 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 16:55:32 -0000 ----Security_Multipart(Tue_Oct_14_01_49_36_2014_368)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Smith 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)----