newbie IPFW user - when handbook examples dont work...
Da Rock
freebsd-ipfw at herveybayaustralia.com.au
Tue Mar 27 13:34:56 UTC 2012
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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>>
>>
>
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
More information about the freebsd-ipfw
mailing list