Mailing List Archive

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

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

> 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

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

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

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

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

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

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

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