From owner-freebsd-net@FreeBSD.ORG Mon Mar 19 02:17:08 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E7E916A400 for ; Mon, 19 Mar 2007 02:17:08 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.freebsd.org (Postfix) with ESMTP id C143613C46A for ; Mon, 19 Mar 2007 02:17:07 +0000 (UTC) (envelope-from kian.mohageri@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so1076102wxc for ; Sun, 18 Mar 2007 19:17:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=svjNtEdiOgDNyGEfO50+dcTNSX6OMlwwhD9LMzOXJ2OJrEoYebB5mRDmxD9Jz+va2ZBe7ykjCeyyTABgZXaBjMBozxSKEvAukaS1JvnFN5U5wv0n5R7WoUJuJmhHt5CtVLAXf06U+Is0PhRgL+vvPi4Q0ARbDJPa+XUwt3/X550= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=GAK4XKU6FquMYkZQYYhqG007oqBUKymnw4r0wQditRkWJhEP8hvlpcHYBw549jD9rZLIgpte0dzUGOIHjjRPIffLDi0SIG83/0T5mJyRwjbAft5Zz2WWgDtHu/7SCfa2v3Q0GWf/+yJ8N0exJMCWwXGJPUNabx5NUmRRQilIB5A= Received: by 10.70.66.18 with SMTP id o18mr7609735wxa.1174270627007; Sun, 18 Mar 2007 19:17:07 -0700 (PDT) Received: from ?10.1.1.53? ( [71.227.220.29]) by mx.google.com with ESMTP id h20sm8008088wxd.2007.03.18.19.17.04; Sun, 18 Mar 2007 19:17:05 -0700 (PDT) Message-ID: <45FDF284.3040008@gmail.com> Date: Sun, 18 Mar 2007 19:16:36 -0700 From: Kian Mohageri User-Agent: Thunderbird 1.5.0.9 (X11/20070103) MIME-Version: 1.0 To: Doug Barton References: <200703171210.l2HCAD63046801@drugs.dv.isc.org> <45FC7EAE.803@FreeBSD.org> <45FC90CE.3020605@gmail.com> <45FDD5C3.1070305@FreeBSD.org> In-Reply-To: <45FDD5C3.1070305@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mark Andrews , freebsd-rc@freebsd.org Subject: Re: rc.order wrong (ipfw) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 02:17:08 -0000 Doug Barton wrote: > That said, if the issues of needing to resolve hostnames and set up > rules for cloned interfaces are a universal problem (and it seems that > they are) then perhaps rather than customizing a solution for pf it > might be worthwhile to have a more generic "firewalls_late" script that > performs the appropriate actions regardless of what firewalls are > enabled. That way we could add just one rc.d script, and using the new > functionality would be opt-in. Off the top of my head I envision > something like: > > if [ checkyesno $firewall_enable -a -n "$firewall_rules_late" ]; then > # do stuff specific to ipfw > fi > if [ checkyesno $ipfilter_enable -a -n "$ipfilter_rules_late" ]; then > ... I agree VERY MUCH with this sort of approach. It would be a much cleaner solution than completely separate handling of all of these different problems. I'm trying to get an idea of what all of the major problems with the current order are, and these are the ones I'm aware of: - ipfw blocks by default (names unresolvable, rtsol breaks) - ipf/pf pass by default (services are unprotected) I think a firewall_boot script (similar to what you've proposed) could potentially solve all of these problems. If the user chose to enable it, it would do something like this: - load modules for pf/ipfw/ipf (whichever are enabled in rc.conf) - load firewall-specific minimal rulesets for enabled firewall(s) It would start BEFORE routing/netif, protecting services, but it would allow things like rtsol and name resolution to work. To elaborate a bit on your ideas, firewall_boot might do something like this: ... if [ checkyesno $firewall_enable -a -f $firewall_boot_script ]; # load ipfw and minimal ruleset if [ checkyesno $pf_enable -a -f $pf_boot_rules ]; # pf and minimal ruleset if [ checkyesno $ipfilter_enable -a -f $ipfilter_boot_rules ]; # ipfilter and minimal ruleset ... The tiny default boot rulesets would be in /etc/defaults/ and of course the user could override the location if they wanted to use their own early ruleset. The actual firewall scripts could then come up after the network, so cloned interfaces have been created, names can be resolved, etc. and the real rulesets should load without any problems. Does that sound reasonable? -Kian