Julian Elischer <jul...@freebsd.org> wrote in <542155fb.9020...@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
pgpSK5rPI6G7m.pgp
Description: PGP signature
