Date: Fri, 25 Jan 2002 18:23:12 -0600 From: "Thomas T. Veldhouse" <veldy@veldy.net> To: <cjclark@alum.mit.edu> Cc: "Patrick Greenwell" <patrick@stealthgeeks.net>, <stable@FreeBSD.ORG> Subject: Re: Firewall config non-intuitiveness Message-ID: <000c01c1a5ff$a4539870$0101a8c0@cascade> References: <20020124201411.A39351-100000@rockstar.stealthgeeks.net> <20020124220302.N87663@blossom.cjclark.org> <002b01c1a5a7$67200e00$3028680a@tgt.com> <20020125160846.A14394@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Fri, Jan 25, 2002 at 07:51:33AM -0600, Thomas T. Veldhouse wrote: > > It works as expected using the GENERIC kernel. > > Because when there is no firewall in the kernel and firewall_enable is > not set to "YES", there is no firewall loaded. This behavior would not > change. In fact this can be an argument for the suggested change, it > would make behavior more consistent between systems without built-in > firewalling and ones with firewalling. Behavior is very consistant. It loads the ipfw module if needed and runs the firewall script. > > > It only works the way > > complained about when you build your own custom kernel with IPFIREWALL and > > not with IPFIREWALL_DEFAULT_TO_ACCEPT. At that point, I think the admin > > needs to educate one self. I prefer to leave it as is, as it errs on the > > side of safety. > > I am not sure that making the system pretty much unusable really errs > on the side of safety. I guess brick, cut off from the world, is > pretty secure. We always need to balance security versus other > factors and usability is one of the big ones. No -- it implies that you should know what you are doing if you are going to be building and installing new kernels and working on you firewall remotely. There is NOTHING stopping you from getting onto the machine with a good old fashioned keyboard. > > > There is a message to this respect right in the LINT configuration file. > > > > # WARNING: IPFIREWALL defaults to a policy of "deny ip from any to any" > > # and if you do not add other rules during startup to allow access, > > # YOU WILL LOCK YOURSELF OUT. It is suggested that you set > > firewall_type=open > > # in /etc/rc.conf when first enabling this feature, then refining the > > # firewall rules in /etc/rc.firewall after you've tested that the new kernel > > # feature works properly. > > It doesn't actually mention that you need to set firewall_enable="YES" > here, but I really do not think there is a problem with the current > documentation either. You don't actually have to if you don't want to. You can set the proper sysctl in /etc/sysctl.conf if you like. > > I _do_ think that having firewall_enable="NO" actually disable the > firewall would be more useful. Right now, there is no supported way to > boot up a system with firewalling built into the kernel and actually > disable the firewalling. I think that should be an option. That's > really what makes the change attractive to me. (I have wanted to do > this in the past, I had to enable firewalling, load an "open" rule > set, before I could flip 'net.inet.ip.fw.enable' off.) That tells me that you should either leave it as a module or add IPFIREWALL_DEFAULT_TO_ACCEPT to your kernel config. Both are something that is an educated administration choice. The only time that firewall_enable="NO" is a problem is when you consciously put IPFIREWALL into the kernel. It really is up to you to make sure you at least know a little about what you are doing when you begin messing with a new kernel and building a firewall. I still believe the current knobs in rc.conf work just fine and I don't believe they should be changed at all as they pertain to this discussion. Tom Veldhouse veldy@veldy.net > > > ----- Original Message ----- > > From: "Crist J. Clark" <cjc@FreeBSD.ORG> > > To: "Patrick Greenwell" <patrick@stealthgeeks.net> > > Cc: <stable@FreeBSD.ORG> > > Sent: Friday, January 25, 2002 12:03 AM > > Subject: Re: Firewall config non-intuitiveness > > > > > > > On Thu, Jan 24, 2002 at 08:21:50PM -0800, Patrick Greenwell wrote: > > > > > > > > I recently got bit by this: I have firewall options configured into my > > > > kernel, and made the mistake of thinking that in order to disable > > > > this functionality to allow all traffic that I merely needed to remove > > the > > > > firewall_enable paramater from my rc.conf since firewall_enable is set > > to NO in > > > > /etc/defaults/rc.conf. > > > > > > > > This did not have the intended result of disabling the firewall, rather > > a > > > > default deny was applied. If firewall_enable is set to NO, wouldn't it > > make > > > > more sense to have the init scripts set net.inet.ip.fw.enable to 0, or > > am I > > > > missing something? > > > > > > > > Opinions welcome. > > > > > > I think this is a valid point. When 'firewall_enable="NO"' the > > > firewalling should be disabled with the net.inet.ip.fw.enable > > > sysctl(8). > > > > > > That said, it _may_ be a little late to make this change in > > > -STABLE. Although the name may be misleading, I think the rest of the > > > documentation is accurate. Besides all the stuff people have quoted > > > about the 'options IPFIREWALL' in the kernel, I think rc.conf(5) is > > > fairly clear, > > > > > > firewall_enable > > > (bool) Set to ``YES'' to load firewall rules at > > startup. > > > If the kernel was not built with IPFIREWALL, the ipfw > > ker- > > > nel module will be loaded. See also ipfilter_enable. > > > > > > In that it only says special things happen when it is "YES" and > > > doesn't say it is explicitly disabled when set to "NO." Since this is > > > such a security critical option, I really hesitate when it comes to > > > changing this in -STABLE. -CURRENT OTOH... > > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > 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?000c01c1a5ff$a4539870$0101a8c0>