Date: Tue, 29 Jan 2002 20:34:01 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-stable@freebsd.org Subject: Re: Summary: Problems and Proposals of firewall_enable (was: Re: firewall config (CTFM)) Message-ID: <20020129203401.H1494@shell.gsinet.sittig.org> In-Reply-To: <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de>; from Siegbert.Baude@gmx.de on Tue, Jan 29, 2002 at 04:42:54AM %2B0100 References: <15445.37204.693732.376471@caddis.yogotech.com> <20020128150458.E10891-100000@charon.acheron.localnet> <15445.46625.765383.179068@caddis.yogotech.com> <20020128223911.GA7080@rhadamanth> <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 29, 2002 at 04:42 +0100, Siegbert Baude wrote:
>
> 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.
Is this the moment where we have to ask for INCLUDE_CONFIG_FILE
in GENERIC once more? Is the public demand or "would be nice"
judgement big enough to make me sit down and provide a patch?
I know it's not a one line change. GENERIC should get the option
added while release build scripts and maybe picobsd stuff don't
like bloat like "nice" string tables in executables for the users'
pure pleasure but without essential functionality.
[ should this be worth a new thread feel free to change the
subject, it's in no way connected to the firewall_enable
discussion :) ]
> 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
This implies that ipf and ipfw are mutually exclusive. Although
rc.conf(5) suggests to use one of them, people reportedly run
both of them alongside without any problems. They use ipf for
packet filtering tasks while ipfw does traffic shaping (bandwidth
limiting).
This and the fact that both filters come into play at totally
different times and places in the boot sequence won't let you
combine these two aspects (easily or without too much code of
spaghetti shape). Even if ipfw invocation gets moved upwards
to where ipf gets initialized there is still the situation
where both are enabled at the same time.
There might be a "filter_enable" setting with an "ON/OFF" range
and a "filter_systems" setting with a *list* of implementations
to configure. But then an empty list could easily take the place
of the OFF switch ... And I wouldn't stick too much with the
"we only have ipfw or ipf" constraint in mind. We might have
OpenBSD's pf some day in the near future, too. :)
> firewall_ruleset UNKNOWN #see /etc/rc.firewall *
> firewall_ruleset_load on/OFF #always OFF if ruleset==UNKNOWN *
This one is strictly ipfw related (ATM?). Although one could have
misused the firewall_ruleset to hold what is in ipfilter_rules now.
But again, see above: ipfw and ipf can happily run at the same
time.
> firewall_kernel_overrule ON/off #will overrule firewall_functionality
> #if IPFIREWALL is compiled in kernel
If this boils down to a single sysctl setting than it probably
is better done in sysctl.conf. ISTR that there is a general
move towards this direction (to eliminate switches which only
do / result in a "sysctl $MIB=$VAL").
BTW: Is the above your notation for ON to be the default? This
is in contrast to what the prose says. :> Or do I misread it and
it means "leave what's already the kernel's behaviour no matter
what the rc.conf variables specify"? I'm a little confused. Some
"disable_loaded_filter" might be better. But see the above
comment on "if it's a mere sysctl ...".
> *: 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.
AMEN! :) I considered this to be a common FreeBSD or UNIX in
general policy: Don't guess what could have been meant but
instead stupidly(id? there certainly is a better word but I'm
not a native speaker) following the admin's / user's command.
The human in control is to blame for all the "issues" which
result from wrong commands -- but in return gets full control
of what happens.
> [ ... ] It is
> better to keep things in one place, so we need this one instead of some
> sysctl tweaking in other places. [ ... ]
Good point. But I thought I had spotted a movement of eliminating
"simple sysctl wrappers". Unless I'm mistaking ...
> Has the discussion to be continued on the stable list?
-chat? :) -security? -hackers?
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
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?20020129203401.H1494>