Re: rpc-grind.nse timeout

[Daniel Miller <bonsaiviking () gmail com>]

On Mon, Aug 25, 2014 at 11:39 AM, Pavel Kankovsky <kan () dcit cz> wrote:

> I scanned a large number of addresses with lots of open|filtered UDP ports
> with -sV --version-light and it seemed to me Nmap spent too much time in
> rpc-grind.nse.
>
> It turns out rpc-grind.nse waits 30 seconds (the standard NSE timeout) for
> every response including its initial check whether the port is a Sun RPC
> service at all (isRPC)--as opposed to 5 seconds for (most) probes in
> nmap-service-probes.
>
> To add insult to injury, it wastes time in isRPC even when all the ports
> have already been probed with RPCCheck and neither of them has responded.
>
> I do not know how to make rpc-grind.nse aware of the (negative) results of
> service scan--and I do not even known whether it would be desirable--but I
> tried something else: I patched isRPC (see the attachment; I had to touch
> nselib/rpc.lua too) to time out after 5 seconds.
>
> A very simplistic test perfomed on a tiny subsample of my original scan
> (one typical host, 100 TCP + 100 UDP ports) shows the patch reduces time
> needed to finish such scan from cca 210 seconds (55 in service scan, 150 in
> NSE) to 105 seconds (45 in NSE).
>
> Correct me if I am wrong but I suppose that 5 s timeout is good enough for
> rpc-grind.nse if it is good enough for various non-NSE service probes
> including RPCCheck.

Pavel,

Thanks for this report! We've discussed timeouts recently [1], so this
seemed like a good candidate for conversion to the "new" way of doing
things. r33622 changes the timeout for *all* rpc scripts from the default
30s to 5 times Nmap's calculated host timeout (fairly safe) or 10s if that
info is not available.

Keep an eye out for further timeout changes. Some ideas:

* Implement this timeout defaulting as a stdnse function.
* Enforce a minimum timeout (e.g. 1s min, 5s max, but use
host.times.timeout between the two?)
* Keep ultrascan's ping timing probes going during version scan and NSE
phases (this would require major overhaul of core parts of Nmap)

Dan

[1] http://seclists.org/nmap-dev/2014/q3/188
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/