From owner-freebsd-security@FreeBSD.ORG Sun Jul 16 19:17:44 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 7577016A4E0; Sun, 16 Jul 2006 19:17:44 +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 193BE43D55; Sun, 16 Jul 2006 19:17:35 +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 k6GJHWlo022178 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2006 21:17:33 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6GJHWZS011626; Sun, 16 Jul 2006 21:17:32 +0200 (MEST) Date: Sun, 16 Jul 2006 21:17:32 +0200 From: Daniel Hartmeier To: Ari Suutari Message-ID: <20060716191732.GD3240@insomnia.benzedrine.cx> References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> <44B7D8B8.3090403@suutari.iki.fi> <20060716182315.GC3240@insomnia.benzedrine.cx> <44BA8A95.10300@suutari.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44BA8A95.10300@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 19:17:44 -0000 On Sun, Jul 16, 2006 at 09:51:01PM +0300, Ari Suutari wrote: > I could of course adjust my rc.d scripts, but I would very much > appreciate that security-related things are there correctly in > standard setup. > > I'll try to port pf_boot myself if nobody else volunteers. > (I don't think there is much porting to do, however). The point of OpenBSD's "boot-time" (preliminary) ruleset is that pf can be activated earlier, before the production ruleset can be loaded. The production ruleset can usually not be loaded very early on in the boot sequence, because it can contain constructs that rely on interfaces having been created, IP addresses assigned, or host name resolution working. At the point in time where all these things work, other things are already exposed (briefly). So what OpenBSD does (and I guess what that pf_boot script does on NetBSD) is enable pf with a short hard-coded preliminary ruleset very early on in the boot sequence, which only allows traffic which is needed by the boot process itself subsequently. This protects the things exposed afterwards, but before the production ruleset can be loaded. It also remains effective should the production ruleset fail to load (hence it usually allows ssh access to the firewall itself). So first you need to identify whether FreeBSD's boot sequence suffers the same issue (things are being exposed prior to the point where you can load the production ruleset). Then you need to find the proper time to load the kernel module and activate a preliminary ruleset. And of course the preliminary ruleset needs to account for all legitimate traffic that can subsequently occur during boot on various kinds of setups. One word of warning, the OpenBSD preliminary ruleset had to be revised many times when people found it broke things that the boot sequence needs in non-default setups. You'll likely go through several revisions on FreeBSD as well. You claimed there was a hole. If you can't explain what it consists of ("thing X might get exposed prior to rc.d/pf due to the following sequence of events..."), blindly sticking in pf_boot at some convenient place in the boot order is not guaranteed to solve more than it can break. Whoever is going to do this, will NEED to carefully go through the rc.d sequence with regards to networking. Daniel