multiport tolerance changes

multiport tolerance changes

[Vincent Regnard]

Hi all,

I recently upgraded my firewall setup. Mainly upgrading kernel from 
2.6.8 to 2.6.16 and iptables from 1.2.7 to 1.3.5. And I had to modify my 
  firewall rules due to what I think is a syntax tolerance change 
regarding multiport.

With iptables 1.2.7 I had some rules where I could write some multiport 
(port lists or ranges) both for source and destination ports, like this:

/sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87 
--sport 1024:65535 -d 0.0.0.0/0 --dports 80,8080,81,8000,1755 -j ACCEPT

iptables was coping well with this and expanded the port matrix into 
appropriate single rules (ipchains was also able to do this well in its 
good time). But  iptables 1.3.5 refuses to have multiport for both 
source and destination ports and objects:

iptables v1.3.5: multiport can only have one option

So I have to re-write my firewall rules.

What is the reason why this practical feature (expanding the port 
matrix) disapeared ? Is it related to the merge of extended multiport 
into multiport (including ranges in lists) ?
Is there any plan to re-introcduce such a functionality in the future 
releases of iptables ?

Thanks for your comments on this.

Vincent

Re: multiport tolerance changes

[Pascal Hambourg]

Hello,

Vincent Regnard a écrit :
> 
> With iptables 1.2.7 I had some rules where I could write some multiport 
> (port lists or ranges) both for source and destination ports, like this:
> 
> /sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87 
> --sport 1024:65535 -d 0.0.0.0/0 --dports 80,8080,81,8000,1755 -j ACCEPT
> 
> iptables was coping well with this and expanded the port matrix into 
> appropriate single rules

What do you mean ? Could you give an example of such expansion ?

> But iptables 1.3.5 refuses to have multiport for both 
> source and destination ports and objects:
> 
> iptables v1.3.5: multiport can only have one option

Well, it seems that my old iptables 1.2.6a already had the same 
limitation. I submitted your rule to it and got an error too.

> So I have to re-write my firewall rules.

How did you rewrite the above rule ?
If I reorder the options, so that the --sport parameter appears to 
belong to the implicit "-m tcp" match created by "-p tcp", the rule is 
accepted by my iptables 1.2.6a :

/sbin/iptables -A fw2net_eth3 -s 82.67.103.87 -d 0.0.0.0/0 \
   -p tcp --sport 1024:65535 -m multiport --dports 80,8080,81,8000,1755 \
   -j ACCEPT

As a general rule it seems to me that it is more logical and readable to 
put the parameters of a match right behind the match.

PS: what's the use of "-d 0.0.0.0/0" ?

Re: multiport tolerance changes

[Vincent Regnard]

Pascal Hambourg a écrit :
> Hello,
> 
> Vincent Regnard a écrit :
>>
>> With iptables 1.2.7 I had some rules where I could write some 
>> multiport (port lists or ranges) both for source and destination 
>> ports, like this:
>>
>> /sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87 
>> --sport 1024:65535 -d 0.0.0.0/0 --dports 80,8080,81,8000,1755 -j ACCEPT
>>
>> iptables was coping well with this and expanded the port matrix into 
>> appropriate single rules
> 
> What do you mean ? Could you give an example of such expansion ?

The expansion in that case becomes:

     0     0 ACCEPT     tcp  --  *      *       82.67.103.87
0.0.0.0/0          tcp spts:1024:65535 dpt:8080
     0     0 ACCEPT     tcp  --  *      *       82.67.103.87
0.0.0.0/0          tcp spts:1024:65535 dpt:81
     0     0 ACCEPT     tcp  --  *      *       82.67.103.87
0.0.0.0/0          tcp spts:1024:65535 dpt:8000
     0     0 ACCEPT     tcp  --  *      *       82.67.103.87
0.0.0.0/0          tcp spts:1024:65535 dpt:1755

> 
>> But iptables 1.3.5 refuses to have multiport for both source and 
>> destination ports and objects:
>>
>> iptables v1.3.5: multiport can only have one option
> 
> Well, it seems that my old iptables 1.2.6a already had the same 
> limitation. I submitted your rule to it and got an error too.
> 
>> So I have to re-write my firewall rules.
> 
> How did you rewrite the above rule ?

I suppressed the SOURCE port range and the rule becomes more permissive
(but works):

/sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87 -d
0.0.0.0/0 --dports 80,8080,81,8000,1755 -j ACCEPT

> If I reorder the options, so that the --sport parameter appears to 
> belong to the implicit "-m tcp" match created by "-p tcp", the rule is 
> accepted by my iptables 1.2.6a :
> 
> /sbin/iptables -A fw2net_eth3 -s 82.67.103.87 -d 0.0.0.0/0 \
>   -p tcp --sport 1024:65535 -m multiport --dports 80,8080,81,8000,1755 \
>   -j ACCEPT
> 

I confirm that when writing it that way (reordering properly) I also
have no more error. But for some protocol, I would like to be able to
write some source port range and also some destination port range. A
rule like this:

/sbin/iptables -A fw2net_eth3 -p tcp -m multiport -s 82.67.103.87
--sports 10000,10001,10002 -d 0.0.0.0/0 --dports 80,8080,81,8000,1755 -j
ACCEPT

And such a rule actually does not work.

> As a general rule it seems to me that it is more logical and readable to 
> put the parameters of a match right behind the match.

You're right, but I have some constraints that does not permit this
right now.

> 
> PS: what's the use of "-d 0.0.0.0/0" ?
> 
> 

0.0.0.0 is here just because I use shell script variable for my rules
and sometimes it gets replaced with a "proper" IP bloc or address
I have some general scripts that generate config for many routeurs, the
config are then uploaded onto the routers for iptables treatment. A kind
of general firewall configuration generator based on per router DB
variables.