From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 25 07:26:20 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8F4BD106564A for ; Sun, 25 Mar 2012 07:26:20 +0000 (UTC) (envelope-from freebsd-ipfw@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id 05EEF8FC08 for ; Sun, 25 Mar 2012 07:26:19 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.182]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id 9BDAF5C22 for ; Sun, 25 Mar 2012 17:39:52 +1000 (EST) Message-ID: <4F6EC899.40407@herveybayaustralia.com.au> Date: Sun, 25 Mar 2012 17:26:17 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> <20120325013410.H2060@sola.nimnet.asn.au> <4F6E7E39.8080805@herveybayaustralia.com.au> <4F6EA84D.1010604@freebsd.org> In-Reply-To: <4F6EA84D.1010604@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 07:26:20 -0000 On 03/25/12 15:08, Julian Elischer wrote: > On 3/24/12 7:08 PM, Da Rock wrote: >> On 03/25/12 02:56, Ian Smith wrote: >>> On Sat, 24 Mar 2012, Da Rock wrote: >>> > On 03/18/12 02:31, Julian Elischer wrote: >>> > > On 3/17/12 1:36 AM, Da Rock wrote: >>> > > > On 03/14/12 17:09, Rémy Sanchez wrote: >>> > > > [everything deleted].. > > > ok I'm going to write a little blurb here, as someone who has, > 1/ contributed to ipfw > 2/ written python code to manipulate ipfw real-time (for code running > in cisco appliances.. guess which ones) > 3/ used it for many weird things at many times. If I may ask, what kind of weird things and how? > > > here are my rules for using ipfw.. > > 1/ always use a script to make your firewalls.. > start by siabling everything > end by re-enabing > comment extensively > > 2/ as soon as you start, split your flows to different rule ranges. > even if that means duplicating rules... Once you have a set of rules for > "incoming rules on re0" you never have to spend cpu cycles testing "in > recv re0" > on any further rules. It also means you don't have to think of every > run of rules > from the perspective of several different flows. > > yes you may have 7 different sets of rules if you have 3 interfaces > and lo0, but > you won't go insane. Inside rulesets can just be "allow ip from any > to any" if you trust your inside interfaces. > > 3/ get really familiar with all the things you can do with tables. > e.g. skipto tablearg/ > > 4/ use skipto creatively but remember you can oly skip forwards. > > 5/ remember that keep-state rules, when matched will duplicate > whatever the original did > so .... skipto 1000 ip from a to b keep-state will skip to 1000 > whenever the state matches. > this can lead to some really creative rulesets. > > 6/ when using NAT remember that rules before and after NAT are looking > at different packets and > that rules before nat are in local addresses going out but external > addresses coming in, and teh opposite for after NAT. I always try > catch incoming sessions that are actuallydestimed for the local > machien before NAT so that my incoming sessions and local services > still work if NAT fails. Wow! That is really helpful. Why isn't *that* in the handbook? I had considered breaking everything up into sections and using skipto, but I _hadn't_ picked up on the fact that you can only go forwards- good catch there. I'm assuming you can use tags like in pf? Would that work well in such an environment where it is all sectioned? When you speak of sets, how are they used? Are you using the sets feature mentioned in the man ipfw(8)? I'm still a little confused on how these would be used as yet, but I intend to investigate further because the comments in the man page intrigued me in the reference to "hot swapping" sets on an attacked firewall to further close it up. As for my motto: "dont trust anyone." So I disable all and only let in what is required under strict conditions- even on the internal interfaces. This is a test scenario atm though, and I will set about locking it all up and implementing a production setup *if* IPSec works. > > > I have not yet used the new 'subroutine' functionality in current but > am looking forward > to playing with it. That sounds interesting. How would that work? Are we talking about a switch from old procedural-like to more OO-like? I'll be back with more questions I'm sure... Meanwhile I have to go and put this stuff into practice :)