mailinglists1 at hotpop.com
Sun Feb 15 07:20:01 PST 2004
this was written two days ago, however my conn has been very unreliable,
anyway, here goes:
On Fri, 2004-02-13 at 00:54, Dagmar d'Surreal wrote: [snipped]
> Since in the LFS-bootscripts firewalling is not atomically tied to the
> starting of the network (and trust me on this, trying to do it on a
> per-interface basis is not a clean solution... been down that road and
> came back tired) we're in somewhat better shape than we could
> be--however, solving this issue appears to require doing some things
> differently than I had initially hoped for, and it's going to require
> adding some new functionality to _many_ of the init.d scripts. I've
> just about got this all solved, but I want to see if there are any fresh
> ideas to this end before I publish my solutions because someone just
> might come up with something unique and useful.
> Mind you, what folks should be thinking about is a generic method (i.e.,
> a best practice) for implementing firewalling rulesets, not a list of
> specific firewall rules that people should use.
> (hint: firewalling rules that won't match are a waste of CPU cycles)
a quick reply to the last point... depending on the setup, performance
(bandwidth) starts to suffer around 30Mbit/s for a packet size of
128bytes *and* when packets go through 25 successive rules.
this has two implications since internet traffic is the most diverse,
rules filtering it will be more numerous and since in most setups if not
all, 30Mbit/s is way over the internet bandwidth a firewall/gateway 1)
will be inspecting, we have more leeway in terms of number of rules. 2)
on the lan side, where data transfers reach higher speeds it would be
pretty easy to cut down on the number of rules.
also, intelligent rule positioning is crucial and lots of tricks exist
to decrease the number of rules visited by a packet, such as splitting
the filtering between -t filter and -t nat (which is recommended
against, but if some redundancy in -t filter is added, it should be
now, nobody mentioned stateful firewalling, which is the big thing in
netfilter compared to earlier implementations. with that, there is
simply no excuse for *not* using a block all, allow needed approach.
and what stateful brings too, is a decrease in the number of rules being
matched against with a careful positioning of -m state
ESTABLISHED[,RELATED] in the tree structure.
now, somebody with extensive experience in iptables will tell u it is
possible to restrain rules to a certain number whatever the
setup/requirements might be. so that's a moot point.
as for rulesets... I don't think there should be multiple rulesets
depending on the interfaces up. one ruleset can apply to all situations
with some amount of abstraction in the "tree". an addition of one or two
rules before an interface is brought up is the maximum to be expected in
a good ruleset.
in short, I think one ruleset should be living in memory before any
interfaces != lo r brought up. then before each new interface is brought
up 1/2 rules should be injected by the script, so massive redesign of
the scripts shouldn't be needed. regardless of how we go with this,
1/multiple rulesets, can't see why sysvinit scripts should undergo a
massive redesign. even in the case where we would want to modify a
ruleset on a daemon starting. work can be done on a script similar to
/sbin/service in redhat.
in any case, I will take a look at what the hlfs book has on this, I
also volunteer to design the ruleset. my credentials will be provided at
a later date if the idea is appealing to the group.
More information about the hlfs-dev