Re: A hang towards the end of the "Slow comprehensive scan"

[Daniel Miller <bonsaiviking () gmail com>]

On 06/20/2012 09:16 AM, Whit Blauvelt wrote:
> On Tue, Jun 19, 2012 at 08:27:52PM -0400, Whit Blauvelt wrote:
> > On Tue, Jun 19, 2012 at 03:19:44PM -0700, David Fifield wrote:
> > > nmap -sS -sU -T4 -A -v -PE -PS80,443 -PA3389 -PP -PU40125 -PY --source-port 53 --script "default or (discovery and 
> > > safe)"
> Let me put this in the form of a development suggestion. I'm running now
> with the current "Slow comprehensive scan" as above, and it appears to be
> getting hung up right towards the end:
>
> Service scan Timing: About 97.58% done; ETC: 09:03 (0:17:46 remaining)
> Completed Service scan at 09:03, 44085.36s elapsed (16083 services on 18 hosts)
> Initiating OS detection (try #1) against 18 hosts
> Retrying OS detection (try #2) against 16 hosts
> Retrying OS detection (try #3) against 11 hosts
> Retrying OS detection (try #4) against 11 hosts
> Retrying OS detection (try #5) against 11 hosts
> Initiating Traceroute at 09:03
> Completed Traceroute at 09:03, 3.11s elapsed
> Initiating Parallel DNS resolution of 27 hosts. at 09:03
> Completed Parallel DNS resolution of 27 hosts. at 09:03, 0.12s elapsed
> Initiating System CNAME DNS resolution of 2 hosts. at 09:03
> Completed System CNAME DNS resolution of 2 hosts. at 09:03, 0.03s elapsed
> NSE: Script scanning 18 hosts.
> Initiating NSE at 09:03
>
> It's been stuck there for an hour. I'm guessing that for my case this may be
> from one specific script in the set that's not runnable in my context for
> whatever reason. So a question:
>
> - Is there a switch I could have added to the profile that would have caused
>    each script to be named as it is run, so it would be obvious where it's
>    hanging up?
>
> And the suggestion:
>
> - If there is, put it in the default profile. How can it hurt to know?
>
> The default invocation of something that's going to take many hours to run,
> and that has any likelihood of getting hung up during the run, should
> include enough debugging information to learn where the hang up is, IMHO.
> (I'm sure I should RTFM, and will probably buy the book. Still, why not
> tweak defaults towards the ideal?)
>
> Best,
> Whit
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
Information about which script is running is available from debug 
output, which you can enable with the -d option. When running Nmap 
directly in a console, you can increase the debug level by pressing "d" 
while the scan runs, and pressing enter (or most other keys) will give a 
detailed snapshot of current status, including a backtrace of the 
scripts currently running. Unfortunately, this functionality is not 
available in Zenmap at the moment.

Perhaps interactivity should be supported in Zenmap? Even if it were in 
the form of buttons rather than hotkeys. The capability is likely tied 
up in the same terminal detection that is causing problems for users of 
sudo, as reported in this thread: 
http://seclists.org/nmap-dev/2012/q2/44 (I can report that it works just 
fine under gdb).

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