Date: Sun, 25 Mar 2012 18:57:22 -0700 From: Julian Elischer <julian@freebsd.org> To: Da Rock <freebsd-ipfw@herveybayaustralia.com.au> Cc: freebsd-ipfw@freebsd.org Subject: Re: newbie IPFW user - when handbook examples dont work... Message-ID: <4F6FCD02.6040001@freebsd.org> In-Reply-To: <4F6EC899.40407@herveybayaustralia.com.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.. > > 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. > > 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, >> >> >> 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' > > 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. there will be test next week :-) > _______________________________________________ > 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?4F6FCD02.6040001>