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 :)
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
