Date: Wed, 20 Oct 1999 12:51:15 -0400 From: "Patrick Bihan-Faou" <patrick@mindstep.com> To: "Dag-Erling Smorgrav" <des@flood.ping.uio.no> Cc: "matt" <matt@BabCom.ORG>, <freebsd-security@FreeBSD.ORG> Subject: Re: ipfw rule wrong in rc.firewall(?) Message-ID: <002001bf1b1b$52ea0a80$190aa8c0@local.mindstep.com> References: <19991020104749.B17206@relay.ucb.crimea.ua> <Pine.BSF.4.20.9910200503320.40234-100000@s01.arpa-canada.net> <009001bf1b08$05ad6040$190aa8c0@local.mindstep.com> <xzppuyahxyn.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
----- Original Message -----
From: Dag-Erling Smorgrav <des@flood.ping.uio.no>
> "Patrick Bihan-Faou" <patrick@mindstep.com> writes:
> > I guess it would add a couple of keywords in the lines of:
> >
> > ipfw add allow udp from ${oip} to any 53 monitor 10
> > ipfw add allow udp from any to any established
> > ipfw add deny udp from any to any
> >
> > where "monitor" indicates that we want to allow the return data flow, 10
is
> > a time-out value (packets must be no more that 10 seconds apart from one
> > another).
>
> Sounds like a good idea, but you may want to do something a little bit
> more fancy than just accepting the packets unconditionally.
>
> If you teach ipfw the notion of temporary rules (add a ttl field to
> the rule structure, and remove the rule when the ttl reaches 0), the
> effect of a "monitor" rule would simply be to add a temporary rule
> with a preselected rule number. That way, you can view and delete
> automagic rules manually. You might also want to have those automagic
> rules be 'skipto' rules rather than 'allow' rules, so you can do
> arbitrarily complex processing of those packets.
I was more thinking of something like:
ipfw add <action> <proto> <from> <to> monitored
Here the keyword "monitored" (with a 'd'...) indicates where the packets
matching the monitored connection list should be handled.... Sort of like
the "established" keyword for TCP... This is why I wrote "established" for
the UDP rule. Because in a way that feature extends the meaning of
"established" beyond the scope of TCP sessions.
Which is to say the keyword "established" indicates that ipfw can, by one
mean or another, verify that the packet is part of a session. This leaves as
much flexibility as one may want (or at least close enough), while not
requiring major architecture changes in ipfw (sort of)...
Of course the problem of removing "established/monitored" connections is not
dealt with. Is it really a concern ?
Now that I think of it, "monitored" might be a better word than
"established" since the type of checking (which could be also applied to TCP
connections) is somewhat stricter thant the "established" keyword for TCP
(which relies on trust of the TCP header).
As far as coding goes, I would find it fun to work on that. So if you do not
have too much time to look at it, let me do some mods and submit them later
(I am talking of a couple of weeks time frame).
Patrick.
--
Patrick Bihan-Faou
MindStep Corporation
www.mindstep.com
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?002001bf1b1b$52ea0a80$190aa8c0>