Date: Wed, 18 Apr 2007 14:08:05 -0700 From: Julian Elischer <julian@elischer.org> To: Julian Elischer <julian@elischer.org> Cc: ipfw@freebsd.org Subject: Re: ipfw changes being contemplated.. Message-ID: <462688B5.9080305@elischer.org> In-Reply-To: <46268689.1080301@elischer.org> References: <46268689.1080301@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > I'm contemplating the following changes to functionality: > I'd like suggestions and comments... > > 1/ Commit capability > In this change you declare a new firewall, > and modify/build it, and then you 'commit' it so that > the whole change is atomic. > I have a current bug at work where automatic changes are made to teh > firewall, but sometimes packets can arrive > between parts of a change and lead to odd behaviour. > For example if I have a reset rule after a skipto, and as part of the > change I replace the skipto with something else, > then for a moment, teh reset it exposed before the new rule is put in. > this leads to a spurious reset being sent out and terminating a > perfectly innocent session. I can code around these sorts of things > but I'd like to do: > > ipfw duplicate to 1 # make rule list 1 a copy of the current rules > ipfw rules 1 delete 1000 > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > > > or > ipfw new 1 # make rule list 1 a copy of the current rules > ipfw rules 1 add 1000 skipto 2000 tcp from any to me ... > ... (400 other changes) > ipfw commit 1 > rules that are unchanged would maintain their statistics. > > possibly I would not need a rule list number if the ipfw program > would automatically write to the existing set if there is no new (or > duplicate) rule list, but would manipulate the 'growing' list > if it exists. (that way keeping the new behaviour as a superset > of the old behaviour). > > 2/ implements some local registers for each packet run. > As each packet traverses the firewall the rules can assign > values to some registers, which can be used to make decisions later. > e.g. > ipfw add 1000 loadregister 1 tablearg ip from any to table (2) > ipfw add 2000 skipto 3000 register 1 gt 100 > > > 3/ 'computed goto' (fortran name) > ipfw add 1000 skipto tablearg tcp from 1.1.1.1 to table (1) > 4/ tablearg to get an optional table number.... > if a rule has 2 tables we need to be able to specify which. > > 5/ > ability to have multiple firewalls.. (extension of (1)) > ipfw new 1 ipfw rules 1 add .... > .... > ipfw commit 1 bridge "bridge0" > > different rule sets for different entry points. > ethernet layer (Layer2), IP output, bridging, IP input, different > input interfaces? > > 6/ corrolory of 5 > ability for one firewall to call into another.. > ipfw new 2 ipfw add [IP tests] > > > ipfw new 1 > ipfw rules 1 add 1000 check rules 2 mac-type ipv4 > commit 2 bridge > > > > The syntax is not set on these. This is just to get ideas out there. > so I'm up for a discussion. p.s. this goes along with a planned internal change that changes the way ipfw locking is done. BLUESKY: Also One possibility of 6 would be to make a family of firewalls rather than one, that work together, e.g. L2FW (layer 2 firewall) that knows about MAC packets etc but calls IPFW for ip packets should it want to do so. IPFW in turn the ability to call TCPFW for some sessions and TCPFW would know about modules that in turn know about different protocols. IPFW could be called from the IP layer, or from the FW of a lower layer. each layer would have the ability to do some inspection of the payload to help decide which higher layer might be relevant. I can imagine an HTTPFW which does some small tests and if it needs to can divert the session to a proxy. It would know some basic rules of HTTP. for example. > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?462688B5.9080305>