Date: Thu, 02 Oct 2014 16:39:13 +0900 (JST)
From: Hiroki Sato <hrs@FreeBSD.org>
To: julian@freebsd.org
Cc: bu7cher@yandex.ru, ipfw@FreeBSD.org
Subject: Re: net.inet{,6}.fw.enable in /etc/rc
Message-ID: <20141002.163913.1611863032602700090.hrs@allbsd.org>
In-Reply-To: <542155FB.9020801@freebsd.org>
References: <20140921.145812.325633000583440554.hrs@allbsd.org> <542063F3.8080600@yandex.ru> <542155FB.9020801@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Thu_Oct__2_16_39_13_2014_926)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Julian Elischer <julian@freebsd.org> 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)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141002.163913.1611863032602700090.hrs>