Date: Sat, 14 Oct 2000 11:32:01 +0200 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> To: freebsd-security@FreeBSD.ORG Subject: Re: Dynamic rc.firewall Message-ID: <20001014113200.H25237@speedy.gsinet> In-Reply-To: <20001013164231.S37870@jade.chc-chimes.com>; from billf@chimesnet.com on Fri, Oct 13, 2000 at 04:42:31PM -0400 References: <5.0.0.25.2.20001013032255.00a8ee40@127.0.0.1> <20001013191623.C25237@speedy.gsinet> <20001013164231.S37870@jade.chc-chimes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 13, 2000 at 16:42 -0400, Bill Fumerola wrote:
> On Fri, Oct 13, 2000 at 07:16:23PM +0200, Gerhard Sittig wrote:
>
> > > How can I have rc.firewall automatically pull in ip,
> > > netmask and network numbers from the currently configured
> > > interfaces.
> > >
> > > [ ... ]
> >
> > I don't know whether ipfw has a similar "alias", but in ipf
> > (which is available in FreeBSD, too) you can specify address
> > 0.0.0.0/32 in your rules when you mean "my current address on
> > this interface". Just make sure to issue "ipf -y" whenever
> > the interface address changes (ppp.linkup or the appropriate
> > dhcp client hook).
>
> < /home/billf # ipfw sh
> 00010 4 336 count ip from any to any via lo0
> 00020 4 336 count ip from any to any via 127.0.0.1
> 65535 1394368 292507478 allow ip from any to any
>
> Granted you can't just use this anywhere, but ipfw allows for a
> preprocessor.
Am I missing something when I feel the preprocessor to be of not
much help for a dynip environment? Let me sketch my "thought
model" of how such a packet filter works. Please correct me
where I'm wrong.
Whenever a packet arrives or leaves it gets checked against
certain criteria. These are held in some machine readable format
in kernel or user space (I assume tables of a format most
suitable for fast parsing). The admin never sees these tables
and cannot handle these directly.
These tables are formed / filled / manipulated by the programs
like ipfw(8) or ipf(8) or ipchains(8) or ipfwadm(8) or whatever
-- I don't see any difference here between all of these. These
command's input is the only point where an admin could (easily)
intervene. So you can feed the rule definition file through any
data mangling mechanism, before it gets into the "original"
filter frontend (ipfw/ipf) and makes it into the internal
representation.
But if this internal representation has no way of saying "the
current address of the interface" then you explicitely have to
write a rule for this interface every time it changes
configuration and you have to load the rule set or manipulate
single rules (depending on whether you can "number" rules and
manipulate single rules without affecting the others or the order
they're in).
It turns out the a "rule load time" vs "rule check time" issue.
I agree that a preprocessor in ipfw(8) makes life easier for the
admin and gives a chance to write the rule sets more readable
like this:
---------------------------------------------
#define MXHOST 1.2.3.4
...
add pass tcp from any to MXHOST 25 setup
...
---------------------------------------------
But it doesn't eliminate the need to feed another rule with the
interface's new IP into this "table manipulator" and maybe delete
the previous rule for this case (which reminds me of Linux and
the need of "run your firewall script again every time you
establish a ppp link with dynip" -- including the effects of
possibly disturbing other established connections, flushing rule
sets to build them anew, time windows with no known rule sets,
etc). It's more of a hack than a solution.
And the -p option in ipfw "only" saves the admin from one extra
step when loading rules and has him write
ipfw -p $CPP $DEFINES $RULES
instead of
$CPP $DEFINES < $RULES | ipfw
Admittedly the former is easier to handle with the FreeBSD
rc.conf style. :) Short of such an option one had to specify
another script as the fwcmd variable wrapping a preprocessor
around the actual fwcmd.
So -- can't we just have the best of both worlds with teaching
ipfw of the "my address" alias (think of ppp's HISADDR) and ipf
of a -p option? But I guess that would make admins' lives too
easy. :>
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-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001014113200.H25237>