multiport needs `-p tcp', `-p udp' - Why?

DISCUSSION U. George 4 participants 11 messages Feb 27, 2010 – Feb 28, 2010

Share & tools

U. George

author

2010-02-27 15:03 UTC #0 lore raw

In order to get to the chain, the protocol, as well as the interface must match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in order for it to work?

Quoted 5 lines

+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or -p dccp' Try iptables -h' or 'iptables --help' for more information.

ratheesh k

2010-02-27 15:06 UTC #1 lore raw

Port is in Layer 4 of protocol stack .

Quoted 20 lines · U. George

In order to get to the chain, the protocol, as well as the interface must match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in order for it to work?
Quoted 7 lines
+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP
iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

U. George

author

2010-02-27 16:17 UTC #2 lore raw

U'll have to let me know why "-p udp" is needed when the chain can only have udp packets, and therefor can only process udp packets.

I dont want to test over (( and over ) and over ) again when I know that the packet is already KNOWN to be from eth1 and of protocol UDP.

adding "-p UDP" to multiport does make iptables happy, but appears to be a useless test.

Quoted 30 lines · ratheesh k

Port is in Layer 4 of protocol stack .
Quoted 15 lines · U. George
In order to get to the chain, the protocol, as well as the interface must match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in order for it to work?
Quoted 7 lines
+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP
iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

ratheesh k

2010-02-27 16:46 UTC #3 lore raw

port offset may be differ based on which layer 4 protocol , you are using . If u dont specify protocol ( layer 4 ) , netfilter dont know this .

Please find below some code sinppet from xt_multiport.c .

