On 3/23/14, 7:56 AM, Brett Glass wrote:
At 11:33 PM 3/22/2014, Julian Elischer wrote:
in ipfw that's up to you..
but I usually put the check-state quite early in my rule sets.
I don't, because I want packets to touch as few rules as possible
for the sake of
efficiency. One "check state" can cause an awful lot of work to be
done!
check state is a hash ;ookup and generally doesn't cause a lot of work.
it's about the equivalent of 2 simple rules I would guess so if you
save two rules by using check state, then you win.
In my IPFW rule sets, I divide the work up by interface, and so
there's a
"check-state" only for interfaces and directions (in vs. out) to
which automatically
generated rules will apply.
I do the same. first thing my rule set does is break the packet flow
into N*4 separate sets of rules,
where N is the number of interfaces. Each interface gets two sets of
rules.. one for incoming
and one for outgoing. each of these it further divided into two
smaller sets. One for
packets that are for or from THIS machine, and one that is for packets
no for or from this machine)
incoming, for me
incoming NOT for me
outgoing from me
outgoing NOT from me
each of these sets can then have rules.
however since we know some of the information already it doesn't
need to be tested again so the rules there tend to be "from any to any"
because we already know who it's for (or from, depedning on the direction)
The problem is that this is still inefficient, because there's only
one batch of
automatically generated rules, containing some that will never apply
in certain
situations. My rule sets would be more efficient if I could divide
the automatically
created rules into multiple batches, and do "keep-state N" and
"check-state N" to check
only the batch that needed to be tested in a particular spot. This
ought to be a relatively
easy patch, and I've thought many times about coding and submitting
it. "N" would default
to zero, so the old behavior would be preserved if there was no "N"
at the end so as not
to violate POLA.
I am working on a new rc.firewall that is much more efficient.
the trouble is that the script to make it do what I want is a bit
more complicated.
I'll put it out for discussion later. maybe tonight.
Would like to see it!
see other emails for sample output.
--Brett Glass
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
