From owner-freebsd-ipfw@FreeBSD.ORG Fri Jun 26 09:04:11 2009 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5594C1065674 for ; Fri, 26 Jun 2009 09:04:11 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id A16FE8FC08 for ; Fri, 26 Jun 2009 09:04:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-005-052.pools.arcor-ip.net [88.66.5.52]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MKsym-1MK7Lt1L9E-000O1G; Fri, 26 Jun 2009 11:04:09 +0200 Received: (qmail 50911 invoked from network); 26 Jun 2009 09:04:08 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.187) by laiers.local with SMTP; 26 Jun 2009 09:04:08 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Fri, 26 Jun 2009 11:04:06 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.30-rc5-ARCH; KDE/4.2.3; x86_64; ; ) References: <4A444BC2.4010606@FreeBSD.org> In-Reply-To: <4A444BC2.4010606@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906261104.07597.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19cotJMtoMW3JgncrqbVOuFrOBZR7k9H8oqaZ3 F6t4ywdlJt9/2x6u2ubIoYHvxUJcoLOqUJ1jQfofCEEfXg8M/g 2euMpyX33eyDnj1jEMqZg== Cc: freebsd-ipfw@freebsd.org, Doug Barton , freebsd-pf@freebsd.org Subject: Re: pfsync rc script breaks pfsync on cloned interfaces X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 09:04:11 -0000 On Friday 26 June 2009 06:17:06 Doug Barton wrote: > I have reverted the change that caused pf and ipfw to appear before > netif in the rcorder. While I still feel strongly that it is the > "right thing" to configure the firewalls first, the changes caused too > many problems for too many users, and it's too late in the release > cycle to make a change like this that has significant side effects. > > I would like to strongly encourage those who use pf and ipfw to > consider doing the work required to make this change possible. With > ipfw it's not quite as urgent since by default it does not pass > packets till it is configured. This is not the case with pf, as its > default is wide open until it is configured. It's not a simple problem and I'm not sure we can really come up with a "one-size-fits-all" solution. That does not mean we shouldn't try, though. My idea how this should work is something along the following lines: 1) Very early in the boot (just after the necessary firewall configuration tools are available [NFS-root might be a problem here!]) setup an "initial firewall" configuration. For most users this could be a default (allow dhcp, outgoing DNS, maybe ssh in/out, NFS(???), ...). 2) After setting up the interfaces have the option to start a more involved firewall that is fully user supplied. At this point we should be able to look up DNS (though this is clearly a bad idea from the security PoV unless you have DNSSEC), get interface configurations and maybe even routing information. The latter could be another chicken-egg-problem as we might need a routing daemon active to get this. However, people who really need that should be able to modify the early setup accordingly. It is unclear to me where stage 2 should be located. I would argue that with a reasonable default setup we can easily get away with putting stage 2 at the very end of the start up procedure. If people need early holes in the firewall (e.g. for smbfs, routing daemons, ...) they can place them in the early stage. I would like input about how a very simple "save default" setup could look like. A ruleset for pf or ipfw that allows most of the boot process to complete without opening the host to the outside world, yet. For extra points this ruleset is aware of the rc.conf variables and adjusts accordingly (e.g. opening access to sshd iff it is configured). In addition there might be *one or two* configuration variables for the early stage to open additional ports or to select a default interface. However, the fewer the better. Input greatly appreciated! -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News