Date: Thu, 21 Oct 1999 16:26:30 +0200 From: Tim Priebe <tim@iafrica.com.na> To: "Patrick Bihan-Faou" <patrick@mindstep.com>, "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: <99102217281409.25232@310.priebe.alt.na> References: <002001bf1b1b$52ea0a80$190aa8c0@local.mindstep.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Oct 1999, Patrick Bihan-Faou wrote:
> 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).
What I would like to look at doing after you have done this, is to look at a
way of having 2 or more firewalls share this state information. I have a client
that is very serious about redundancy, and it was by showing them that I could
setup 2 firewalls, and dynamic routing, for mutch less than the cost of a
single commercial firewall, that was the final argument that finally got FBSD
onto the network. I liked the state info in ipfilter, but it would have caused
my present setup not to work.
Tim.
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?99102217281409.25232>