Iptables initialization

Dagmar d'Surreal dagmar.wants at nospam.com
Mon Feb 16 11:58:23 PST 2004


On Sun, 2004-02-15 at 09:20, Tarek W. wrote:
> 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.
> (http://hipac.org/)

For the record, my comment about firewalling rules that are a waste of
CPU cycles was not an obsession over processor efficiency.  It was to
try to discourage people from thinking they should add rules without
specifying an interface for them because it's a sloppy practice and can
be painful to debug.

> 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.

Generally *because* internet traffic is so diverse, the sensible
solution is to start with a 'deny all' rule, and then allow acceptable
traffic through item by item, which makes for less trouble.

> 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
> fine).
> 
> 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

This is pretty self-evident.  Some of us have been waiting for that
feature for years now.

> 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.

Actually, stateful filtering can be abused by someone with the proper
know-how and physical access to the segment, but the benefits of using
this outweigh the added load of connection table lookups.

> 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.

It's all well and good to believe in the existence of rulesets, but you
should really be more specific.  I can't tell what you're talking about.

> 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.

There is no one ruleset that should be applied to everyone's machine, so
I don't know what it is you're intending to design.
-- 
The email address above is phony because my penis is already large enough, kthx. 
              AIM: evilDagmar  Jabber: evilDagmar at jabber.org




More information about the hlfs-dev mailing list