UFW-Like frontend for IPFW
Victor Sudakov
vas at mpeks.tomsk.su
Fri Mar 10 08:32:42 UTC 2017
Ian Smith wrote:
> >
> > > > There is one thing that a higher level macro language on top of ipfw
> > > > would be nice to have for.
> > >
> > > ipfw rules are very much like an assembly language, and 'assemble' to
> > > precisely executable opcodes in a well-defined virtual machine. pf feels
> > > (to me) more like 'higher level' coding, which seems to suit many people
> > > better .. but I'm an old assembler kind of guy, from S/370 onwards :)
> > >
> > > > Several times I have tried to emulate Cisco PIX/ASA logic with ipfw.
> > > > I just want to have e.g. 3 interfaces: inside, outside, dmz with
> > > > security levels of 100, 0, 50 respectively. Traffic can flow from the
> > > > interface with a higher security level to the interface with a lower
> > > > security level, and return traffic is permitted too.
> > > >
> > > > Every time I have tried to express this with ipfw rules, I failed
> > > > miserably, though superficially it looks simple (with keep-state).
> > >
> > > That's quite doable, but I wouldn't use numeric levels like that,
> >
> > When there are more than 2 interfaces, numeric levels are very useful.
>
> Sure, if you have some way to map these to interfaces and to define the
> allowable flows, but meanwhile I used those as method descriptors, which
> you'd already clearly enough defined for this particular application.
>
> > > and
> > > I'd use static rules first to limit access between inside, outside and
> > > dmz, adding dynamic (stateful) rules after those constraints are met.
> > >
> > > Just roughly, as a partial sketch, and assuming all at layer 3 (ip):
> > >
> > > check-state // pass established dynamic flows
> > >
> > > # can only check both interfaces on 'out' packets, leaving ipfw
> > > deny tcp from any to any out recv $dmz_if xmit $inside_if setup
> > > deny udp from any to any out recv $dmz_if xmit $inside_if
> > >
> > > # if dmz provides service/s to outside, skip over these for them
> > > # those can be allowed/denied on 'in' pass, using dest address/es.
> > >
> > > deny tcp from any to any out recv $outside_iface setup
> > > deny udp from any to any out recv $outside_iface
> > >
> > > # skip this for any static (setup then established) services below
> > > deny all from any to any established
> > >
> > > # best use static rules for icmp, see rc.firewall 'workstation'
> > >
> > > # then (or earlier, if you prefer) separate flows for inside|dmz
> > > # then allow services on inside and dmz, perhaps using static rules
> > > # then allow access from inside|dmz to dmz|outside statefully.
> >
> > Yes, that's basically what I usually come to.
> > But it would be much nicer to write a macro like that:
> >
> > nameif fxp0 outside security0
> > nameif fxp1 inside security100
> > nameif fxp2 dmz security50
> > permit tcp from any to any eq 80 in interface dmz
> > permit tcp from any to 10.10.5.1 eq 3389 in interface inside
> >
> > and to have all the gory details configured for you automagically.
>
> Well yes, but I think you'll find that non-trivial to do.
I have.
> If you come
> up with something, or enthuse somebody else to do so, I'll test it at
> least as far as scrutinising output rulesets.
>
> Perhaps start by declaring actual ipfw rules you expect such a syntax to
> produce from your example above; then figure out how to generate those?
Oh, if I could imagine the actual ipfw rules, I would have done this
long ago. Superficially, they should boil down to a bunch of rules like
check-state
permit ip from any to any in via XXX out via YYY keep-state
permit ip from any to any in via QQQ out via ZZZ keep-state
deny ip from any to any
but in practice, there is always some show-stopper.
> I can't recall when or where, but have seen an example using ipfw's
> preprocessor feature, using m4(1) to pre-process provided parameters to
> generate customised rulesets, to some degree at least.
>
> ipfw [-cfnNqS] [-p preproc [preproc-flags]] pathname
>
> See ipfw(8) /LIST OF RULES AND PREPROCESSING
Been there, done that. Using a shell script with loops and variables
for networks and interfaces turned out to be so much simpler than using a
preprocessor.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
AS43859
More information about the freebsd-questions
mailing list