hi folks!
assertation:
2.4.7 omits icmp port unreachable errors for unbound udp ports on non-local
interfaces. sounds strange? here are my observations:
linux host guardian
linux host ghanima
[session 1]
ghanima:~# tcpdump -i eth0 host guardian and port not ssh
tcpdump: listening on eth0
..
[session 2]
guardian:/home/guardian/therapy# nmap -sU -p 1-10 ghanima.endorphin.org
(nmap is asked to udp scan ghanima port 1-10)
Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
Interesting ports on (62.116.8.197):
Port State Service
1/udp open tcpmux
2/udp open compressnet
3/udp open compressnet
4/udp open unknown
5/udp open rje
6/udp open unknown
7/udp open echo
8/udp open unknown
9/udp open discard
10/udp open unknown
all ports opened? can't be!
let's look at the tcpdump trace on ghanima for it's eth0 output:
[session 1]
21:35:57.781649 guardian > ghanima.endorphin.org: icmp: echo request
21:35:57.781683 ghanima.endorphin.org > guardian: icmp: echo reply
21:35:58.096727 guardian.51277 > ghanima.endorphin.org.echo: udp 0
21:35:58.096871 guardian.51277 > ghanima.endorphin.org.8: udp 0
21:35:58.097673 guardian.51277 > ghanima.endorphin.org.discard: udp 0
21:35:58.098479 guardian.51277 > ghanima.endorphin.org.1: udp 0
21:35:58.099285 guardian.51277 > ghanima.endorphin.org.2: udp 0
21:35:58.100029 guardian.51277 > ghanima.endorphin.org.3: udp 0
21:35:58.100721 guardian.51277 > ghanima.endorphin.org.6: udp 0
..and so on.
really there are no icmp destination, port unreachable errors sent.
so nmap assumes all ports are opened.
some output filters in iptables, you might think?
ghanima:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
definatly not.
let's try something else:
[session 1]
ghanima:~# tcpdump -i lo
tcpdump: listening on lo
[session 2]
ghanima:~# nmap -sU -p 1-10 localhost
Starting nmap V. 2.54BETA22 ( www.insecure.org/nmap/ )
All 10 scanned ports on localhost (127.0.0.1) are: closed
Nmap run completed -- 1 IP address (1 host up) scanned in 1 second
ghanima:~$
[session 1]
21:43:05.255608 localhost > localhost: icmp: echo request
21:43:05.255648 localhost > localhost: icmp: echo reply
21:43:05.256945 localhost.41478 > localhost.www: . ack 4120283222 win 4096
21:43:05.256978 localhost.www > localhost.41478: R 4120283222:4120283222(0)
win 0 (DF)
21:43:05.558663 localhost.41458 > localhost.10: udp 0
21:43:05.558719 localhost > localhost: icmp: localhost udp port 10
unreachable [tos 0xc0]
21:43:05.559668 localhost.41458 > localhost.echo: udp 0
21:43:05.559688 localhost > localhost: icmp: localhost udp port echo
unreachable [tos 0xc0]
21:43:05.560165 localhost.41458 > localhost.discard: udp 0
21:43:05.560183 localhost > localhost: icmp: localhost udp port discard
unreachable [tos 0xc0]
.. and so on.
huch, now we have icmp errors replied for the udp probe packets.
this problem has been confirmed for at least for 2.4.7-pre8 in a totally
different network setup.
my debugging attempts so far:
for both scans, local and non local, the udp "No Port" counter is increased.
(/proc/net/snmp)
which means for both scans an icmp packet is tried to be transmitted as far
as concerning net/ipv4/udp.c
[from udp.c - line 917]
UDP_INC_STATS_BH(UdpNoPorts);
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PORT_UNREACH, 0);
i tried to use kdb to trace the icmp_send, but got stuck somewhere after
ip_output in dev_queue_xmit. so obviously 2.4.7 really tries to send
something out to eth0, but fails somewhere in low-level routines.
since i'm not that good at kernel debugging, i'm handing this issue over.
clemens
p.s.: i'm using 8139too for eth0, but that really shouldn't matter.
|