From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 2 19:12:37 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 DF446854; Thu, 2 Oct 2014 19:12:36 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4342A284; Thu, 2 Oct 2014 19:12:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s92JCPQm005803; Fri, 3 Oct 2014 05:12:25 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 3 Oct 2014 05:12:25 +1000 (EST) From: Ian Smith To: Hiroki Sato Subject: Re: net.inet{,6}.fw.enable in /etc/rc In-Reply-To: <20141002.163913.1611863032602700090.hrs@allbsd.org> Message-ID: <20141003025830.D48482@sola.nimnet.asn.au> References: <20140921.145812.325633000583440554.hrs@allbsd.org> <542063F3.8080600@yandex.ru> <542155FB.9020801@freebsd.org> <20141002.163913.1611863032602700090.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Thu, 02 Oct 2014 19:12:37 -0000 On Thu, 2 Oct 2014 16:39:13 +0900, Hiroki Sato wrote: > 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. Well, being only an issue when ipfw is compiled into kernel (without DEFAULT_TO_ACCEPT) or deliberately preloaded in /boot/loader.conf, we can a) determine whether net.inet.ip.fw.enable is set and only if so, b) add rule/s to enable only DHCP, perhaps something like (tested here): if [ "`sysctl -ni net.inet.ip.fw.enable`" = "1" ]; then # "0" if ipfw loaded but disabled or "" if not loaded echo "firewall already enabled - allowing DHCP only" ipfw add 65534 allow udp from me to any 67 out ipfw add 65534 allow udp from any 67 to me in else echo "ipfw not loaded .. doing nothing" fi which rules will be flushed when /etc/rc.d/ipfw runs, but should enable DHCP to work? I'm not sure whether those rules are exactly correct or sufficient for DHCP, but principle is to anly allow what's necessary in the circumstances this addresses, vastly reducing vulnerable window. Using such a method, there should be no need to modify rc.d/ipfw? > 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. It can. If using (say) mpd with dialup or ADSL modems, as I do, the interface - here ng0 - needs to preexist, needing an IP address too. I think that by now, many will likely rely on netif preceding ipfw. > -- Hiroki cheers, Ian