From owner-freebsd-pf@FreeBSD.ORG Sun Jul 16 21:45:02 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0F8416A4E0; Sun, 16 Jul 2006 21:45:02 +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 1A40343D53; Sun, 16 Jul 2006 21:45:00 +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 k6GLivff008269 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 16 Jul 2006 23:44:57 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6GLivPW011825; Sun, 16 Jul 2006 23:44:57 +0200 (MEST) Date: Sun, 16 Jul 2006 23:44:56 +0200 From: Daniel Hartmeier To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20060716214456.GE3240@insomnia.benzedrine.cx> References: <44B7715E.8050906@suutari.iki.fi> <20060714154729.GA8616@psconsult.nl> <44B7D8B8.3090403@suutari.iki.fi> <20060716182315.GC3240@insomnia.benzedrine.cx> <86y7utgt0o.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86y7utgt0o.fsf@xps.des.no> 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-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: Sun, 16 Jul 2006 21:45:03 -0000 On Sun, Jul 16, 2006 at 11:05:27PM +0200, Dag-Erling Smørgrav wrote: > > Hence, a "default block" switch or compile time option _within_ pf is > > not going to make any difference. > > Sure it will, if pf is compiled into the kernel or loaded by the BTX > loader. Ok, in that case I guess you want to enable pf by default, too. I haven't tried it in this mode, but the default block can be achieved by simply changing sys/contrib/pf/pf_ioctl.c pf_attach() - pf_default_rule.action = PF_PASS; + pf_default_rule.action = PF_DROP; bzero(&pf_status, sizeof(pf_status)); + pf_status.running = 1; That would then block all packets on all interfaces, until a ruleset is loaded. If anything started through the startup scripts needs unblocked packets (including the production ruleset loading requiring name resolution over network), you'd need to first load a simpler temporary ruleset to pass that, and finally replace it with the production ruleset. And, of course, if the boot sequence for any reason doesn't reach that point, you can only fix stuff with local access... :) I'm not sure the average user _really_ is worried enough about that half a second period on boot. But I DO know there will be people locking themselves out from far-away remote hosts (on updates, for instance) if this becomes the default. Daniel