From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 2 07:39:59 2014 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB9943EA; Thu, 2 Oct 2014 07:39:58 +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 EA19361A; Thu, 2 Oct 2014 07:39:57 +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 s927dWGN075272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Oct 2014 16:39:42 +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 s927dTHo017073; Thu, 2 Oct 2014 16:39:31 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 02 Oct 2014 16:39:13 +0900 (JST) Message-Id: <20141002.163913.1611863032602700090.hrs@allbsd.org> To: julian@freebsd.org Subject: Re: net.inet{,6}.fw.enable in /etc/rc From: Hiroki Sato In-Reply-To: <542155FB.9020801@freebsd.org> References: <20140921.145812.325633000583440554.hrs@allbsd.org> <542063F3.8080600@yandex.ru> <542155FB.9020801@freebsd.org> 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(Thu_Oct__2_16_39_13_2014_926)--" 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]); Thu, 02 Oct 2014 16:39:52 +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, 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: Thu, 02 Oct 2014 07:39:59 -0000 ----Security_Multipart(Thu_Oct__2_16_39_13_2014_926)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Elischer wrote in <542155FB.9020801@freebsd.org>: ju> On 9/23/14, 2:01 AM, Andrey V. Elsukov wrote: ju> > On 21.09.2014 09:58, Hiroki Sato wrote: ju> >> Hi, ju> >> ju> >> I would like your comments about the attached patch to /etc/rc. ju> >> ju> >> The problem I want to fix by this patch is as follows. ju> >> net.inet{,6}.fw.enable are set to 1 by default at boot time if IPFW ju> >> kernel module is loaded or statically compiled into a kernel. And by ju> >> default IPFW has only a "deny ip from any to any" rule if it is ju> >> compiled without IPFIREWALL_DEFAULT_TO_ACCEPT option. In this case, ju> >> the default-deny rule can prevent rc.d scripts before rc.d/ipfw from ju> >> working as described in the patch. ju> >> ju> >> To fix this, the patch turns IPFW off before running rc.d scripts at ju> >> boot time, and enables it again in rc.d/ipfw script. ju> > Hi, ju> > ju> > I think this should be configurable, the change can be an unexpected ju> > for ju> > someone. ju> it does open a window where there is networking but no firewalling. ju> given that a reboot is remotely detectable. (ping stops responding ju> etc.) ju> there is a possibility that a targeted attack could include ju> "use exploit ABC to cause a crash of the target and then strike with ju> exploit XYZ after target system reboots while the firewall is ju> disabled". ju> ju> I have not evaluated the danger of this window. Yes, certainly this opens a window between rc.d/netif to rc.d/ipfw. I admit it is a problem of disabling IPFW unconditionally. Does ipfw have rules which depend on interface initialization? If not, moving rc.d/ipfw to just before rc.d/netif may be a better idea. -- Hiroki ----Security_Multipart(Thu_Oct__2_16_39_13_2014_926)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlQtASEACgkQTyzT2CeTzy3C0ACg1/0QZw6356lpzy+X3cJQG19C EuUAoIswuh1kKzT5+8G9OmURSVk5l7F5 =I4WB -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Oct__2_16_39_13_2014_926)----