net.inet{,6}.fw.enable in /etc/rc

Hiroki Sato hrs at FreeBSD.org
Thu Oct 2 07:39:59 UTC 2014


Julian Elischer <julian at freebsd.org> wrote
  in <542155FB.9020801 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20141002/732cc93b/attachment.sig>


More information about the freebsd-ipfw mailing list