From owner-freebsd-pf@FreeBSD.ORG Mon Jun 1 19:45:20 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 7F08E1065675 for ; Mon, 1 Jun 2009 19:45:20 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.freebsd.org (Postfix) with ESMTP id 12CC78FC12 for ; Mon, 1 Jun 2009 19:45:19 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-067-225-144.pools.arcor-ip.net [88.67.225.144]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1MBDRe288t-0001Y2; Mon, 01 Jun 2009 21:45:18 +0200 Received: (qmail 17376 invoked from network); 1 Jun 2009 19:45:18 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.187) by laiers.local with SMTP; 1 Jun 2009 19:45:18 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Mon, 1 Jun 2009 21:45:16 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.30-rc5-ARCH; KDE/4.2.3; x86_64; ; ) References: <4A242035.8010101@FreeBSD.org> In-Reply-To: <4A242035.8010101@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906012145.17315.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+q/+R63OIign9joHA34DaOJUuizEAHrYj8l9i 7hWQvBspNKLRcopqMpS2WbkqvlmAcDkovh+GIlyPvWKuEPoX25 crL/6z9aNBY3I1iMUp+3A== Cc: bzeeb-lists@lists.zabbadoz.net, Gert Doering Subject: Re: 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:45:20 -0000 On Monday 01 June 2009 20:38:45 Doug Barton wrote: > 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? The default behavior is to pass everything unconditionally. > 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? Traditionally pf has had some issues with startup before netif. e.g. it was not possible to configure ALTQ on interfaces before they are created. Over the years most of these restrictions have been fixed (though you still need to specify an absolute bandwidth for ALTQ if you want to configure non-existing interfaces). The last remaining issue with non- existing interfaces is the "set loginterface". In addition people seem to like to use symbolic hostnames in their pf.conf for some reason. It's a bad idea from the security perspective, but who am I to decide how one shoots oneself? Symbolic hostnames, as well as non-dynamic interface statements are evaluated at ruleset load-time in pf. Thus the resolver must work when we load a ruleset with rules like that. > Anything else y'all would like to add is welcome at this point. It might make sense to have the ability for two points to configure the firewall. One "firewall_early" to setup a minimal "block all/allow dhcp/RA/DNS/..." and "firewall_late" to setup the final thing. In any case setting up the firewall is a non-trivial task and I doubt that there really is a good "one size fits all" solution. I'd prefer your version over the previous incarnation - as it is secure by default. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News