Date: Tue, 27 Mar 2012 23:34:54 +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: <4F71C1FE.3090201@herveybayaustralia.com.au> In-Reply-To: <4F6FCD02.6040001@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> <4F6EC899.40407@herveybayaustralia.com.au> <4F6FCD02.6040001@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/26/12 11:57, Julian Elischer wrote: > On 3/25/12 12:26 AM, Da Rock wrote: >> 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? > > some examples (I've forgotten some I'm sure) > > used the 'fwd' rule and tables to implement multiple routing tables, > before I actually added multiple routing tables to the system. > > used level2 firewalling (plus some patches) to implement a transparent > firewalling bridge. > (a firewalling cable so to speak.) > > used fwd, (with some patches) to implement transparent redirection to > a web proxy. > > >>> >>> >>> 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. > That is in the man page.. Yep. But that didn't mean it registered... :) >> >> I'm assuming you can use tags like in pf? Would that work well in >> such an environment where it is all sectioned? > > I have never needed tags. But I know others that use them.. they do > add some overhead per packet. >> >> 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. > I have sets for each interface.. > so I can switch on firewalling and nat on each interface individually > for testing or if something goes wrong. > > A differnet NAT interface for each interface is also useful. > theoretically a single natd process can do multiple contexts at once > with different port numbers etc, > but the one time I tried it, it didn;t work so I switched to multiple > instances of natd. I have to look into how exactly that works yet. It sounds useful to my own needs in some way I haven't quite out > >> >> 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've used IPSEC successfully with home-grown tunnels using netgraph > ksocket nodes connected to netgraph ng_iface interfaces. Now that we > can have multiple stack instances it gets even more interesting, as > you can forward other jails to do tunnel encapsulation and such. > > the variety and number of options you have to achieve any task is > getting bewilderingly high. > for any task you can probably get 3 or 4 completely different > suggestions as to how it can be done, Amen to that! I'm still trying to sort through it all for my own needs. > > > >>> >>> >>> 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? > > As I said, I haven't really looked but I gather it's like a 'skipto' > except that you can 'return' Hmm, I think I see that - that would be extremely useful (especially considering my thoughts on using skipto before I knew it was only pass forward). > >> >> I'll be back with more questions I'm sure... Meanwhile I have to go >> and put this stuff into practice :) > > go read the man pages for ipfw, divert, netgraph (AND all it's module > types), the route command including the 'newish' setfib stuff, the > jail command with specific reference to having a separate complete > networking stack in each jail (including it's own firewall), (and > ifconfig vnet command), natd, ipfw nat options, mpd (a port)and ppp. > and as if that wasn't enough.. pf, tun, if_bridge, epair, gif, stf, > and I'm sure I forgot a bunch. I'm still going through it all (amongst other tasks), but I did come across one thing: why nat only ip4 (simple/client/open)? Isn't nat still a possibility on ipv6 (for one of the original reasons it was used on ip4- anonymity)? > > there will be test next week :-) I'll be ready :P > > > >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F71C1FE.3090201>