ram and processor cycles for a firewall machine
1100100 at gmail.com
Mon Oct 4 01:20:37 CEST 2004
Sorry for the slow response.
My thanks also to Jason, Daniel, and Aleksandar for their thoughtful responses.
Joining this list and perusing others' daily networking/routing issues
has been a huge wake-up call to me.
I'm very thankful for this community of developers, admins., and users.
On Sat, 2 Oct 2004 12:19:27 +0600, Askar <askarali at gmail.com> wrote:
> Thanks Jason, Aleksandar now the things kinda clear to me about the
> magic of "optimize" a ruleset :)
> On Fri, 01 Oct 2004 16:09:03 -0500, Aleksandar Milivojevic
> <amilivojevic at pbl.ca> wrote:
> > Mike wrote:
> > > Me too--- I'd like to learn what it means to optimize my iptables.
> > > After using iptables for 2 years but never really taking the time to
> > > digest what it means to filter data across tables, I'm trying to
> > > really understand what's going on. I've started with Oskar
> > > Andreasson's tutorial, but I definitely don't see anything about
> > > optimization in there.
> > It can mean many things, and depends on actual configuration and needs.
> > Idea behind optimization is to minimize average number of rules that
> > packets will traverse.
> > Simple example could be if you have bunch of rules with "-m state
> > --state NEW" and than somewhere at the end you have catch-all "-m state
> > --state ESTABLISHED", moving that rule to the top will make huge
> > difference (because majority of packets will be matched by it).
> > On a very bussy site with simple set of rules (but huge number of
> > simultanious connections) eliminating connection tracking could increase
> > performance (if traversing couple of rules is faster than lookup into a
> > huge table, of course). I don't know how connection tracking table is
> > organized and how the entries are looked up, so don't ask me for a
> > numbers when it makes sense not to use connection tracking, but majority
> > of people probably wouldn't benefit from turning it off. However, do
> > note that this will be tradeoff between performance and security.
> > Another example is if you have bunch of rules allowing access to service
> > only from certain IP addresses (say there's 20 of them). Creating user
> > defined chain for that service (for example -p tcp --dport 80 -j HTTP),
> > and than checking if packet is from one of 20 allowed IP addresses means
> > that all other packets will have to be checked only by 1 rule, not by 20
> > of them. Or you can go the other way around, if you are checking single
> > IP address agains number of services (in this case using multiport
> > module can be usefull too). Something like -s a.b.c.d -j CLIENT_A.
> > These are just some simple and obvious examples. The idea is to
> > minimize number of checks that need to be done on a packet before it is
> > accepted or dropped. Obviously, what can be done differs from one
> > config to another.
> > P.S.
> > Offtopic: seems that Google mail is becoming quite popular on the
> > mailinglist...
> > --
> > Aleksandar Milivojevic <amilivojevic at pbl.ca> Pollard Banknote Limited
> > Systems Administrator 1499 Buffalo Place
> > Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
> (after bouncing head on desk for days trying to get mine working, I'll make
> your life a little easier)
More information about the netfilter