Date: Tue, 29 Jan 2002 20:33:49 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: stable@FreeBSD.ORG Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <20020129203349.G1494@shell.gsinet.sittig.org> In-Reply-To: <20020128.151138.115627568.imp@village.org>; from imp@village.org on Mon, Jan 28, 2002 at 03:11:38PM -0700 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
On Mon, Jan 28, 2002 at 15:11 -0700, M. Warner Losh wrote:
>
> Loading ipfw is less secure than having it in the kernel, since
> there's a window at boot that packets can pass. 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).
The only reason I can come up with is the "ppp/nat" catchword.
Loading ipfw this late might be what saved ipfw users from
suffering from the "problem" in PR conf/22859. The issue seem
to be "suddenly appearing" or reconfigured interfaces (drivers
loaded on demand, ppp creating tun(4)s, and the like).
Should ipfw be loaded earlier it might need a method of synching
or reloading its ruleset very much like the "ipf -y" feature. Or
to do what I've seen in Linux land: run the firewall boot scripts
in ip-up and ip-down once more (/etc/ppp/ppp.link{up,down} in
FreeBSD speak), maybe passing a few parameters to restrict work
a little (only adjusting the PPP interface or something). That's
when default policies of accepting traffic might harm you when
the ruleset gets build multiple times while the machine is already
connected ...
> 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.
Regarding the default to block everything: it might not be the
default behaviour when only enabling the ipf kernel code or ipl
module. But there's a kernel option IPFILTER_DEFAULT_BLOCK
available and rc.network as well as rc.conf(5) even recommend its
use. (guess who wrote these comments :>)
> 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.
I just had a look at rev 1.119 of rc.network (-CURRENT). It
tries to activate ipfilter as soon as the admin wants ipf or
ipnat functionality. Then it checks for ipf code in the kernel
and (should the querying sysctl fail) tries to load ipl.ko.
Should this module loading fail, the admin's wishes are
overridden and no further ipf/ipnat/ipfs/ipmon command gets
issued. This should be safe. I read it that the ipf subsystem
only is used / configured if it is statically linked into the
kernel or could be loaded on demand. I don't see a problem here,
unless I missed something.
A quick look at rev 1.74.2.28 (-STABLE) makes me assume that the
logic is identical here, at least in the ipf respect.
Last "cvs up" in the above sandboxes was done last Thursday, but
I haven't noticed commit logs in cvs-all. So things should be
fine in ipf land. :)
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?20020129203349.G1494>