From owner-freebsd-questions@freebsd.org Wed Mar 8 12:29:31 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 7EEE8D0242A for ; Wed, 8 Mar 2017 12:29:31 +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 A28511281 for ; Wed, 8 Mar 2017 12:29:29 +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 39632576; Wed, 08 Mar 2017 18:24:59 +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 v28CTSrF067764; Wed, 8 Mar 2017 19:29:28 +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 v28CTPXU067763; Wed, 8 Mar 2017 19:29:25 +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: Wed, 8 Mar 2017 19:29:25 +0700 From: Victor Sudakov To: Ian Smith Cc: Polytropon , Michael Wilcox , freebsd-questions@freebsd.org Subject: Re: UFW-Like frontend for IPFW Message-ID: <20170308122925.GA67654@admin.sibptus.transneft.ru> References: <20170307233222.E87835@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170307233222.E87835@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: Wed, 08 Mar 2017 12:29:31 -0000 Ian Smith wrote: [dd] > > 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. > 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. > > > Has anyone done this? > > More or less :) My firewalls are mostly static rules, but stateful > rules in this instance are likely simpler. Don't be too entranced by > statefulness; there are cases (icmp, sometimes DNS, ssh perhaps) where > static rules make more sense, and don't suffer from timeouts etc. > -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN AS43859