Date: Tue, 29 Jan 2002 04:42:54 +0100 From: "Siegbert Baude" <Siegbert.Baude@gmx.de> To: <freebsd-stable@freebsd.org> Subject: Summary: Problems and Proposals of firewall_enable (was: Re: firewall config (CTFM)) Message-ID: <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de> References: <15445.37204.693732.376471@caddis.yogotech.com> <20020128150458.E10891-100000@charon.acheron.localnet> <15445.46625.765383.179068@caddis.yogotech.com> <20020128223911.GA7080@rhadamanth>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?008001c1a877$091c2aa0$4011a8c0>