From owner-freebsd-stable Mon Jan 28 19:42:37 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rz.uni-ulm.de (gemini.rz.uni-ulm.de [134.60.246.16]) by hub.freebsd.org (Postfix) with ESMTP id B9D1737B417 for ; Mon, 28 Jan 2002 19:42:30 -0800 (PST) Received: from lilith (lilith.wh-wurm.uni-ulm.de [134.60.106.64]) by mail.rz.uni-ulm.de (8.12.1/8.12.1) with SMTP id g0T3gTxQ013630 for ; Tue, 29 Jan 2002 04:42:29 +0100 (MET) Message-ID: <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de> From: "Siegbert Baude" To: References: <15445.37204.693732.376471@caddis.yogotech.com> <20020128150458.E10891-100000@charon.acheron.localnet> <15445.46625.765383.179068@caddis.yogotech.com> <20020128223911.GA7080@rhadamanth> Subject: Summary: Problems and Proposals of firewall_enable (was: Re: firewall config (CTFM)) Date: Tue, 29 Jan 2002 04:42:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hello folks, thanks to Ceri, Erik, Richard and Warner, who made the points, I'm repeating here with a slight addition of mine. In media res: comparing defaults/rc.conf and "man rc.conf": defaults/rc.conf: firewall_enable="NO" # Set to YES to enable firewall functionality man rc.conf: firewall_enable (bool) Set to ``NO'' if you do not want have firewall rules loaded at startup, or ``YES'' if you do. If set to ``YES'', and the kernel was not built with IPFIREWALL, the ipfw kernel module will be loaded. See also ipfilter_enable. Problem 1: The variable's main function is about loading rule sets, as clearly indicated in the man page, but the name is stressing the less important part of loading the kernel module. Problem 2: The comment in defaults/rc.conf even enforces the misleading name as it talks about functionality, which is only true in case of using the kernel module, but not in the case of compiled in IPFIREWALL. To mention functionality really is a bug, as someone said: firewall_enable is about the operation not the state (which is equivalent to functionality in this case)! Problem 3: Neither man page nor defaults/rc.conf mentions the possibility of locking yourself out with compiled in IPFIREWALL without additional ruleset, as the kernel defaults to "deny all" (which is not obvious at all, but is secure and therefore should be kept as is). Problem 4: Maybe only my ignorance, because I never did it: How do I find out before reboot, if IPFIREWALL is compiled in my kernel, if the relevant config file is not there, e.g. on very stripped installations, where make buildworld/-kernel is done on external machines? We all know the lack of documentation in the real admin's world. Verbal heritage between admin generations is sometimes suboptimal, too. Don't forget compiling kernel with IPFIREWALL to be the recommended way, as someone mentioned in this thread! So this should be found in numerous computers. Steps to be taken: To solve Problem 2, Ceri's suggestion to change the comment in defaults/rc.conf is very good. I just added one remark and used capital letters as warning like in LINT/NOTES: firewall_enable="NO" # Set to YES: 1) to load firewall rulesets. # 2) to load kernel module, if needed. # Set to NO: CAN LOCK YOU OUT, if you have # IPFIREWALL compiled in your kernel! This could be done immediately without any bad consequences. The hint should make users read more documentation, before they shoot themselves in the foot. To solve problem 3 and 4, somebody *duck* has to add some phrases in the rc.conf manpage. To solve problem 1, the short term solution is to rename "firewall_enable" with "firewall_rules_load". The comment YES/2) should probably be altered to: "This implies loading the kernel module, if needed." Long term solution #1: Use Warner's improved scripts suggested some mails before, but _please_: Name the variable "firewall_functionality", what Warner called "firewall_enable"! This is so much clearer. Long term solution #2: Rethink the variables with having two different methods in mind, i.e. ipfw and ipfilter. Should be in the line of (capital letters denote defaults): firewall_functionality on/OFF firewall_method ipfilter/IPFW firewall_ruleset UNKNOWN #see /etc/rc.firewall * firewall_ruleset_load on/OFF #always OFF if ruleset==UNKNOWN * firewall_kernel_overrule ON/off #will overrule firewall_functionality #if IPFIREWALL is compiled in kernel ** some_ipfw/ipfilter_specifics #as already is *: This is in accordance to Warner's point, that compiled in kernel rules, shouldn't be touched unless explicitly wanted. This should be true not only for IPFIREWALL but also for IPFIREWALL_DEFAULT_TO_ACCEPT. "firewall_ruleset" replaces "firewall_type". With firewall_ruleset_load the method UNKNOWN maybe is dispensable and should be replaced with "filename" pointing to a standard place in /etc . Possibility: throw out the types, but instead create some equivalent standard rulesets. Similar to the cvsup examples. DEFAULT to something useful then, of course. **: This is in accordance to Warner's point, that the fallback of admin's error with firewall_functionality shouldn't disable the kernel firewall. So if you accidentally turn firewall_functionality to OFF, you will still have your kernel firewall enabled (note the default ON of overrule). Enough security Warner? I think you can also imagine situations, where you want kernel firewall disabled on reboot. It is better to keep things in one place, so we need this one instead of some sysctl tweaking in other places. If some admin changes both variables accidentally, he deserves to have his pants^h^h^h^h^hfirewall down. :-) As I never fiddle with CURRENT, it's up to security and core team to decide, which steps could be taken when and where (CURRENT or STABLE). Has the discussion to be continued on the stable list? Ciao Siegbert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message