Date: Wed, 30 Jan 2002 01:52:12 +0100 From: "Siegbert Baude" <Siegbert.Baude@gmx.de> To: <freebsd-stable@freebsd.org> Subject: Re: Summary: Problems and Proposals of firewall_enable (was: Re: firewall config (CTFM)) Message-ID: <00d301c1a928$5aa47d80$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> <008001c1a877$091c2aa0$4011a8c0@whwurm.uniulm.de> <20020129203401.H1494@shell.gsinet.sittig.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, a proposal created at 4a.m. local time couldn't be perfect. :-) Reading the existent docs took some time. > > 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? If this is the only way to find out, yes. But I'm quite sure, that it should be possible to make the ipfw react on some commands, so that you can decide, whether it's in or not. But I don't know if this beast already exists at all. The INCLUDE_CONFIG_FILE should get a warm recommendation in some prominent place (handbook?). If servers are maintained by several people it should be a "must have". I'm a great fan of the idea, that I should be able to find out everything about my system, when it's already running. Even if I missed the kernel boot messages (I know they are stored in /var besides dmesg). But this really is a different thread and as I'm only on stable, announce and questions, I don't know where to move this. Feel free to do it wherever is appropriate. > > 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. [..] > 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). [..] > 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. :) Good points. My firewall_method should be a set of desired base system packet filters. And yes an empty set would be equivalent to "firewall_functionality off", but it is not so descriptive as having two separat variables. Didn't this holy thread start with ambiguous meaning of variables? Clearness is more important than one left out variable, IMHO. This is not in the inner loop of some heavily used kernel algorithm, but in a config file meant to be read and edited by humans! BTW, that the different firewalls are initialised at different times doesn't imply that the configuration can be done together in contiguous lines of rc.conf. The evaluation of the variables by the rc script doesn't depend on the place, where the variables are set. > > 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. I didn't mean to throw out the additional ipfilter variables. My naming tries to be similar to the status quo. To be more concise it could be named ipfw_ruleset and ipfw_ruleset_load. Then there is ipfilter_ruleset, pf_ruleset, xxx_ruleset, ... in addition. > > 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"). As I'm not on the list, where such things are discussed (where?), I can't comment on this one. But I very much would prefer to tweak those things in one place, which are about the same topic (firewall in this case). So even if it is only one line for sysctl, it should be defined in rc.conf not sysctl.conf . > 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"? Fallen into the same trap as firewall_enable. Ambiguous. Damn :-( It should be read as: IPFIREWALL kernel settings, which are compiled into the kernel should overrule my new "firewall_functionality" variable. The default of "ON" therefore to fulfill Warner's point. But of course this can be read as: This variable will overrule kernel setting. So please suggestions for a better name, English isn't my native language. :-) firewall_kernel_priority? -preeminence? -kept_in_state? -always_active? Ciao Siegbert P.S.: Gerhard, did you see my comment on your PR? Should the addition for the man page be a separate PR? And sorry for the double post, missed the list in first place. 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?00d301c1a928$5aa47d80$4011a8c0>