Date: Mon, 28 Jan 2002 15:26:43 -0700 From: Nate Williams <nate@yogotech.com> To: "M. Warner Losh" <imp@village.org> Cc: nate@yogotech.com, cjm2@earthling.net, stable@FreeBSD.ORG, n@nectar.cc Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <15445.53283.957773.221016@caddis.yogotech.com> In-Reply-To: <20020128.151138.115627568.imp@village.org> References: <1913.216.153.202.59.1012249133.squirrel@www1.27in.tv> <20020128.135120.11184725.imp@village.org> <15445.48617.802871.870971@caddis.yogotech.com> <20020128.151138.115627568.imp@village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'm most worried about the case where you have compiled ipfw into the
> kernel. When you do that, the default is don't route anything. I
> want to preserve that.
That's a tricky one. If we make the default to 'YES' (to preserve the
current behavior of enabled firewall in compiled in kernels), then the
firewall would get loaded by default on *every* setup, even if they are
currently not using a kernel.
> Loading ipfw is less secure than having it in the kernel, since
> there's a window at boot that packets can pass.
Except on those machines who don't use a 'standard' ipfw setup. IMO,
using the existing configuration/rc.conf setup, it's hard to get a
secure setup. You have to either modify /etc/rc.firewall (bad, since
you have to carefully merge in any mergemaster updates), or you have to
build your own customized scripts (again, that means you have to
hand-merge any updates to the stock /etc/rc.firewall.)
In short, the current 'status quo' doesn't work well for any but the
most simple firewall setup (using NAT). And, the default setup is both
ineffecient as well as insecure, IMO. (However, it's hard to be all
things to all people, because each firewall really needs to be
customized for the user's particular setup, hence some of the problems.)
> The problem with ipfw
> now is that if you don't have the default deny rule, there's a small
> window where you have packets passed. ipfilter is done much sooner in
> the boot process, so doesn't appear to suffer from this
> vulnerability. If possible, we should move ipfw to the same location
> as ipfilter (I suspect that it isn't there for some reason).
Agreed. What needs to occur is the firewall needs to be loaded *before*
the network devices are configured, to avoid this. Although, there is
still a *small* chance of something bad happen w/regards to ARP/DHCP
and/or broadcast packets. I'm not sure how paranoid we should be here.
> We'd also need to change ipfilter rules as well. It doesn't defaults
> to blocking everything and if you set ipfilter_enable to NO, you get
> that same behavior.
*urk*
> The ipfilter stuff also will blindly try to load the ipfilter rules,
> even if ipfilter isn't in the kernel and can't be loaded.
Ahh, so we'd be doing the same (broken) thing for ipfw. At least it
would be consistent. :) :)
> So leaving that aside for the moment, returning to ipfw stuff.
> firewall_enable is really firewall_rules_enable at the moment.
> Looking at the code closely, we see things like:
>
> case ${firewall_in_kernel} in
> 1)
> ... (indentation <<)
> case ${firewall_enable} in
> [Yy][Ee][Ss])
> if [ -r "${firewall_script}" ]; then
> ...
> elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then
> echo 'Warning: kernel has firewall functionality,' \
> 'but firewall rules are not enabled.'
> echo ' All ip services are disabled.'
> fi
> ...
> ;;
> esac
> ;;
> esac
>
> My understanding of what I want and what you want, rendered in code
> excerpt form is:
>
> # Initialize IP filtering using ipfw
> #
> if /sbin/ipfw -q flush > /dev/null 2>&1; then
> ipfw_in_kernel=1
> else
> ipfw_in_kernel=0
> fi
>
> case ${ipfw_enable} in
> [Yy][Ee][Ss])
> if [ "${ipfw_in_kernel}" -eq 0 ] && kldload ipfw; then
> ipfw_in_kernel=1
> echo 'Kernel firewall module loaded'
> elif [ "${ipfw_in_kernel}" -eq 0 ]; then
> echo 'Warning: firewall kernel module failed to load'
> fi
> ;;
> esac
This loads things automagically if 'firewall is enabled', and does
nothing if if the 'firewall isn't enabled'.
> case ${ipfw_in_kernel} in
> 1)
> ... (indentation <<)
> case ${ipfw_firewall_enable} in
All of the above is just safety code.
> *)
> if [ -r "${ipfw_script}" ]; then
> ...
> elif [ "`ipfw l 65535`" = "65535 deny ip from any to any" ]; then
> echo 'Warning: kernel has firewall functionality,' \
> 'but firewall rules are not enabled.'
> echo ' All ip services are disabled.'
> fi
Which doesn't help much if you are not sitting at the console, but you
be seen once you login and check the logfiles. (Been there, done that,
hence the reason for my passioned opinions on this subject. :)
> ...
> ;;
> [Nn][oO])
> echo 'Warning: kernel has firewall functionality,' \
> 'but user disabled it in /etc/rc.conf'
> echo ' All ip services are ENABLED'
> sysctl ... # turn off ipfw via sysctl
> ;;
> esac
>
> Is that right? Forget my old proposal for the moment (and do a
> s/firewall/ipfw/ on all the current firewall_ variables not
> specifically mentioned). We'd introduce a ipfw_firewall_enable.
>
> /etc/defaults/rc.conf would have:
>
> ipfw_enable=no
> ipfw_firewall_enable=yes
>
> Or in less shellese pseudo-code:
> in-kernel=`ask the kernel if there's ipfw`
> if !in-kenrel && ipfw_enable == yes
> load ipfw
> in-kernel=true
> endif
> if in-kenrel
> if ipfw_firewall_enable == no
> turn off ipfw
> else
> load rules, natd, etc.
> endif
> endif
> if in-kenrel
> if ipfw_firewall_enable == no
> turn off ipfw
> else
> load rules, natd, etc.
> endif
> endif
>
> ipfw_enable == Load ipfw if it isn't in the kernel.
> ipfw_firewall_eanble == turn ipfw on/off if it is in the kenrel.
>
> Comments?
Except the chicken/egg problem, I'm not sure how to get the old
'default' functionality and still allow someone to easily 'disable' the
kernel. (Again, I don't care for the ipfw_firewall_disable variable.
Also, the name is a bit redundant, but now I'm picking nits. :) :) :)
Nate
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?15445.53283.957773.221016>