| Author |
Message |
henry
Guest
|
 Posted:
Wed Jan 12, 2005 1:49 am Post subject:
Max iptables rules? |
|
|
Does anyone know what is the maximum number of firewall rules that be
loaded at a time in iptables?
I am working on writing a perl firewall script that loads groups of
networks from a database and applies polices to them using ibtables. It
is working well as of now with several thousand rules installed and
running. I am wondering what performance issues might arise as the
database grows and more rules are installed. Is there a set limit which
iptables will not allow any new rules to be installed? Is there a
performance threshold that will arise around a certain number of rules?
I have searched the web for this, and can't seem to find any information
regarding number of rules that can be installed in iptables. This is for
the 2.6 kernel. If anyone knows it would be much appreciated, thanks... |
|
| Back to top |
|
 |
Wolfgang Kueter
Guest
|
| Posted:
Wed Jan 12, 2005 5:23 am Post subject:
Re: Max iptables rules? |
|
|
henry wrote:
| Quote: | Does anyone know what is the maximum number of firewall rules that be
loaded at a time in iptables?
|
I don't think so. The other day a discussion came up in another newsgroup
in which someone presented the problem, that his machine became very slow
bacause dynamically added rules to filter certain hosts when using file
sharing. He said he has some 50.000 rules. I just said, that this is just
crazy and a perfect way to self DoS, long blacklists are always BAD.
| Quote: | I am working on writing a perl firewall script that loads groups of
networks from a database and applies polices to them using ibtables.
|
Usually (long) blacklists are not a good idea.
| Quote: | It
is working well as of now with several thousand rules installed and
running. I am wondering what performance issues might arise as the
database grows and more rules are installed.
|
It will slow down everything. You might split the ruleset up into several
user defined chains so that every packet does nor have to travel throught
the whole stack of rules. At least that is what I do when rulesets become
complex. However I always try to keep the number of rules small. Allow only
certain services, deny everything else is the right approach.
Wolfgang |
|
| Back to top |
|
|
henry
Guest
|
| Posted:
Wed Jan 12, 2005 7:13 am Post subject:
Re: Max iptables rules? |
|
|
Thanks for your response Wolfgang. My firewalling approach is the following:
Its databased controlled, and I have a table that defines services, a
table that defines networks, and a table taht defines policies. In my
services table I define services, such as http or smtp, and what groups
of networks (from the networks table) should have access. The reason for
this approach is I figure, I want to grant access to everyone to
services like http, smtp, and dns, but everyone doesn't need access to
services like ssh, pop3, mysql, imap, etc. So I have compiled a list of
networks of the ISPs my users are on, and then only allow those networks
access to connect to these secure ports. Every once and a while, a user
calls and says they don't have access, I find out their current IP, and
grant that whole /16 network. Now I have my list of about 20-30 class B
networks, and I never gets calls anymore...
This has worked very well. I have added the policies table to be able to
deny bad networks and to expressly grant access to all hosts to
protocols like ah and esp (allow VPN from anywhere).
At this point I have maybe a few hundred rules. I have been considering
the possibility of maintaining blacklists of networks, but you are
telling me thats a bad idea. I have already started this however, by
blocking known spyware/adware networks, some romanian networks, etc. Now
I have several thousand rules and everything is still running fine. I am
wondering how far this concept can be pushed before performace starts to
become a problem, or if the whole concept is a bad one.
If the order of the rules is done in an intelligent manner, then
shouldn't packets that match rules near the top not be bogged down? If a
packet matches the 3rd rule, for example, then shouldn't it not matter
if there are a million rules below it? Also, since I have the rule to
allow packets whose state is established/connected at the top of the
list, then wouldn't the processing burden only be on those first few
packets that come through until a connection is established? And, those
would only be on packets who are unfortunate enough to belong to
networks whose rank is low in the list... Am I making any sense?
Wolfgang Kueter wrote:
| Quote: | henry wrote:
Does anyone know what is the maximum number of firewall rules that be
loaded at a time in iptables?
I don't think so. The other day a discussion came up in another newsgroup
in which someone presented the problem, that his machine became very slow
bacause dynamically added rules to filter certain hosts when using file
sharing. He said he has some 50.000 rules. I just said, that this is just
crazy and a perfect way to self DoS, long blacklists are always BAD.
I am working on writing a perl firewall script that loads groups of
networks from a database and applies polices to them using ibtables.
Usually (long) blacklists are not a good idea.
It
is working well as of now with several thousand rules installed and
running. I am wondering what performance issues might arise as the
database grows and more rules are installed.
It will slow down everything. You might split the ruleset up into several
user defined chains so that every packet does nor have to travel throught
the whole stack of rules. At least that is what I do when rulesets become
complex. However I always try to keep the number of rules small. Allow only
certain services, deny everything else is the right approach.
Wolfgang
|
|
|
| Back to top |
|
|
Wolfgang Kueter
Guest
|
| Posted:
Thu Jan 13, 2005 4:22 am Post subject:
Re: Max iptables rules? |
|
|
henry wrote:
| Quote: | Thanks for your response Wolfgang. My firewalling approach is the
following: [...]
|
In general your approach is correct.
| Quote: | If the order of the rules is done in an intelligent manner, then
shouldn't packets that match rules near the top not be bogged down? [...]
|
Right. Concerning ordering of rules think of a tree structure of user
defined chains:
rule_1aa
/
rule_1a
/ \
/ rule_1ab
rule_1
|
|
| rule_2aa
| /
| rule_2a
| / \
| / rule_2ab
rule_2
In this small example we have a total of eight rules but after a maximum of
3 decisions every packet reaches its final destination. When we have the
standard ordering the rules (one rule after the other in a stack) a packet
might have to travel through the whole stack.
Well, compare a tree structure of lets say a thousand rules to a stack of
1000 rules and you got my point.
Wolfgang |
|
| Back to top |
|
|
henry
Guest
|
| Posted:
Thu Jan 13, 2005 7:32 am Post subject:
Re: Max iptables rules? |
|
|
Here is my understanding of how Iptables processes firewall rules,
please someone correct if where this is wrong:
Lets say we have a table like the following dummy example
# Target prot source destination
===============================================
1 ACCEPT all 0.0.0.0/0 0.0.0.0/0 state: est/connected
2 ACCEPT all 10.0.0.0/24 0.0.0.0/0
3 ACCEPT all 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80
4 ACCEPT all 30.30.0.0/16 0.0.0.0/0 tcp dpt: 22
5 ACCEPT all 31.31.0.0/16 0.0.0.0/0 tcp dpt: 22
6 ACCEPT all 32.32.0.0/16 0.0.0.0/0 tcp dpt: 22
...
...
...
20 ACCEPT all 60.60.0.0/16 0.0.0.0/0 tcp dpt: 22
21 REJECT all 66.1.0.0/16 0.0.0.0/0
22 REJECT all 66.2.0.0/16 0.0.0.0/0
23 REJECT all 66.3.0.0/16 0.0.0.0/0
24 REJECT all 66.4.0.0/16 0.0.0.0/0
...
...
...
...
1000 REJECT all 70.30.0.0/16 0.0.0.0/0
Lets say the above is our firewall with 1000 rules in it. Now this isn't
a very good firewall configuration, but bear with me. Lets say that a
packet come through on port 80. The packet will be compared to the list.
On the 3rd rule, iptables will find a match and will allow the packet,
and will ignore all the rest of the 997 rules as if they weren't even
there. Lets say a packet from ip 70.30.1.2 comes in on port 80. It is in
the list and should clearly be rejected, right? (number 1000). Well, it
would indeed match that reject rule, but it would also match the ACCEPT
rule number 3, and since 3 comes first, the packet will be allowed. If
our default policy is to REJECT, then all of our reject rules that come
at the end of our list effectively do nothing--and also shouldn't impact
performance... Here is a more senseable config:
# Target prot source destination
===============================================
1 ACCEPT all 0.0.0.0/0 0.0.0.0/0 state: est/connected
2 ACCEPT all 10.0.0.0/24 0.0.0.0/0
3 ACCEPT all 30.30.0.0/16 0.0.0.0/0 tcp dpt: 22
4 ACCEPT all 31.31.0.0/16 0.0.0.0/0 tcp dpt: 22
5 ACCEPT all 32.32.0.0/16 0.0.0.0/0 tcp dpt: 22
...
...
...
19 ACCEPT all 60.60.0.0/16 0.0.0.0/0 tcp dpt: 22
20 REJECT all 66.1.0.0/16 0.0.0.0/0
21 REJECT all 66.2.0.0/16 0.0.0.0/0
22 REJECT all 66.3.0.0/16 0.0.0.0/0
23 REJECT all 66.4.0.0/16 0.0.0.0/0
...
...
...
...
999 REJECT all 70.30.0.0/16 0.0.0.0/0
1000 ACCEPT all 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80
Now this firewall actually does something. In this firewall, we say that
everyone should be able to connect to port 80, EXCEPT those hosts that
we are rejecting. The question is, how much will this impact performance?
Lets say that machine 10.0.0.4 wants to browse out to the net (assuming
we also have a snat rule). Those packets match on rule 2, so there is
virtually no extra processing happening there, it doesn't matter if
there are 10,000 rules below it, rule 2 matches, the packet is allowed,
and iptables doesn't look at the rest of the list.
Ok, but now lets say that a random machine, say 90.100.100.9, wants to
connect on port 80. Iptables will begin comparing the packet line by
line until it finds a match. Lets say we have no reject rules that match
this host. Iptables will have to go all the way through the entire list
until it gets to rule 1000, that says the packet should be allowed.
Thats hefty processing right? Especially for every single packet that
goes through the firewall, right? Well lets look. 90.100.100.9 wants to
connect on port 80. Before the firewall allows the packet, it runs
through all 1000 rules for allowing the packet to pass through he
filter. The packet reaches the web server, which responds (since the web
server is probably on 10.0.0.0/24, it will match rule 2 and be allowed
right away) and goes back to 90.100.100.9, which in turn sends a packet
back as the 2 hosts begin to communicate. Now when the following packets
come from host 90.100.100.9, the firewall again has to compare them, as
with every packet, to the firewall rules. This time however, the packets
from 90.100.100.9 have a state of established/connected, related to the
session it has established it the web server. The firewall compares the
packet to its firewall rules and matches on the very first rule of
connected/established, and allows the packet.
As we see, even with connections from hosts that have to match rules all
the way at the bottom of the list, in reality only a fraction of the
packets that pass the filter will have to undergo such scrutiny. And,
with a powerful box, shouldn't it be able to effectively handle a list
of a few hundred thousand entries?
The example you described of the "tree" is not my understanding of how
Iptables processes rules. The rules are perfectly linear. Every packet
is compared to every rule in the list until a match is found. Thats why
I think the key is to make it so that as many of the packets as possible
match as high on the list as possible.
Maybe I have it all wrong... That's why I am posting the question.
In any case, I think it is worth an experiment. I am going to setup a
box with 100,000 rules that will be randomly generated from a perl
script. Most of the rules will be reject rules for small blocks of IPs.
I will then put the rule that will match to my test box at the top of
the list, test performance and load, and then at the bottom the list,
and test performance and load. I will do the same for the rule of
allowing established/connected packets at the top and bottom as well,
testing both cases. I'll be sure to post my results.
Wolfgang Kueter wrote:
| Quote: | henry wrote:
Thanks for your response Wolfgang. My firewalling approach is the
following: [...]
In general your approach is correct.
If the order of the rules is done in an intelligent manner, then
shouldn't packets that match rules near the top not be bogged down? [...]
Right. Concerning ordering of rules think of a tree structure of user
defined chains:
rule_1aa
/
rule_1a
/ \
/ rule_1ab
rule_1
|
|
| rule_2aa
| /
| rule_2a
| / \
| / rule_2ab
rule_2
In this small example we have a total of eight rules but after a maximum of
3 decisions every packet reaches its final destination. When we have the
standard ordering the rules (one rule after the other in a stack) a packet
might have to travel through the whole stack.
Well, compare a tree structure of lets say a thousand rules to a stack of
1000 rules and you got my point.
Wolfgang |
|
|
| Back to top |
|
|
henry
Guest
|
| Posted:
Thu Jan 13, 2005 7:32 am Post subject:
Re: Max iptables rules? |
|
|
Here is my understanding of how Iptables processes firewall rules,
please someone correct if where this is wrong:
Lets say we have a table like the following dummy example
# Target prot source destination
===============================================
1 ACCEPT all 0.0.0.0/0 0.0.0.0/0 state: est/connected
2 ACCEPT all 10.0.0.0/24 0.0.0.0/0
3 ACCEPT all 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80
4 ACCEPT all 30.30.0.0/16 0.0.0.0/0 tcp dpt: 22
5 ACCEPT all 31.31.0.0/16 0.0.0.0/0 tcp dpt: 22
6 ACCEPT all 32.32.0.0/16 0.0.0.0/0 tcp dpt: 22
...
...
...
20 ACCEPT all 60.60.0.0/16 0.0.0.0/0 tcp dpt: 22
21 REJECT all 66.1.0.0/16 0.0.0.0/0
22 REJECT all 66.2.0.0/16 0.0.0.0/0
23 REJECT all 66.3.0.0/16 0.0.0.0/0
24 REJECT all 66.4.0.0/16 0.0.0.0/0
...
...
...
...
1000 REJECT all 70.30.0.0/16 0.0.0.0/0
Lets say the above is our firewall with 1000 rules in it. Now this isn't
a very good firewall configuration, but bear with me. Lets say that a
packet come through on port 80. The packet will be compared to the list.
On the 3rd rule, iptables will find a match and will allow the packet,
and will ignore all the rest of the 997 rules as if they weren't even
there. Lets say a packet from ip 70.30.1.2 comes in on port 80. It is in
the list and should clearly be rejected, right? (number 1000). Well, it
would indeed match that reject rule, but it would also match the ACCEPT
rule number 3, and since 3 comes first, the packet will be allowed. If
our default policy is to REJECT, then all of our reject rules that come
at the end of our list effectively do nothing--and also shouldn't impact
performance... Here is a more senseable config:
# Target prot source destination
===============================================
1 ACCEPT all 0.0.0.0/0 0.0.0.0/0 state: est/connected
2 ACCEPT all 10.0.0.0/24 0.0.0.0/0
3 ACCEPT all 30.30.0.0/16 0.0.0.0/0 tcp dpt: 22
4 ACCEPT all 31.31.0.0/16 0.0.0.0/0 tcp dpt: 22
5 ACCEPT all 32.32.0.0/16 0.0.0.0/0 tcp dpt: 22
...
...
...
19 ACCEPT all 60.60.0.0/16 0.0.0.0/0 tcp dpt: 22
20 REJECT all 66.1.0.0/16 0.0.0.0/0
21 REJECT all 66.2.0.0/16 0.0.0.0/0
22 REJECT all 66.3.0.0/16 0.0.0.0/0
23 REJECT all 66.4.0.0/16 0.0.0.0/0
...
...
...
...
999 REJECT all 70.30.0.0/16 0.0.0.0/0
1000 ACCEPT all 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80
Now this firewall actually does something. In this firewall, we say that
everyone should be able to connect to port 80, EXCEPT those hosts that
we are rejecting. The question is, how much will this impact performance?
Lets say that machine 10.0.0.4 wants to browse out to the net (assuming
we also have a snat rule). Those packets match on rule 2, so there is
virtually no extra processing happening there, it doesn't matter if
there are 10,000 rules below it, rule 2 matches, the packet is allowed,
and iptables doesn't look at the rest of the list.
Ok, but now lets say that a random machine, say 90.100.100.9, wants to
connect on port 80. Iptables will begin comparing the packet line by
line until it finds a match. Lets say we have no reject rules that match
this host. Iptables will have to go all the way through the entire list
until it gets to rule 1000, that says the packet should be allowed.
Thats hefty processing right? Especially for every single packet that
goes through the firewall, right? Well lets look. 90.100.100.9 wants to
connect on port 80. Before the firewall allows the packet, it runs
through all 1000 rules for allowing the packet to pass through he
filter. The packet reaches the web server, which responds (since the web
server is probably on 10.0.0.0/24, it will match rule 2 and be allowed
right away) and goes back to 90.100.100.9, which in turn sends a packet
back as the 2 hosts begin to communicate. Now when the following packets
come from host 90.100.100.9, the firewall again has to compare them, as
with every packet, to the firewall rules. This time however, the packets
from 90.100.100.9 have a state of established/connected, related to the
session it has established it the web server. The firewall compares the
packet to its firewall rules and matches on the very first rule of
connected/established, and allows the packet.
As we see, even with connections from hosts that have to match rules all
the way at the bottom of the list, in reality only a fraction of the
packets that pass the filter will have to undergo such scrutiny. And,
with a powerful box, shouldn't it be able to effectively handle a list
of a few hundred thousand entries?
The example you described of the "tree" is not my understanding of how
Iptables processes rules. The rules are perfectly linear. Every packet
is compared to every rule in the list until a match is found. Thats why
I think the key is to make it so that as many of the packets as possible
match as high on the list as possible.
Maybe I have it all wrong... That's why I am posting the question.
In any case, I think it is worth an experiment. I am going to setup a
box with 100,000 rules that will be randomly generated from a perl
script. Most of the rules will be reject rules for small blocks of IPs.
I will then put the rule that will match to my test box at the top of
the list, test performance and load, and then at the bottom the list,
and test performance and load. I will do the same for the rule of
allowing established/connected packets at the top and bottom as well,
testing both cases. I'll be sure to post my results.
Wolfgang Kueter wrote:
| Quote: | henry wrote:
Thanks for your response Wolfgang. My firewalling approach is the
following: [...]
In general your approach is correct.
If the order of the rules is done in an intelligent manner, then
shouldn't packets that match rules near the top not be bogged down? [...]
Right. Concerning ordering of rules think of a tree structure of user
defined chains:
rule_1aa
/
rule_1a
/ \
/ rule_1ab
rule_1
|
|
| rule_2aa
| /
| rule_2a
| / \
| / rule_2ab
rule_2
In this small example we have a total of eight rules but after a maximum of
3 decisions every packet reaches its final destination. When we have the
standard ordering the rules (one rule after the other in a stack) a packet
might have to travel through the whole stack.
Well, compare a tree structure of lets say a thousand rules to a stack of
1000 rules and you got my point.
Wolfgang |
|
|
| Back to top |
|
|
henry
Guest
|
| Posted:
Thu Jan 13, 2005 7:34 am Post subject:
Re: Max iptables rules? |
|
|
Here is my understanding of how Iptables processes firewall rules,
please someone correct if where this is wrong:
Lets say we have a table like the following dummy example
# Target prot source destination
===============================================
1 ACCEPT all 0.0.0.0/0 0.0.0.0/0 state: est/connected
2 ACCEPT all 10.0.0.0/24 0.0.0.0/0
3 ACCEPT all 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80
4 ACCEPT all 30.30.0.0/16 0.0.0.0/0 tcp dpt: 22
5 ACCEPT all 31.31.0.0/16 0.0.0.0/0 tcp dpt: 22
6 ACCEPT all 32.32.0.0/16 0.0.0.0/0 tcp dpt: 22
...
...
...
20 ACCEPT all 60.60.0.0/16 0.0.0.0/0 tcp dpt: 22
21 REJECT all 66.1.0.0/16 0.0.0.0/0
22 REJECT all 66.2.0.0/16 0.0.0.0/0
23 REJECT all 66.3.0.0/16 0.0.0.0/0
24 REJECT all 66.4.0.0/16 0.0.0.0/0
...
...
...
...
1000 REJECT all 70.30.0.0/16 0.0.0.0/0
Lets say the above is our firewall with 1000 rules in it. Now this isn't
a very good firewall configuration, but bear with me. Lets say that a
packet come through on port 80. The packet will be compared to the list.
On the 3rd rule, iptables will find a match and will allow the packet,
and will ignore all the rest of the 997 rules as if they weren't even
there. Lets say a packet from ip 70.30.1.2 comes in on port 80. It is in
the list and should clearly be rejected, right? (number 1000). Well, it
would indeed match that reject rule, but it would also match the ACCEPT
rule number 3, and since 3 comes first, the packet will be allowed. If
our default policy is to REJECT, then all of our reject rules that come
at the end of our list effectively do nothing--and also shouldn't impact
performance... Here is a more senseable config:
# Target prot source destination
===============================================
1 ACCEPT all 0.0.0.0/0 0.0.0.0/0 state: est/connected
2 ACCEPT all 10.0.0.0/24 0.0.0.0/0
3 ACCEPT all 30.30.0.0/16 0.0.0.0/0 tcp dpt: 22
4 ACCEPT all 31.31.0.0/16 0.0.0.0/0 tcp dpt: 22
5 ACCEPT all 32.32.0.0/16 0.0.0.0/0 tcp dpt: 22
...
...
...
19 ACCEPT all 60.60.0.0/16 0.0.0.0/0 tcp dpt: 22
20 REJECT all 66.1.0.0/16 0.0.0.0/0
21 REJECT all 66.2.0.0/16 0.0.0.0/0
22 REJECT all 66.3.0.0/16 0.0.0.0/0
23 REJECT all 66.4.0.0/16 0.0.0.0/0
...
...
...
...
999 REJECT all 70.30.0.0/16 0.0.0.0/0
1000 ACCEPT all 0.0.0.0/0 0.0.0.0/0 tcp dpt: 80
Now this firewall actually does something. In this firewall, we say that
everyone should be able to connect to port 80, EXCEPT those hosts that
we are rejecting. The question is, how much will this impact performance?
Lets say that machine 10.0.0.4 wants to browse out to the net (assuming
we also have a snat rule). Those packets match on rule 2, so there is
virtually no extra processing happening there, it doesn't matter if
there are 10,000 rules below it, rule 2 matches, the packet is allowed,
and iptables doesn't look at the rest of the list.
Ok, but now lets say that a random machine, say 90.100.100.9, wants to
connect on port 80. Iptables will begin comparing the packet line by
line until it finds a match. Lets say we have no reject rules that match
this host. Iptables will have to go all the way through the entire list
until it gets to rule 1000, that says the packet should be allowed.
Thats hefty processing right? Especially for every single packet that
goes through the firewall, right? Well lets look. 90.100.100.9 wants to
connect on port 80. Before the firewall allows the packet, it runs
through all 1000 rules for allowing the packet to pass through he
filter. The packet reaches the web server, which responds (since the web
server is probably on 10.0.0.0/24, it will match rule 2 and be allowed
right away) and goes back to 90.100.100.9, which in turn sends a packet
back as the 2 hosts begin to communicate. Now when the following packets
come from host 90.100.100.9, the firewall again has to compare them, as
with every packet, to the firewall rules. This time however, the packets
from 90.100.100.9 have a state of established/connected, related to the
session it has established it the web server. The firewall compares the
packet to its firewall rules and matches on the very first rule of
connected/established, and allows the packet.
As we see, even with connections from hosts that have to match rules all
the way at the bottom of the list, in reality only a fraction of the
packets that pass the filter will have to undergo such scrutiny. And,
with a powerful box, shouldn't it be able to effectively handle a list
of a few hundred thousand entries?
The example you described of the "tree" is not my understanding of how
Iptables processes rules. The rules are perfectly linear. Every packet
is compared to every rule in the list until a match is found. Thats why
I think the key is to make it so that as many of the packets as possible
match as high on the list as possible.
Maybe I have it all wrong... That's why I am posting the question.
In any case, I think it is worth an experiment. I am going to setup a
box with 100,000 rules that will be randomly generated from a perl
script. Most of the rules will be reject rules for small blocks of IPs.
I will then put the rule that will match to my test box at the top of
the list, test performance and load, and then at the bottom the list,
and test performance and load. I will do the same for the rule of
allowing established/connected packets at the top and bottom as well,
testing both cases. I'll be sure to post my results.
Wolfgang Kueter wrote:
| Quote: | henry wrote:
Thanks for your response Wolfgang. My firewalling approach is the
following: [...]
In general your approach is correct.
If the order of the rules is done in an intelligent manner, then
shouldn't packets that match rules near the top not be bogged down? [...]
Right. Concerning ordering of rules think of a tree structure of user
defined chains:
rule_1aa
/
rule_1a
/ \
/ rule_1ab
rule_1
|
|
| rule_2aa
| /
| rule_2a
| / \
| / rule_2ab
rule_2
In this small example we have a total of eight rules but after a maximum of
3 decisions every packet reaches its final destination. When we have the
standard ordering the rules (one rule after the other in a stack) a packet
might have to travel through the whole stack.
Well, compare a tree structure of lets say a thousand rules to a stack of
1000 rules and you got my point.
Wolfgang |
|
|
| Back to top |
|
|
Justins local account
Guest
|
| Posted:
Thu Jan 13, 2005 8:41 pm Post subject:
Re: Max iptables rules? |
|
|
henry <info@intellitree.com> writes:
| Quote: |
The example you described of the "tree" is not my understanding of how
Iptables processes rules. The rules are perfectly linear. Every packet
is compared to every rule in the list until a match is found. Thats
why I think the key is to make it so that as many of the packets as
possible match as high on the list as possible.
|
check the -j and -N arguments to IPtables - these allow you to create
your tree. Or loops...
copy rules 4 to 20 into a new chain called trusted - but don't bother
specifying the "tcp dpt:" bit
then change rule 4 to
4 trusted all 0.0.0.0/0 0.0.0.0/0 tcp dpt: 22
then delete rules 20 down to 5
--
Justin Murdock |
|
| Back to top |
|
|
Wolfgang Kueter
Guest
|
| Posted:
Fri Jan 14, 2005 3:00 am Post subject:
Re: Max iptables rules? |
|
|
henry wrote:
| Quote: | The example you described of the "tree" is not my understanding of how
Iptables processes rules.
|
iptables processes rules in defined chains. THere are a few prefined chains
like INPUT, OUTPUT and FORWARD. You can define your own ...
| Quote: | The rules are perfectly linear.
|
Wrong, that is is the case for every chain, but the way from chain to chain
is not neccessarily linear. One can build a tree structure of chains,
believe me, I've done it (more than once ....).
| Quote: | Every packet
is compared to every rule in the list until a match is found. Thats why
I think the key is to make it so that as many of the packets as possible
match as high on the list as possible.
|
Look at the following code snippet to get the idea (stateful filtering not
used to make the example easier to understand)
---8<---
# some variable definitions
# servers
SERVER_1="111.111.111.111/32"
SERVER_2="111.111.111.112/32"
SERVER_3="111.111.111.113/32"
# networks
NET_1="111.111.112.0/24"
NET_2="111.111.113.0/24"
NET_3="111.111.114.0/24"
# clean up the user defined chain mess first ;-)
iptables -X
# cleaning of user defined mess done
# and now some user defined chains (the mess ...) again ;-)
# everything to/from SERVER_1 goes here
iptables -N server_1
# everything to/from SERVER_2 goes here
iptables -N server_2
# everything to/from SERVER_3 goes here
iptables -N server_3
# define my own reject chain
iptables -N myreject
# Send a correct ICMP Message to reject connections attemps
iptables -A myreject -j REJECT --reject-with icmp-admin-prohibited
# traffic to SERVER_1 to chain server_1
iptables -A FORWARD -s §SERVER_1 -j server_1
iptables -A FORWARD -d §SERVER_1 -j server_1
# traffic to SERVER_2 to chain server_2
iptables -A FORWARD -s §SERVER_2 -j server_1
iptables -A FORWARD -d §SERVER_2 -j server_1
# traffic to SERVER_3 to chain server_3
iptables -A FORWARD -s §SERVER_3 -j server_1
iptables -A FORWARD -d §SERVER_3 -j server_1
# rules for SERVER_1
# allow http access from NET_1 to SERVER_1
iptables -A server_1 -s $NET_1 -d $SERVER_1 -p tcp --dport 80 - j ACCEPT
iptables -A server_1 -d $NET_1 -d $SERVER_1 -p tcp --sport 80 - j ACCEPT
# allow smto access from NET_2 to SERVER_1
iptables -A server_1 -s $NET_2 -d $SERVER_1 -p tcp --dport 25 - j ACCEPT
iptables -A server_1 -d $NET_2 -s $SERVER_1 -p tcp --sport 25 - j ACCEPT
# log the rest
iptables -A server_1 -s $SERVER_1 -j LOG --log-prefix "SERVER_1 OUT DENIED "
iptables -A server_1 -d $SERVER_1 -j LOG --log-prefix "SERVER_1 IN DENIED "
# and then reject it
iptables -A server_1 -j myreject
# rules for SERVER_2
# allow http access to SERVER_2 from anywhere
iptables -A server_2 -d $SERVER_2 -p tcp --dport 80 - j ACCEPT
iptables -A server_2 -s $SERVER_2 -p tcp --sport 80 - j ACCEPT
# allow https access to SERVER_2 from anywhere
iptables -A server_2 -d $SERVER_2 -p tcp --dport 443 - j ACCEPT
iptables -A server_2 -s $SERVER_2 -p tcp --sport 443- j ACCEPT
# log the rest
iptables -A server_2 -s $SERVER_2 -j LOG --log-prefix "SERVER_2 OUT DENIED "
iptables -A server_2 -d $SERVER_2 -j LOG --log-prefix "SERVER_2 IN DENIED "
# and then reject it
iptables -A server_2 -j myreject
# ...
---8<---
Did you get the idea behind that? That _is_ a tree. believe me. Packets
to/from SERVER_1 never see the rules for SERVER_2 and packets to/from
SERVER_2 never see the the rules for SERVER_1 ...
Wolfgang
| Quote: | In any case, I think it is worth an experiment. I am going to setup a
box with 100,000 rules that will be randomly generated from a perl
script.
|
_Think_ instead of using brute force.
Wolfgang |
|
| Back to top |
|
|
Wolfgang Kueter
Guest
|
| Posted:
Fri Jan 14, 2005 3:08 am Post subject:
Re: Max iptables rules? |
|
|
henry wrote:
| Quote: | The example you described of the "tree" is not my understanding of how
Iptables processes rules.
|
iptables processes rules in defined chains. THere are a few prefined chains
like INPUT, OUTPUT and FORWARD. You can define your own ...
| Quote: | The rules are perfectly linear.
|
Wrong, that is is the case for every chain, but the way from chain to chain
is not neccessarily linear. One can build a tree structure of chains,
believe me, I've done it (more than once ....).
| Quote: | Every packet
is compared to every rule in the list until a match is found. Thats why
I think the key is to make it so that as many of the packets as possible
match as high on the list as possible.
|
Look at the following code snippet to get the idea (stateful filtering not
used to make the example easier to understand)
---8<---
# some variable definitions
# servers
SERVER_1="111.111.111.111/32"
SERVER_2="111.111.111.112/32"
SERVER_3="111.111.111.113/32"
# networks
NET_1="111.111.112.0/24"
NET_2="111.111.113.0/24"
NET_3="111.111.114.0/24"
# clean up the user defined chain mess first ;-)
iptables -X
# cleaning of user defined mess done
# and now some user defined chains (the mess ...) again ;-)
# everything to/from SERVER_1 goes here
iptables -N server_1
# everything to/from SERVER_2 goes here
iptables -N server_2
# everything to/from SERVER_3 goes here
iptables -N server_3
# define my own reject chain
iptables -N myreject
# Send a correct ICMP Message to reject connections attemps
iptables -A myreject -j REJECT --reject-with icmp-admin-prohibited
# traffic to SERVER_1 to chain server_1
iptables -A FORWARD -s §SERVER_1 -j server_1
iptables -A FORWARD -d §SERVER_1 -j server_1
# traffic to SERVER_2 to chain server_2
iptables -A FORWARD -s §SERVER_2 -j server_2
iptables -A FORWARD -d §SERVER_2 -j server_2
# traffic to SERVER_3 to chain server_3
iptables -A FORWARD -s §SERVER_3 -j server_3
iptables -A FORWARD -d §SERVER_3 -j server_3
# rules for SERVER_1
# allow http access from NET_1 to SERVER_1
iptables -A server_1 -s $NET_1 -d $SERVER_1 -p tcp --dport 80 - j ACCEPT
iptables -A server_1 -d $NET_1 -d $SERVER_1 -p tcp --sport 80 - j ACCEPT
# allow smto access from NET_2 to SERVER_1
iptables -A server_1 -s $NET_2 -d $SERVER_1 -p tcp --dport 25 - j ACCEPT
iptables -A server_1 -d $NET_2 -s $SERVER_1 -p tcp --sport 25 - j ACCEPT
# log the rest
iptables -A server_1 -s $SERVER_1 -j LOG --log-prefix "SERVER_1 OUT DENIED "
iptables -A server_1 -d $SERVER_1 -j LOG --log-prefix "SERVER_1 IN DENIED "
# and then reject it
iptables -A server_1 -j myreject
# rules for SERVER_2
# allow http access to SERVER_2 from anywhere
iptables -A server_2 -d $SERVER_2 -p tcp --dport 80 - j ACCEPT
iptables -A server_2 -s $SERVER_2 -p tcp --sport 80 - j ACCEPT
# allow https access to SERVER_2 from anywhere
iptables -A server_2 -d $SERVER_2 -p tcp --dport 443 - j ACCEPT
iptables -A server_2 -s $SERVER_2 -p tcp --sport 443- j ACCEPT
# log the rest
iptables -A server_2 -s $SERVER_2 -j LOG --log-prefix "SERVER_2 OUT DENIED "
iptables -A server_2 -d $SERVER_2 -j LOG --log-prefix "SERVER_2 IN DENIED "
# and then reject it
iptables -A server_2 -j myreject
# rules for SERVER_3
# allow simply nothing
# log the rest
iptables -A server_3 -s $SERVER_3 -j LOG --log-prefix "SERVER_3 OUT DENIED "
iptables -A server_3 -d $SERVER_3 -j LOG --log-prefix "SERVER_3 IN DENIED "
# and then reject it
iptables -A server_3 -j myreject
# ...
---8<---
Did you get the idea behind that? That is a tree. believe me. Packets
to/from SERVER_1 never see the rules for SERVER_2 and packets to/from
SERVER_2 never see the the rules for SERVER_1 ...
| Quote: | In any case, I think it is worth an experiment. I am going to setup a
box with 100,000 rules that will be randomly generated from a perl
script.
|
_Think_ instead of using brute force.
Wolfgang |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in