Date: Fri, 25 Jan 2002 19:05:52 -0800 From: "Crist J. Clark" <cjc@FreeBSD.ORG> To: "Thomas T. Veldhouse" <veldy@veldy.net> Cc: Patrick Greenwell <patrick@stealthgeeks.net>, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <20020125190552.E14394@blossom.cjclark.org> In-Reply-To: <000c01c1a5ff$a4539870$0101a8c0@cascade>; from veldy@veldy.net on Fri, Jan 25, 2002 at 06:23:12PM -0600 References: <20020124201411.A39351-100000@rockstar.stealthgeeks.net> <20020124220302.N87663@blossom.cjclark.org> <002b01c1a5a7$67200e00$3028680a@tgt.com> <20020125160846.A14394@blossom.cjclark.org> <000c01c1a5ff$a4539870$0101a8c0@cascade>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 25, 2002 at 06:23:12PM -0600, Thomas T. Veldhouse wrote:
>
> > 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.
But the current behavior of the two is inconsistent if
'firewall_enable="NO".' If you have a staticly compiled firewall, you
have a brick. If you don't you have a wide-open machine. The change
would make it wide open in both cases. That is, when you do not have
firewall_enable enabling firewalling, you don't have a firewall. (period)
> > > 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.
I never said there was anything keeping you off the console. It's a
brick with a head.
> > 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.
They work, but I think they can work better. Having
'firewall_enable="NO"' when you have a built-in firewall is
essentially a useless configuration knob. Almost everyone needs to set
it to "YES" to have a useable system. Why not give "NO" a useful
functionality? Since everyone with a built-in firewall has it already
set it to "YES", I don't see a great security impact in changing the
behavior of "NO". That is, people are not going to do a mergemaster(8)
on a configured system and have their policy changed without their
knowledge. The argument that "NO" should by default lock people out of
their systems unless they know better goes both ways. One can just as
easily say that if they should know better, they should know that you
need to have 'firewall_enabled="YES"' for the firewall to be enabled.
But there may be people running systems out there with
'firewall_enable="NO"' and compiled-in firewalls. Because I can't
think of a workable configuration that would be set up this way, it
doesn't mean there are not any. This is what makes me hesitant about
changing it. However, I haven't seen any evidence so far that such
systems exist.
--
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?20020125190552.E14394>