mailing list archives
Re: Nmap: problem with UDP scanning and --ip-options
From: David Fifield <david () bamsoftware com>
Date: Wed, 8 Jun 2011 17:18:24 -0700
On Tue, Jan 11, 2011 at 06:36:30PM +0100, Bogdan wrote:
I have a problem with nmap. It goes like this: when I scan a closed
UDP port with no IP options, nmap sends one UDP packet, gets one
packet back (ICMP destination unreachable, port unreachable),
determines that the port is closed and shows the port as closed in the
results (with reason port-unreachable).
Now, when I scan the same port with any IP options ("--ip-options U"
is the easiest), nmap sends 2 UDP packets (like it got no response for
the first), gets two ICMP packets back, but shows the port as
open|filtered (like it got no response).
Enabling debug mode shows:
Received short ICMP packet (86 bytes).
The total IP length in the received packets is set to 92 (20 for IP,
8 for ICMP, 20+36 for the erroneous packet with the options and 8 for
the UDP header) and this should be the expected length. But the
received packet isn't shorter, as nmap would suggest. Wireshark
recognises it easily.
Bogdan, please try the new version 5.52.IPv6.Beta2. I think this problem
is fixed through more careful header parsing.
Moreover, there is a second problem with this scan: if the erroneous
packet is artificially shortened to 28 bytes (20 for the shorter IP
header, instead of 56, and 8 for UDP), it is recognised correctly and
the port is marked as closed. But the RFC for ICMP says that the
"Internet header" should be included in the ICMP
destination-unreachable message. It doesn't say "The minimum Internet
header", so I guess it should be the full header, even if it's longer
that the minimum 20 bytes.
The third problem: the shortened packet's checksums can be freely
modified and nmap will still recognise the packet, parse it and mark
the port as closed.
Furthermore, rejecting incorrect ICMP packets is expected (incorrect
both in terms of checksums and the fact that the ICMP packet did not
contain the nmap's sent packet's header).
I'm not too worried about receiving packets that are too short or have
incorrect checksums. We should err on the side of matching broken
packets, I think.
The last question: is there an "open bug list" for nmap? Searching
the site and mailing lists on my question's topic didn't produce any
results, so I'm not sure if I'm not sending a duplicate report for
something already reported or marked as "not to be fixed".
The mailing list is the closest thing.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/
- Re: Nmap: problem with UDP scanning and --ip-options David Fifield (Jun 09)