Nmap Development mailing list archives
Re: UDP scanning within Nmap
From: Chris McNab <chris () cloudsoc net>
Date: Wed, 12 Nov 2014 15:01:24 +0000
Hi Dan, Thanks for the feedback, and I absolutely agree with steps 1 and 2.. Regarding 3 however -- UDP scanning using ICMP unreachables as an indicator is already painfully slow. As we both know, many operating systems rate-limit ICMP unreachables, and many network devices are probably doing the same. If we can please just have a mode that scans using the UDP payloads (whatever they are), that would be great. I understand that I can just specify the individual ports, but that's not ideal if the payloads are being updated constantly. Speed is a real problem with UDP in Nmap for some reason, particularly when using -sV and invoking NSE scripts. For example, I ran a scan using nmap -Pn -sU -sV --open -p53,123,135,137,161 -vvv -n 10.3.0.1 which took 114 seconds to complete, testing only 5 ports of a single host across my LAN. Using -F to scan the 100 common ports of the same host took 10 minutes. If there's anything you can do there, that would be awesome. Regards and thanks, Chris On Tue, Nov 11, 2014 at 10:02 PM, Daniel Miller <bonsaiviking () gmail com> wrote:
Chris, Thanks for this analysis. My thoughts are inline below: On Mon, Nov 3, 2014 at 9:04 AM, Chris McNab <chris () cloudsoc net> wrote:Hi Dan, Any plans to decouple the two UDP scanning modes in Nmap? i.e. payload scanning (sending real datagrams to service ports and getting responses), and inverse scanning (relying on ICMP responses to infer open ports)Nmap's UDP scan (-sU) uses payloads where they are available, otherwise empty datagrams are sent. The interpretation of responses are the same: ICMP response means closed, UDP response means open, and no response is the ambiguous "open|filtered".The inverse scanning mode is slow and unreliable (and things get really painful with NSE). I also have never seen a UDP service listening on a non-standard port during a test. Can we please come up with a mode thatjustsends crafted UDP datagrams to the various ports? It would be so muchfasterand more robust/reliable than using the negative scanning mode.The payloads are read from the nmap-payloads file, so you can see which ports are supported by looking there: awk '$1=="udp"{print $2}' nmap-payloads If you really wanted to, you could restrict your scan to just these ports.I also noticed that Nmap didn't have a decent payload for DNS in theexamplebelow, but scanudp (http://examples.oreilly.com/9780596006112/tools/scanudp_v2.tgz) did, as follows..We actually do have a payload for 53/udp: # DNSStatusRequest udp 53 "\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00" The scanudp tool's payload is just different: // dig @ip localhost A 53, "dns", "\x68\x6c\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x09\x6c\x6f\x63\x61\x6c\x68\x6f\x73\x74\x00\x00\x01\x00\x01", 27,Anyway, so rolling-in the UDP payloads from scanudp and establishing a payload-only UDP scan mode would be awesome.More UDP payloads will definitely improve scan times against open services, but the real time-killer is the closed ports. If a system is using a firewall to drop probes, then Nmap will detect those drops pretty quickly, especially if the few open services are quick to respond (giving an accurate RTT and packet loss estimate). But if the host is rate-limiting the ICMP responses, then Nmap knows it ought to wait for them, and so it just keeps slowing down its probes until it matches the (slow) rate limit that the target is using for responses. For TCP scans, most hosts will not rate-limit RST packets (closed port responses), but some do. In this case, we have the --defeate-rst-ratelimit option which abandons accuracy in distinguishing closed ports from filtered ones. This allows it to focus only on open ports (which respond with SYN/ACK). We don't do the same for UDP because a port may be open even if it doesn't respond at all (because we haven't sent the proper payload). I can conceive of a --defeat-icmp-ratelimit option that would treat open|filtered UDP ports as closed, and only report the definitely-open ones as up. This would mean a greater loss of accuracy, since some open services would be missed. This could be partially remedied by expanding the nmap-payloads file to include the UDP probes from the nmap-service-probes file. As you saw in your output, service scan will often change the status of a port from open|filtered to open because of a received response. Based on your feedback, I see 3 areas of improvement that our volunteer developers can work on: 1. Research and add more UDP probes to nmap-payloads 2. Improve the quality of the existing payloads (research into which probes get good responses without being intrusive) 3. Consider the implications and plan for a --defeat-udp-ratelimit option. Thanks for your thoughts! Dan
-- Chris McNab CloudSOC LLC *www.cloudsoc.com <http://www.cloudsoc.com>*
_______________________________________________ Sent through the dev mailing list http://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: UDP scanning within Nmap Daniel Miller (Nov 11)
- Re: UDP scanning within Nmap Chris McNab (Nov 12)
- Re: UDP scanning within Nmap David Fifield (Nov 12)