From owner-freebsd-security@FreeBSD.ORG Sun Jul 16 18:23:20 2006 Return-Path: X-Original-To: freebsd-security@freebsd.org Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D72816A4DF; Sun, 16 Jul 2006 18:23:20 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A1B43D53; Sun, 16 Jul 2006 18:23:19 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k6GINIPO006956 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2006 20:23:18 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6GINFA0026185; Sun, 16 Jul 2006 20:23:15 +0200 (MEST) Date: Sun, 16 Jul 2006 20:23:15 +0200 From: Daniel Hartmeier To: Ari Suutari Message-ID: <20060716182315.GC3240@insomnia.benzedrine.cx> References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> <44B7D8B8.3090403@suutari.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B7D8B8.3090403@suutari.iki.fi> User-Agent: Mutt/1.5.10i Cc: freebsd-security@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Any ongoing effort to port /etc/rc.d/pf_boot, /etc/pf.boot.conf from NetBSD ? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jul 2006 18:23:20 -0000 On Fri, Jul 14, 2006 at 08:47:36PM +0300, Ari Suutari wrote: > There has been discussion about this before. I know that perfect > solution would be PF_DEFAULT_BLOCK, but while waiting for that > I wonder why we cannot have pf_boot, which closes the > boot hole (at least when run with proper filter rules). That is certainly not a perfect solution, as it misses the point, mostly. The "hole" being discussed is the time, during boot, before pf is fully functional with the production ruleset. For a comparatively long time, the pf module isn't even loaded yet. The time after module load and enabling pf with the production ruleset is much smaller. So, you first need to check the boot sequence for - interfaces being brought up before pf is loaded - addresses assigned to those interfaces - daemons starting and listening on those addresses - route table getting set up - IP forwarding getting enabled - etc. And to get rid of the "hole", you need to get the order right so there is nothing being exposed before the pf module is loaded. Once you have ensured that nothing gets exposed before rc.d/pf is started, it's trivial to make sure that that script only exits after pf has been enabled and the production ruleset is in place. Hence, a "default block" switch or compile time option _within_ pf is not going to make any difference. The problem lies mostly outside of pf, and the boot order needs to be carefully examined and adjusted, if needed. I think the chronological placement of rc.d/pf is already meant to achieve precisely that, have you actually checked the rc.d scripts and found some order that needs to be adjusted? Daniel