Date: Sun, 25 Mar 2012 17:26:17 +1000 From: Da Rock <freebsd-ipfw@herveybayaustralia.com.au> To: freebsd-ipfw@freebsd.org Subject: Re: newbie IPFW user - when handbook examples dont work... Message-ID: <4F6EC899.40407@herveybayaustralia.com.au> In-Reply-To: <4F6EA84D.1010604@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F6EC899.40407>