From owner-freebsd-questions@freebsd.org Fri Mar 10 08:32:42 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CEBA1D0467E for ; Fri, 10 Mar 2017 08:32:42 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) Received: from relay2.tomsk.ru (mail.sibptus.tomsk.ru [212.73.124.5]) by mx1.freebsd.org (Postfix) with ESMTP id 0D63B1706 for ; Fri, 10 Mar 2017 08:32:41 +0000 (UTC) (envelope-from vas@mpeks.tomsk.su) X-Virus-Scanned: by clamd daemon 0.98.5_1 for FreeBSD at relay2.tomsk.ru Received: from [212.73.125.240] (HELO admin.sibptus.transneft.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 5.1.16) with ESMTPS id 39634519; Fri, 10 Mar 2017 14:28:10 +0600 Received: from admin.sibptus.transneft.ru (sudakov@localhost [127.0.0.1]) by admin.sibptus.transneft.ru (8.14.9/8.14.9) with ESMTP id v2A8WcR7015718; Fri, 10 Mar 2017 15:32:38 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) Received: (from sudakov@localhost) by admin.sibptus.transneft.ru (8.14.9/8.14.9/Submit) id v2A8WXSH015714; Fri, 10 Mar 2017 15:32:33 +0700 (KRAT) (envelope-from vas@mpeks.tomsk.su) X-Authentication-Warning: admin.sibptus.transneft.ru: sudakov set sender to vas@mpeks.tomsk.su using -f Date: Fri, 10 Mar 2017 15:32:33 +0700 From: Victor Sudakov To: Ian Smith Cc: Polytropon , Michael Wilcox , freebsd-questions@freebsd.org Subject: Re: UFW-Like frontend for IPFW Message-ID: <20170310083233.GA15405@admin.sibptus.transneft.ru> References: <20170307233222.E87835@sola.nimnet.asn.au> <20170308122925.GA67654@admin.sibptus.transneft.ru> <20170309023112.M80813@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170309023112.M80813@sola.nimnet.asn.au> Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://www.dreamwidth.org/pubkey?user=victor_sudakov X-PGP-Fingerprint: 10E3 1171 1273 E007 C2E9 3532 0DA4 F259 9B5E C634 User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 08:32:42 -0000 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