Re: UDP scanning within Nmap

[Chris McNab <chris () cloudsoc net>]

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 that
> just
> > sends crafted UDP datagrams to the various ports? It would be so much
> faster
> > and 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 the
> example
> > below, 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/