113 pptr = skb_header_pointer(skb, protoff, sizeof(_ports), _ports);
114 if (pptr == NULL) {
115 /* We've been asked to examine this packet, and we
116 * can't. Hence, no choice but to drop.
117 */
118 duprintf("xt_multiport: Dropping evil offset=0
tinygram.\n");
119 *hotdrop = 1;
120 return 0;
121 }
122
123 return ports_match(multiinfo->ports,
124 multiinfo->flags, multiinfo->count,
125 ntohs(pptr[0]), ntohs(pptr[1]));

thanks,
Ratheesh

Quoted 48 lines · U. George

U'll have to let me know why "-p udp" is needed when the chain can only have udp packets, and therefor can only process udp packets.
I dont want to test over (( and over ) and over ) again when I know that the packet is already KNOWN to be from eth1 and of protocol UDP.
adding "-p UDP" to multiport does make iptables happy, but appears to be a useless test.
Quoted 27 lines · ratheesh k
Port is in Layer 4 of protocol stack .
Quoted 17 lines · U. George
In order to get to the chain, the protocol, as well as the interface must match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in
order for it to work?
Quoted 7 lines
+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP
iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

U. George

author

2010-02-27 17:28 UTC #4 lore raw

source port offset for udp and tcp are both at 0 for IPv4
destination port offset for udp and tcp are both at 16 for IPv4

Quoted 79 lines · ratheesh k

port offset may be differ based on which layer 4 protocol , you are using . If u dont specify protocol ( layer 4 ) , netfilter dont know this .
Please find below some code sinppet from xt_multiport.c .
113 pptr = skb_header_pointer(skb, protoff, sizeof(_ports), _ports);
114 if (pptr == NULL) {
115 /* We've been asked to examine this packet, and we
116 * can't. Hence, no choice but to drop.
117 */
118 duprintf("xt_multiport: Dropping evil offset=0
tinygram.\n");
119 *hotdrop = 1;
120 return 0;
121 }
122
123 return ports_match(multiinfo->ports,
124 multiinfo->flags, multiinfo->count,
125 ntohs(pptr[0]), ntohs(pptr[1]));
thanks,
Ratheesh
Quoted 48 lines · U. George
U'll have to let me know why "-p udp" is needed when the chain can only have udp packets, and therefor can only process udp packets.
I dont want to test over (( and over ) and over ) again when I know that the packet is already KNOWN to be from eth1 and of protocol UDP.
adding "-p UDP" to multiport does make iptables happy, but appears to be a useless test.
Quoted 27 lines · ratheesh k
Port is in Layer 4 of protocol stack .
Quoted 17 lines · U. George
In order to get to the chain, the protocol, as well as the interface must match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in
order for it to work?
Quoted 7 lines
+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP
iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Dennis J.

2010-02-27 17:18 UTC #5 lore raw

In reply to U. George

Rules are independent. The port rule does inherit anything from the chain rule so when you tell iptables to block port(s) you have to specify the protocol again.

Regards,
Dennis

Quoted 46 lines · U. George

U'll have to let me know why "-p udp" is needed when the chain can only have udp packets, and therefor can only process udp packets.
I dont want to test over (( and over ) and over ) again when I know that the packet is already KNOWN to be from eth1 and of protocol UDP.
adding "-p UDP" to multiport does make iptables happy, but appears to be a useless test.
Quoted 26 lines · ratheesh k
Port is in Layer 4 of protocol stack .
Quoted 17 lines · U. George
In order to get to the chain, the protocol, as well as the interface must
match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in
order for it to work?
Quoted 7 lines
+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP
iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 6 lines
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Mart Frauenlob

2010-02-28 06:54 UTC #6 lore raw

In reply to U. George

Quoted 5 lines · On 27.02.2010 17:17, [email protected] wrote:

U'll have to let me know why "-p udp" is needed when the chain can only have udp packets, and therefor can only process udp packets.
I dont want to test over (( and over ) and over ) again when I know that the packet is already KNOWN to be from eth1 and of protocol UDP.

now if we add -p icmp -j PRE_UDP, what should iptables do now?

use 'ferm' if you are too lazy to write iptables rules:
http://ferm.foo-projects.org/

Quoted 6 lines

adding "-p UDP" to multiport does make iptables happy, but appears to be a useless test.
Quoted 1 line · ratheesh k
Port is in Layer 4 of protocol stack .

Very useless response ...

Quoted 10 lines

Quoted 10 lines · U. George
Quoted 7 lines
In order to get to the chain, the protocol, as well as the interface must
match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in
order for it to work?

Quoted 7 lines

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP
iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.

ratheesh k

2010-02-28 10:53 UTC #7 lore raw

Quoted 5 lines

Quoted 2 lines · ratheesh k
Quoted 1 line
Port is in Layer 4 of protocol stack .
Very useless response ...

Very true .
No more top posting . I did it by mistake .sorry.

Thanks,
Ratheesh

Quoted 47 lines · Mart Frauenlob

Quoted 5 lines · On 27.02.2010 17:17, [email protected] wrote:
U'll have to let me know why "-p udp" is needed when the chain can only have udp packets, and therefor can only process udp packets.
I dont want to test over (( and over ) and over ) again when I know that the packet is already KNOWN to be from eth1 and of protocol UDP.
now if we add -p icmp -j PRE_UDP, what should iptables do now?
use 'ferm' if you are too lazy to write iptables rules:
http://ferm.foo-projects.org/
Quoted 6 lines
adding "-p UDP" to multiport does make iptables happy, but appears to be a useless test.
Quoted 1 line · ratheesh k
Port is in Layer 4 of protocol stack .
Very useless response ...
Quoted 10 lines
Quoted 10 lines · U. George
Quoted 7 lines
In order to get to the chain, the protocol, as well as the interface must
match. PRE_UDP if already filtered for "-p udp" . So why does multiport require another check for -p udp? Does it really need to have that option in
order for it to work?
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
+ /sbin/iptables -t filter -N PRE_UDP
+ /sbin/iptables -t filter -A INPUT -i eth1 -p udp -j PRE_UDP
+ /sbin/iptables -t filter -A PRE_UDP -m multiport --dport 137,138,139,512,514,515,1433,1434 -j DROP
iptables v1.4.5: multiport needs -p tcp', -p udp', -p udplite', -p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.
TOP POSTING is <-- censored -->...
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

U. George

author

2010-02-28 13:59 UTC #8 lore raw

In reply to Mart Frauenlob

Quoted 8 lines · Mart Frauenlob

Quoted 2 lines
Quoted 2 lines
I dont want to test over (( and over ) and over ) again when I know that the packet is already KNOWN to be from eth1 and of protocol UDP.
now if we add -p icmp -j PRE_UDP, what should iptables do now?
use 'ferm' if you are too lazy to write iptables rules:
http://ferm.foo-projects.org/
Quoted 1 line
Quoted 1 line

Do what *I* say it should be doing. Do the jump. None of the tests in PRE_UDP chain would/should match, and the packet should fall out by the default policy of the chain. An iptable optimizer would recognize that the chain only tests for UDP, and would change the -p icmp -j PRE_UDP to -p icmp -j $(default policy) without going through any of the chain.

BTW: its not lazy to write efficient code.

Mart Frauenlob

2010-02-28 14:41 UTC #9 lore raw

Quoted 12 lines · On 28.02.2010 14:59, [email protected] wrote:

Quoted 9 lines · Mart Frauenlob
Quoted 3 lines
Quoted 1 line
I dont want to test over (( and over ) and over ) again when I
know that
Quoted 1 line
the packet is already KNOWN to be from eth1 and of protocol UDP.
now if we add -p icmp -j PRE_UDP, what should iptables do now?
use 'ferm' if you are too lazy to write iptables rules:
http://ferm.foo-projects.org/
Quoted 1 line
Quoted 1 line

Quoted 5 lines

Do what *I* say it should be doing. Do the jump. None of the tests in PRE_UDP chain would/should match, and the packet should fall out by the default policy of the chain. An iptable optimizer would recognize that the chain only tests for UDP, and would change the -p icmp -j PRE_UDP to -p icmp -j $(default policy) without going through any of the chain.

which of the 2 jumps is to give precedence?
how to judge? read your mind?

Quoted 2 lines

BTW: its not lazy to write efficient code.

ok, don't be lazy write the netfilter chain/jump optimizer :) Because such a thing does not exist, netfilter will not do what you want.

U. George

author

2010-02-28 15:17 UTC #10 lore raw

Quoted 1 line · Mart Frauenlob

which of the 2 jumps is to give precedence?

what 2 jumps. Iptable can execute 2 jumps at the same time?