Re: UDP scanning within Nmap

[Daniel Miller <bonsaiviking () gmail com>]

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
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/