UFW-Like frontend for IPFW

[Ian Smith]

On Fri, 10 Mar 2017 15:32:33 +0700, Victor Sudakov wrote:
 > Ian Smith wrote:
[..]
 > >  > > 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
[..]
 > >  > >     # 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.

As would I, which is why I'm not even considering attempting it :)

 > > 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.

Well, this would involve crafting some distict 'blocks' of rules for 
specific functions - subroutines with parameters, if you like - that 
will each be far more complex than your hoped-for simplicity above.

And you'll need thorough knowledge of how works ipfw(8).  e.g. 'in' and 
'out' are mutually exclusive, "(in fact, out is implemented as not in)", 
and as noted above, both interfaces can only be tested on the way 'out'.

So you really do need to know what you want to do a) on packets into 
ipfw (from each interface) and, for those packets that were accepted in, 
b) on packets on the outbound pass - which may include packets generated 
on this box, having no recv interface - again for each interface, while 
incorporating your desired security boundaries by zones.

 > > 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.

Fair enough.  However, you've set yourself a genuinely difficult task, 
not so much for a specific set of circumstances such as you described, 
but especially for any more generalised 'macro' sense.

Good luck!  When in doubt, log every rule - at least while testing!

cheers, Ian