From owner-freebsd-pf@FreeBSD.ORG Mon Jun 1 19:05:34 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 649FD106564A for ; Mon, 1 Jun 2009 19:05:34 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id CD6B38FC22 for ; Mon, 1 Jun 2009 19:05:33 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 19854 invoked by uid 399); 1 Jun 2009 18:38:47 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Jun 2009 18:38:47 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A242035.8010101@FreeBSD.org> Date: Mon, 01 Jun 2009 11:38:45 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: freebsd-pf@freebsd.org X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bzeeb-lists@lists.zabbadoz.net, Gert Doering Subject: Moving the pf rc.d scripts to run before netif X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 19:05:34 -0000 Howdy, As you can see below, I've made a change to the order of execution of the rc.d scripts in 8-current (soon to be 8-release) to run all of the firewalls, including pf, before the network is up. However the following PR gives an example of why this might be bad: http://www.freebsd.org/cgi/query-pr.cgi?pr=130381 This leaves me with a few questions. 1. When the _kernel_ first starts, what is the condition of the pf firewall? In other words, you have pf in the kernel, and let's pretend that there is no rc.d/pf initialization script. What's going to happen to the packets when the network comes up? 2. The previous rcorder for the pf script was right after netif (the network coming up) and before routing .... why? Is this related to how pf does its work? The reason I ask this question is that in order to fix the IPv6 rcorder problem in the pr the way that Gert is suggesting the "BEFORE: routing" would have to be removed because our IPv6 startup depends on RA which depends on routing being up. (Side note, in the long term I'd like to revise this so that an IPv6-only host and/or a host with statically assigned IPv6 addresses can easily be configured within rc.d, but that's another thing altogether.) 3. Is the need to be able to use $ext_if after the network is up so overwhelmingly important that it justifies running pf after netif? Or is using ($ext_if) a reasonable solution? Anything else y'all would like to add is welcome at this point. Thanks, Doug -------- Original Message -------- Subject: Re: svn commit: r193198 - head/etc/rc.d Date: Mon, 01 Jun 2009 10:38:41 -0700 From: Doug Barton Bjoern A. Zeeb wrote: > On Mon, 1 Jun 2009, Doug Barton wrote: > >> Author: dougb Date: Mon Jun 1 05:35:03 2009 New Revision: 193198 >> URL: http://svn.freebsd.org/changeset/base/193198 >> >> Log: Make the pf and ipfw firewalls start before netif, just like >> ipfilter already does. This eliminates a logical inconsistency, >> and a small window where the system is open after the network >> comes up. > > Unfortunetaly this is contrary to a lot of PRs and requests on > mailing lists out there that actually want the netif/network_ipv6 > to be run _before_ things come up. Can you provide links to some of those PRs? I'd love to learn more about this issue. > Espescially pf really needs this to avoid rules that needs to do > per paket lookups of the interface address. Not sure what you mean here. > Further ipfw has a default option being setaable at compile time > and as TUNABLE to handle this window. And what happens if someone sets the default to accept? You could argue that they are knowingly opening a window of vulnerability but I would argue that the right thing to do is to have the firewall rules loaded before the network comes up regardless of the default. That way you avoid both the potential window of vulnerability AND the window of time between the network being loaded and the firewall allowing access to the box. To give a little more history, this patch was discussed and reviewed a while back and someone told me that they would incorporate it into some overall work they were doing to improve the way that rc.d handles networking, so I stopped paying attention to it. Last night a user pointed out to me that another patch that this same person said they would handle never got in, so I reviewed other outstanding work and found that this one had not been done either. Obviously if this change breaks something it will have to be reverted. However from the security standpoint (primary concern) it would seem to be the right thing to do, and the previous rcorder was not logically consistent in any case. Max Laier wrote: > Can you please add a note about this in UPDATING? Yes. I was on the fence about this anyways, so now you've pushed me over. :) > It might be a slight POLA violation for people who rely on the > interfaces being configured to setup the firewall. For instance > when one doesn't use dynamic address rules in pf i.e. "from/to ifX" > instead of "from/to (ifX)". I don't understand what you've written here. It seems to me that if the interfaces are always the same then the firewall rules will be fine, but if they are using dynamic rules it doesn't matter if it starts before or after the network is up. Doug -- This .signature sanitized for your protection