Re: [RFC] Basing timeouts in NSE on host.times.timeout

[Daniel Miller <bonsaiviking () gmail com>]

On Fri, Aug 1, 2014 at 10:12 AM, Patrick Donnelly <batrick () batbytes com>
wrote:

> Hi Daniel,
>
> On Fri, Aug 1, 2014 at 12:00 AM, Daniel Miller <bonsaiviking () gmail com>
> wrote:
> > List,
> >
> > Right now, there are several sources of default timeouts on socket
> > operations within NSE:
> >
> > * A socket created by nmap.new_socket() has a timeout of 30 seconds
> > * The sockets used in the comm.lua library have 8-second timeouts
> > * of all the calls to set_timeout, a plurality (44%) are 5 seconds, with
> > the remaining 56% evenly split between 10 seconds and other times
> (ranging
> > from 10ms to 50s)
> >
> > In a large number of these cases (portrule and hostrule scripts), the
> > socket is intended to communicate with a port on a host for which Nmap
> > already has a timeout calculated, reported via the host.times.timeout
> > variable. It seems to me like a lot of these timeouts could be replaced
> > with:
> >
> > --was: socket:set_timeout(8000)
> > socket:set_timeout(((host.times and host.times.timeout) or 8) * 1000)
> >
> > Obviously this would not work for prerule, postrule, or external scripts.
> > But I think it's probably a huge improvement over the default 30-second
> > timeout!
> >
> > Does anyone have thoughts or concerns regarding this approach?
>
> I really like the idea. My only concern is that perhaps
> host.times.timeout may be too exact and perhaps we should add a few
> seconds? Or does it already include some wiggle-room?
>
> --
> Patrick Donnelly

host.times.timeout is what Nmap uses during the portscan phase, and it's
based on the round-trip time and variance. Specifically,

timeout = srtt + ( 4 * rtt_variance)

So there is some wiggle room. "srtt" is the smoothed-average RTT over the
course of the scan, weighted towards more-recent results. Unfortunately,
once the port scan phase finishes, Nmap stops monitoring the status of the
network (via "pings" or canary packets), so the real RTT could change
during the course of the later phases (version scan, NSE, etc).

Adding a few seconds makes sense, especially in some special cases where
some host-processing time may be required (e.g. UDP packet sent, target
processes for X seconds, target sends UDP response). It is ultimately up to
the script author. I also was not sure whether NSE/Nsock timeouts are
calculated based on actual arrive time of the response, since NSE
parallelism means a script thread could be waiting to resume while other
threads execute, even if the socket call it yielded on is able to complete.

Dan
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/