* Iptables rules processing @ 2007-08-03 16:13 Franck Joncourt 2007-08-03 16:23 ` Ray Leach 2007-08-04 20:37 ` Elvir Kuric 0 siblings, 2 replies; 11+ messages in thread From: Franck Joncourt @ 2007-08-03 16:13 UTC (permalink / raw) To: netfilter [-- Attachment #1: Type: text/plain, Size: 619 bytes --] Hi, Assuming we have the next two rules in our ruleset : iptables -A INPUT -s 192.168.10.14 -p tcp --dport 80 -j ACCEPT iptables -A INPUT -s 192.168.10.14 -p tcp --dport 443 -j ACCEPT I was wondering whether rules are processed one by one. In the two rules above, we have to check the source address 192.168.10.14, so I think this is done for the first one, and then for the second one. I am not quite sure ; Can anyone confirm that ? -- Franck Joncourt http://www.debian.org - http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 16:13 Iptables rules processing Franck Joncourt @ 2007-08-03 16:23 ` Ray Leach 2007-08-03 17:07 ` Franck Joncourt 2007-08-04 20:37 ` Elvir Kuric 1 sibling, 1 reply; 11+ messages in thread From: Ray Leach @ 2007-08-03 16:23 UTC (permalink / raw) To: netfilter [-- Attachment #1: Type: text/plain, Size: 1259 bytes --] Franck Joncourt wrote: > Hi, > > Assuming we have the next two rules in our ruleset : > > iptables -A INPUT -s 192.168.10.14 -p tcp --dport 80 -j ACCEPT > iptables -A INPUT -s 192.168.10.14 -p tcp --dport 443 -j ACCEPT > > I was wondering whether rules are processed one by one. > In the two rules above, we have to check the source address > 192.168.10.14, so I think this is done for the first one, and then for > the second one. I am not quite sure ; Can anyone confirm that ? > > Yes, rules are processed one by one until a rule matches the packet. So the first rule above would be matched for traffic coming from 192.168.10.14 going to port 80 (192.168.10.14 browses a website) The second rule would be matched when 192.168.10.14 tried to browse a secure website. Since bothe these rules are in the INPUT chain, they will only be matched when the source ip tried to access those ports on the machine running iptables. -- <img src='http://www.danasoft.com/sig/spoonssig.jpg' /> -------------------------------------------------- RCHQ Hobbies cc http://www.rchq.co.za and http://store.rchq.co.za Fax: +27 86 652 2773 eMail: admin@rchq.co.za P O Box 10376, Vorna Valley, Midrand, 1686 -------------------------------------------------- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 16:23 ` Ray Leach @ 2007-08-03 17:07 ` Franck Joncourt 2007-08-03 17:34 ` Rob Sterenborg 2007-08-03 18:43 ` John A. Sullivan III 0 siblings, 2 replies; 11+ messages in thread From: Franck Joncourt @ 2007-08-03 17:07 UTC (permalink / raw) To: netfilter [-- Attachment #1: Type: text/plain, Size: 1965 bytes --] On Fri, Aug 03, 2007 at 06:23:10PM +0200, Ray Leach wrote: > > > Franck Joncourt wrote: >> Hi, >> >> Assuming we have the next two rules in our ruleset : >> >> iptables -A INPUT -s 192.168.10.14 -p tcp --dport 80 -j ACCEPT >> iptables -A INPUT -s 192.168.10.14 -p tcp --dport 443 -j ACCEPT >> >> I was wondering whether rules are processed one by one. >> In the two rules above, we have to check the source address >> 192.168.10.14, so I think this is done for the first one, and then for >> the second one. I am not quite sure ; Can anyone confirm that ? >> >> > Yes, rules are processed one by one until a rule matches the packet. > > So the first rule above would be matched for traffic coming from > 192.168.10.14 going to port 80 (192.168.10.14 browses a website) > The second rule would be matched when 192.168.10.14 tried to browse a > secure website. > > Since bothe these rules are in the INPUT chain, they will only be matched > when the source ip tried to access those ports on the machine running > iptables. > I meant, there can't be no such processing ? 1/ -> ... -> match for the source address 192.168.10.14 |-> match for destination port 80 -> ACCEPT |-> match for the destination port 443 -> ACCEPT -> ... According to me, it works this way : 2/ -> ... -> match source address 192.168.10.14 AND destination port 80 |-> ACCEPT -> match source address 192.168.10.14 AND destination port 443 |-> ACCEPT ->... In the case 1, we check the source address once, and in the second one, twice. So the first case would be quicker to process than the second one where there is no optimalisation. I know what these rules do, but this is just an example, and I know how the user chains work as well :p! -- Franck Joncourt http://www.debian.org - http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: Iptables rules processing 2007-08-03 17:07 ` Franck Joncourt @ 2007-08-03 17:34 ` Rob Sterenborg 2007-08-03 17:44 ` Franck Joncourt 2007-08-03 20:23 ` Grant Taylor 2007-08-03 18:43 ` John A. Sullivan III 1 sibling, 2 replies; 11+ messages in thread From: Rob Sterenborg @ 2007-08-03 17:34 UTC (permalink / raw) To: Netfilter > I meant, there can't be no such processing ? > > 1/ > -> ... > -> match for the source address 192.168.10.14 > |-> match for destination port 80 -> ACCEPT > |-> match for the destination port 443 -> ACCEPT -> ... Yes, this is possible using a user defined chain. $ipt -N WEBCHECK $ipt -A WEBCHECK -p tcp --dport 80 -j ACCEPT $ipt -A WEBCHECK -p tcp --dport 443 -j ACCEPT $ipt -A INPUT -s 192.168.10.14 [-p tcp] -j WEBCHECK First you create a user defined chain (-N), for example, called WEBCHECK. You populate the chain with rules that only match port 80 or port 443 and ACCEPT when matched. You add a rule to the default INPUT chain matching source IP 192.168.10.14 and redirect the packet to the WEBCHECK. If no rule in WEBCHECK matched, the packet will continue traversing the INPUT chain until a match or do what the chain policy says should happen (ACCEPT or DROP). The "-p tcp" in the INPUT rule is optional, but since you're only checking tcp packets in the WEBCHECK chain, it might make sense to only send tcp packets to that chain. This would IMHO only be of real use if you have lots of rules and you want to narrow down the number of rules to be matched. In this case you won't notice the difference. Grts, Rob ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 17:34 ` Rob Sterenborg @ 2007-08-03 17:44 ` Franck Joncourt 2007-08-03 19:29 ` Grant Taylor 2007-08-03 20:23 ` Grant Taylor 1 sibling, 1 reply; 11+ messages in thread From: Franck Joncourt @ 2007-08-03 17:44 UTC (permalink / raw) To: netfilter [-- Attachment #1: Type: text/plain, Size: 685 bytes --] On Fri, Aug 03, 2007 at 07:34:39PM +0200, Rob Sterenborg wrote: > > I meant, there can't be no such processing ? > > > > 1/ > > -> ... > > -> match for the source address 192.168.10.14 > > |-> match for destination port 80 -> ACCEPT > > |-> match for the destination port 443 -> ACCEPT -> ... > > Yes, this is possible using a user defined chain. > This is waht I wanted to know, I can't get such a processing without the user defined chains ; Iptables doesn't do it by itself. Thanks. -- Franck Joncourt http://www.debian.org - http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 17:44 ` Franck Joncourt @ 2007-08-03 19:29 ` Grant Taylor 2007-08-03 20:03 ` Pascal Hambourg 0 siblings, 1 reply; 11+ messages in thread From: Grant Taylor @ 2007-08-03 19:29 UTC (permalink / raw) To: Mail List - Netfilter On 08/03/07 12:44, Franck Joncourt wrote: > This is waht I wanted to know, I can't get such a processing without > the user defined chains ; Iptables doesn't do it by itself. The IPTables rules you have posted do not do it, though I think you could use a mport match to accomplish what you are wanting to do. I.e.: iptables -A INPUT -s 192.168.10.14 -p tcp -m mport --source-ports 80,443 -j ACCEPT Grant. . . . ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 19:29 ` Grant Taylor @ 2007-08-03 20:03 ` Pascal Hambourg 2007-08-03 20:24 ` Grant Taylor 0 siblings, 1 reply; 11+ messages in thread From: Pascal Hambourg @ 2007-08-03 20:03 UTC (permalink / raw) To: Mail List - Netfilter Hello, Grant Taylor a écrit : > > The IPTables rules you have posted do not do it, though I think you > could use a mport match to accomplish what you are wanting to do. I.e.: Don't you mean the 'multiport' match ? The 'mport' match was never included in the vanilla kernel, is now deprecated and has been removed from the latest iptables release (1.3.8). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 20:03 ` Pascal Hambourg @ 2007-08-03 20:24 ` Grant Taylor 0 siblings, 0 replies; 11+ messages in thread From: Grant Taylor @ 2007-08-03 20:24 UTC (permalink / raw) To: Mail List - Netfilter On 08/03/07 15:03, Pascal Hambourg wrote: > Don't you mean the 'multiport' match ? The 'mport' match was never > included in the vanilla kernel, is now deprecated and has been removed > from the latest iptables release (1.3.8). I don't ever use it so I can not say for sure, so "Yes". I just pulled up a man page of IPTables on the web and found it so I used it. Grant. . . . ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 17:34 ` Rob Sterenborg 2007-08-03 17:44 ` Franck Joncourt @ 2007-08-03 20:23 ` Grant Taylor 1 sibling, 0 replies; 11+ messages in thread From: Grant Taylor @ 2007-08-03 20:23 UTC (permalink / raw) To: Mail List - Netfilter On 08/03/07 12:34, Rob Sterenborg wrote: > This would IMHO only be of real use if you have lots of rules and you > want to narrow down the number of rules to be matched. Agreed. This is an example of how to optimize the packet flow through the IPTables chains and rules. Really it comes down to how many decisions have to be made for any given packet and trying to rearrange the chains and rules for optimal packet flow. Rules are processed serially / linearly / one by one / (what ever you want to call it) with in a chain, so the idea is to reduce the number of individual rules and the complexity there is to make packet traversal as fast as possible. > In this case you won't notice the difference. Presuming that the rules that we saw were the only rules in the OPs rule set I'll agree. However if there were 10s to 100s to 1000s (or more) of these sets of rules, then the OPs rule set could very likely benefit from optimization. Depending on the number of rules it may be very much worth the time to split a /24 block in to multiple smaller blocks. Grant. . . . ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 17:07 ` Franck Joncourt 2007-08-03 17:34 ` Rob Sterenborg @ 2007-08-03 18:43 ` John A. Sullivan III 1 sibling, 0 replies; 11+ messages in thread From: John A. Sullivan III @ 2007-08-03 18:43 UTC (permalink / raw) To: Franck Joncourt; +Cc: netfilter On Fri, 2007-08-03 at 19:07 +0200, Franck Joncourt wrote: > On Fri, Aug 03, 2007 at 06:23:10PM +0200, Ray Leach wrote: > > > > > > Franck Joncourt wrote: > >> Hi, > >> > >> Assuming we have the next two rules in our ruleset : > >> > >> iptables -A INPUT -s 192.168.10.14 -p tcp --dport 80 -j ACCEPT > >> iptables -A INPUT -s 192.168.10.14 -p tcp --dport 443 -j ACCEPT > >> > >> I was wondering whether rules are processed one by one. > >> In the two rules above, we have to check the source address > >> 192.168.10.14, so I think this is done for the first one, and then for > >> the second one. I am not quite sure ; Can anyone confirm that ? > >> > >> > > Yes, rules are processed one by one until a rule matches the packet. > > > > So the first rule above would be matched for traffic coming from > > 192.168.10.14 going to port 80 (192.168.10.14 browses a website) > > The second rule would be matched when 192.168.10.14 tried to browse a > > secure website. > > > > Since bothe these rules are in the INPUT chain, they will only be matched > > when the source ip tried to access those ports on the machine running > > iptables. > > > > I meant, there can't be no such processing ? > > 1/ > -> ... > -> match for the source address 192.168.10.14 > |-> match for destination port 80 -> ACCEPT > |-> match for the destination port 443 -> ACCEPT > -> ... > > > According to me, it works this way : > > 2/ > -> ... > -> match source address 192.168.10.14 AND destination port 80 > |-> ACCEPT > -> match source address 192.168.10.14 AND destination port 443 > |-> ACCEPT > ->... > > In the case 1, we check the source address once, and in the second one, > twice. So the first case would be quicker to process than the second > one where there is no optimalisation. > > I know what these rules do, but this is just an example, and I know how > the user chains work as well :p! > Yes, you are correct that user defined chains are a way to optimize this. I do not know much about ipsets but I wonder if that would also help. We face this constantly on the ISCS network security management project (http://iscs.sourceforge.net). We use it to create micro-perimeter solutions where network access is on an as-needed basis only. Thus we have to describe every information flow within the organization. The result can be hundreds of thousands of rules. To optimize the processing, we break the question of WHO has ACCESS to WHAT into three separate stages and answer each separate, i.e., WHO are you, what kind of ACCESS do you have and WHAT are you trying to access. This gives us two advantages: 1) it dramatically reduces the size of complex rule sets because we only need one rule for each WHAT, ACCESS and WHAT instead of a separate rule for each possible combination of WHO, ACCESS and WHAT. 2) It makes traversal of the rule set more efficient. It is, in effect, indexed. Once we know WHO you are, we only need to worry about the rules that pertain to you. We have been wondering if ipsets wouldn't further optimize our processing. If anyone out there with a good understanding of ipsets would like to give us a hand with this project, please let me know. -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan@opensourcedevel.com Financially sustainable open source development http://www.opensourcedevel.com ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Iptables rules processing 2007-08-03 16:13 Iptables rules processing Franck Joncourt 2007-08-03 16:23 ` Ray Leach @ 2007-08-04 20:37 ` Elvir Kuric 1 sibling, 0 replies; 11+ messages in thread From: Elvir Kuric @ 2007-08-04 20:37 UTC (permalink / raw) To: netfilter Hi all, in iptables like in many other firewall/access list ( like in Cisco ) programs firewall rules are checked one by one, so in many cases is problem if we do not care about specific requests and forget to include all neccesary in firewall rules. According to me, best place for all related to iptables is this mailing list and next web location http://iptables-tutorial.frozentux.net/iptables-tutorial.html Best wishes Elvir Kuric On 8/3/07, Franck Joncourt <franck.joncourt@wanadoo.fr> wrote: > Hi, > > Assuming we have the next two rules in our ruleset : > > iptables -A INPUT -s 192.168.10.14 -p tcp --dport 80 -j ACCEPT > iptables -A INPUT -s 192.168.10.14 -p tcp --dport 443 -j ACCEPT > > I was wondering whether rules are processed one by one. > In the two rules above, we have to check the source address > 192.168.10.14, so I think this is done for the first one, and then for > the second one. I am not quite sure ; Can anyone confirm that ? > > -- > Franck Joncourt > http://www.debian.org - http://smhteam.info/wiki/ > GPG server : pgpkeys.mit.edu > Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFGs1QOxJBTTnXAif4RAmR0AJ9v7hd+KU7PNzrb5O7hnTQwdVGEvQCgziNX > NBHg4yEhbaFKlArhH722UE4= > =capX > -----END PGP SIGNATURE----- > > ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2007-08-04 20:37 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2007-08-03 16:13 Iptables rules processing Franck Joncourt 2007-08-03 16:23 ` Ray Leach 2007-08-03 17:07 ` Franck Joncourt 2007-08-03 17:34 ` Rob Sterenborg 2007-08-03 17:44 ` Franck Joncourt 2007-08-03 19:29 ` Grant Taylor 2007-08-03 20:03 ` Pascal Hambourg 2007-08-03 20:24 ` Grant Taylor 2007-08-03 20:23 ` Grant Taylor 2007-08-03 18:43 ` John A. Sullivan III 2007-08-04 20:37 ` Elvir Kuric
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.