nmap -- UDP scanning
('binary' encoding is not supported, stored as-is)
Using nmap for udp scanning, I commonly come across hosts such as this:
root@source# nmap -sU -P0 -T Aggressive -F target
Interesting ports on target:
(The 1004 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE VERSION
67/udp open dhcpserver
123/udp open ntp
161/udp open snmp
162/udp open snmptrap
I have tried using a dhcp/ntp/snmp client, to no avail.
It is well documented that UDP scanners wait for an "icmp port unreachable" message to differentiate between open/filtered
and closed ports. A software/hardware packet filter between the source and the target seems to be blocking these packets.
Seen as this method cannot be used, it does not seem feasible for nmap to generate any meaningful information in this
situation yet somehow it is differentiating between filtered and open udp ports.
To try and understand why this is happening I have done the following:
tcpdump host target
nmap -sU -P0 -p 123 target
...
123/udp open ntp
...
11:58:52.058304 IP source.45682 > target.ntp: [len=0] [|ntp]
11:58:58.069406 IP source.45683 > target.ntp: [len=0] [|ntp]
...
tcpdump host target
nmap -sU -P0 -p 15555 target
...
15555/udp filtered unknown
...
11:33:00.058216 IP source.41032 > target.15555: UDP, length: 0
...
If the port is open, nmap sends two udp packets with a length of zero -- no data is returned.
If the port is filtered, nmap sends a single udp packet with a length of zero -- no data is returned.
I can see a number of reasons for this:
* All packets sent from 'target' are being nat'd to another IP address and are being missed by the tcpdump filter.
I have however used "tcpdump port 123" with the same results.
* Nmap is using protocol specific methods to obtain these results and...
* I dont know how to use tcpdump
* I dont know how to use nmap
...
* magick
So I say to you, WTF?
- Josh Nunan
This archive was generated by hypermail 2.1.7
: Sat Apr 12 2008 - 10:53:58 EDT