Date: Fri, 3 Oct 2014 05:12:25 +1000 (EST)
From: Ian Smith <smithi@nimnet.asn.au>
To: Hiroki Sato <hrs@freebsd.org>
Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org
Subject: Re: net.inet{,6}.fw.enable in /etc/rc
Message-ID: <20141003025830.D48482@sola.nimnet.asn.au>
In-Reply-To: <20141002.163913.1611863032602700090.hrs@allbsd.org>
References: <20140921.145812.325633000583440554.hrs@allbsd.org> <542063F3.8080600@yandex.ru> <542155FB.9020801@freebsd.org> <20141002.163913.1611863032602700090.hrs@allbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2 Oct 2014 16:39:13 +0900, Hiroki Sato wrote:
> 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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141003025830.D48482>