Date: Mon, 28 Jan 2002 08:51:05 +0100 (CET) From: "Patrick M. Hausen" <hausen@punkt.de> To: "M. Warner Losh" <imp@village.org> Cc: charon@seektruth.org, dsyphers@uchicago.edu, security-officer@FreeBSD.ORG, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <200201280751.g0S7p5414157@hugo10.ka.punkt.de> In-Reply-To: <20020127.120138.07163985.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all! In a long and tiring thread Warner Losh once wrote: > : > The current behavior fails safe. The current behavior is documented. > : > I relied on that documentation when setting up my firewall. Now you > : > are wanting to change that documented behavior. It is that way > : > specifically so we fail safe. > : > : The current behavior also renders systems unusable. What good is having my > : web/mail server safe doing me if it can't process any mail or http requests? > : The default rc.conf says next to firewall_enable "Set to YES to enable > : firewall functionality," which implies that NO disables firewall > : functionality. Which is read "disables firewall", not "disables custom > : firewall scripts." I view the kernel as containing stuff that's > : _potentially_ used - I can have support in it for an ethernet card > : that's not installed. But the system doesn't hang looking for it. > > Rendering the system unusable is fail safe. > > : Anyway, the default rc.conf could have firewall_enable set to YES, which > : would make it "fail safe." > > No. That's not fail safe. My machine will still break in an > unacceptible way by this change. > > Please write up the exact details that you want to do so that those on > security-officer know exactly what you are proposing. It is my > understanding that you want to make enable_firewall=NO totally dyke > out the firewall that was compiled into the kernel and be a totally > open realy. I know that this breaks at least one machine that I have, > but I also know that this breaks our current fail-safe behavior, which > I'm strongly opposed to. > > However, I think I've become too embroiled in this issue, which is why > I want the fine folks at security-officer@ to evaluate it (since I'm > on that list, I'll refrain from doing more than stating my position). > It just doesn't seem right to me. Partly I agree with you, partly I think the original author is correct in the way that the current behaviour is confusing at least to novices. apm_enable="NO" -> disable apm. sendmail_enable="NO" -> disable sendmail. firewall_enable="NO" -> you get the idea. I'd suggest changing the name of the parameter to firewall_rules_enable or firewall_script_enable, or ... Wouldn't we get rid of this entire argument, if IPFIREWALL_DEFAULT_TO_ACCEPT was the default for the kernel part of ipfw and there was an option IPFIREWALL_DEFAULT_TO_DENY for anyone preferring the "old" behaviour? Since it is recommended to explicitly state every rule in your config file - with Cisco access lists as well as with ipfw - I assume almost everyone has a "add deny all from any to any" line at the end of his ruleset already? I'm currently in a project where I build a bridging firewall. Seems like I need DEFAULT_TO_ACCEPT to get arp through. I wouldn't mind if it became the default. Regards, Patrick M. Hausen Technical Director -- punkt.de GmbH Internet - Dienstleistungen - Beratung Scheffelstr. 17 a Tel. 0721 9109 -0 Fax: -100 76135 Karlsruhe http://punkt.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200201280751.g0S7p5414157>