* Performance isues related to a large number of iptables rules
@ 2005-01-13 22:45 henry
2005-01-13 23:14 ` Jan Du Caju
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: henry @ 2005-01-13 22:45 UTC (permalink / raw)
To: netfilter
I am curious what is the maximum number of iptable rules that can be
installed in a config before performance starts to be a problem. I have
looked into the possibility of using firewall rules to block "bad"
networks, but I have been told by most people that I have asked that
this is bad idea.
Here are my thoughts. If a packet matches the 3rd rule, does it matter
if there are 100,000 rules below it? 1,000,000 rules below it? If it
doesn't, then does the number of allowable rules really have to do with
how intelligently the rules are written, and more specifically, in what
order?
For ban lists, if for example we wanted to allow everyone access to port
80, except a list of bad networks, we would obviously have to put a rule
to allow all connections on port 80 bellow our reject rules, otherwise
iptbales would never get to the ban rules. So lets say that we have
50,000 rules, 99% of them being reject rules, with a rule to allow port
80 to all hosts at the bottom, and a rule to allow RELATED,ESTABLISHED
packets at the top. When a host connects to us on port 80, iptables will
have to go though all 50,000 rules (assuming this host doesn't match one
of the reject rules) until it gets to the last one and decides to allow
the packet. But then, subsequent packets will have a state of
ESTABLISHED, and so they will match the first rule. In this case, only
the first packet of most sessions will the firewall have to do a lot of
work. Does this make any sense?
It seems to me, that for a reasonably powerful box, processing a large
number of rules on what would become a small total percentage of packets
shouldn't be a problem. Does anyone know what the real numbers are, and
what numbers are feasible and what numbers aren't?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Performance isues related to a large number of iptables rules
2005-01-13 22:45 Performance isues related to a large number of iptables rules henry
@ 2005-01-13 23:14 ` Jan Du Caju
2005-01-13 23:31 ` R. DuFresne
2005-01-14 1:32 ` Samuel Jean
2 siblings, 0 replies; 4+ messages in thread
From: Jan Du Caju @ 2005-01-13 23:14 UTC (permalink / raw)
To: henry; +Cc: netfilter
Hi,
On Thu, Jan 13, 2005 at 05:45:34PM -0500, henry wrote:
> I am curious what is the maximum number of iptable rules that can be
> installed in a config before performance starts to be a problem. I have
> looked into the possibility of using firewall rules to block "bad"
> networks, but I have been told by most people that I have asked that
> this is bad idea.
>
> Here are my thoughts. If a packet matches the 3rd rule, does it matter
> if there are 100,000 rules below it? 1,000,000 rules below it? If it
> doesn't, then does the number of allowable rules really have to do with
> how intelligently the rules are written, and more specifically, in what
> order?
If you want to deal with large rule sets and/or high bandwidth you should
definitely consider hipac (http://www.hipac.org)
Quoted from the hipac web-site:
iptables, like most packet filters, uses a simple packet classification
algorithm which traverses the rules in a chain linearly per packet
until a matching rule is found (or not). Clearly, this approach lacks
efficiency. As networks grow more and more complex and offer a wider
bandwidth linear packet filtering is no longer an option if many rules
have to be matched per packet. Higher bandwidth means more packets per
second which leads to shorter process times per packet.
With nf-HiPAC we offer a novel framework for packet classification
which uses an advanced algorithm to reduce the number of memory lookups
per packet. It is ideal for environments where large rulesets and/or
high bandwidth networks are involved. Thereby, the iptables' semantics
of the rules is preserved, i.e. you can construct your rules like
you're used to. From a user's point of view there is no need to
understand anything about the HiPAC algorithm.
At the hipac site you will find a comparison with iptables. The central
firewall of our university ( http://www.kuleuven.ac.be/english/ ) uses
hipac and we are very pleased with it. At the moment there is only an
implementation for a 2.4 kernel but the developers are working on a
2.6 version :-)
Hope this helps,
Jan
--------------------------------------------------- KULeuvenNet -------
Jan.DuCaju@kuleuven.net http://www.kuleuven.net/e_index.html
K.U.Leuven http://www.kuleuven.ac.be/english/
LUDIT - KULeuvenNet http://ludit.kuleuven.be/index_en.html
de Croylaan 52A 3001 Leuven Belgium
-----------------------------------------------------------------------
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Performance isues related to a large number of iptables rules
2005-01-13 22:45 Performance isues related to a large number of iptables rules henry
2005-01-13 23:14 ` Jan Du Caju
@ 2005-01-13 23:31 ` R. DuFresne
2005-01-14 1:32 ` Samuel Jean
2 siblings, 0 replies; 4+ messages in thread
From: R. DuFresne @ 2005-01-13 23:31 UTC (permalink / raw)
To: henry; +Cc: netfilter
Conventional firewalling, places rules in a number of places, not just the
firewall, for one, most folks seem to have forgotten the term 'screening
router' these days. This is the place to put rules that do things like
place anti-spoofing rules, rules for traffic that should always not be
allowed to pass <i.e. filtering out windows related protocols and ports,
etc>. ingress and egress filters can also be placed here.
There's another problem with large rulesets beisde preformance issues,
they get to be overtly complex and hard to follow and change. Breaking up
the rules upon a screening router<s>. Additionally, there's no reason a
site needs merely one firewall, the DMZ can have a seperate firewall for
those servers and services open to the public that should not hit the
internal network <or these systems can have specific host based firewalls
to address their specific needs and services>. behind the screening
router and or main firewall <which can be a sub-screening router> subnet
or switch specific firewalls can deal with traffic specific to those
systems housed therein.
Having worked at a few places that managed firewalls for the corporate 500
world, we found that overtly large rulesets tended to turn a firewall into
merely an open routed env...and often was the result of a failure to
properly assess the sites security policy structurally. In otherwords the
policy was often far too fluid to get a handle on ahd seemed to change
weekly or bi-weekly.
Thanks,
Ron DuFresne
On Thu, 13 Jan 2005, henry wrote:
> I am curious what is the maximum number of iptable rules that can be
> installed in a config before performance starts to be a problem. I have
> looked into the possibility of using firewall rules to block "bad"
> networks, but I have been told by most people that I have asked that
> this is bad idea.
>
> Here are my thoughts. If a packet matches the 3rd rule, does it matter
> if there are 100,000 rules below it? 1,000,000 rules below it? If it
> doesn't, then does the number of allowable rules really have to do with
> how intelligently the rules are written, and more specifically, in what
> order?
>
> For ban lists, if for example we wanted to allow everyone access to port
> 80, except a list of bad networks, we would obviously have to put a rule
> to allow all connections on port 80 bellow our reject rules, otherwise
> iptbales would never get to the ban rules. So lets say that we have
> 50,000 rules, 99% of them being reject rules, with a rule to allow port
> 80 to all hosts at the bottom, and a rule to allow RELATED,ESTABLISHED
> packets at the top. When a host connects to us on port 80, iptables will
> have to go though all 50,000 rules (assuming this host doesn't match one
> of the reject rules) until it gets to the last one and decides to allow
> the packet. But then, subsequent packets will have a state of
> ESTABLISHED, and so they will match the first rule. In this case, only
> the first packet of most sessions will the firewall have to do a lot of
> work. Does this make any sense?
>
> It seems to me, that for a reasonably powerful box, processing a large
> number of rules on what would become a small total percentage of packets
> shouldn't be a problem. Does anyone know what the real numbers are, and
> what numbers are feasible and what numbers aren't?
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
admin & senior security consultant: sysinfo.com
http://sysinfo.com
...Love is the ultimate outlaw. It just won't adhere to rules.
The most any of us can do is sign on as it's accomplice. Instead
of vowing to honor and obey, maybe we should swear to aid and abet.
That would mean that security is out of the question. The words
"make" and "stay" become inappropriate. My love for you has no
strings attached. I love you for free...
-Tom Robins <Still Life With Woodpecker>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Performance isues related to a large number of iptables rules
2005-01-13 22:45 Performance isues related to a large number of iptables rules henry
2005-01-13 23:14 ` Jan Du Caju
2005-01-13 23:31 ` R. DuFresne
@ 2005-01-14 1:32 ` Samuel Jean
2 siblings, 0 replies; 4+ messages in thread
From: Samuel Jean @ 2005-01-14 1:32 UTC (permalink / raw)
To: henry; +Cc: netfilter
henry wrote:
> Does anyone know what the real numbers are, and
> what numbers are feasible and what numbers aren't?
>
Not me. But if blocking large amount of subnets and host addresses is
your issue here. Only one rule is sufficient. See ipset 2.0
http://people.netfilter.org/kadlec/ipset/
Sorry if am out of topic.
Samuel
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-01-14 1:32 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-13 22:45 Performance isues related to a large number of iptables rules henry
2005-01-13 23:14 ` Jan Du Caju
2005-01-13 23:31 ` R. DuFresne
2005-01-14 1:32 ` Samuel Jean
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.