Nmap Development mailing list archives

Re: How to cancel a script scan


From: Toni Ruottu <toni.ruottu () iki fi>
Date: Mon, 4 Apr 2011 01:24:21 +0300

Would this be at all related to the the "scan playlist" feature we
were discussing earlier. The idea was that nmap would have a list of
pending so a script could add scans to the queue, in addition to
adding targets to the ongoing scan. The details about this are in the
air. No one knows have one should avoid adding duplicate scans into
the queue and how or if one should aggregate scan results. I just
thought I'd bring it up, as you are discussing resume, and I think
that is another type of scanning management thing.

On Mon, Apr 4, 2011 at 12:01 AM, Rob Nicholls <robert () robnicholls co uk> wrote:
I suspect we could make some major improvements to the hostgroup and resume
features, and it could make a good (if not slightly "boring" compared to
things like improving IPv6 support) GSoC project.

Even with things like --defeat-rst-ratelimit, a single host can tie up a
long scan and prevent the next scanning phase, or next hostgroup, from being
launched. Not being able to --resume just those remaining hosts, never mind
resuming where it had left off, is quite annoying as you have to scan the
entire hostgroup again (which is why I pretty much never use --resume, I try
to manually time scans to complete by a certain time, even if it means
manually merging XML data together). It might be useful if the hostgroup can
move onto the service scans and NSE scripts while the final hosts are still
undergoing their original portscans.

Those slow hosts can prevent the output from being written, and even if you
check the verbose output for the discovered ports, you won't end up with XML
output, which I find far more useful nowadays. It'd be nice if we could
somehow resume scans from and still generate the XML files - I know there
are issues, but what are they and can we work around them?

I'm aware that it could affect the grepable output and potentially break
(poorly written) scripts that people have written that assume, for example,
that completed IPs will match the input list order or range (e.g.
192.168.0.1-4 could produce scan results for .3, .2, .4 and finally .1).

Rob

-----Original Message-----
From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org]
On Behalf Of Ron
Sent: 03 April 2011 21:17
To: nmap-dev () insecure org
Subject: Re: How to cancel a script scan

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 29 Mar 2011 11:35:30 +0100 Houcem HACHICHA
<houcem.hachicha () gmail com> wrote:
Hello everyone,

Is there a way to cancel an undergoing script scan? (without losing
the portscan results of course)

Thanks in advance,
There's a secret way: pull out your network cable.

It doesn't work for every script, but in most cases it'll cause the script
scan to fail quickly.

Something that Nmap really ought to have, and maybe we should add it to the
TODO list if it isn't already there, is the ability to display the "output
so far" when you kill nmap with ctrl-c. That way, if you have to kill a scan
half-way through, you don't lose all the data you've already accumulated.

One step further would be to add a feature like Hydra or John has, where
it'll save its progress to a file and can resume from where it left off.
That'd be super awesome, but I'm not sure if it's possible.

Ron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk2Y1aUACgkQ2t2zxlt4g/SWoACeN8fUliIzHpc2LD9hxopYtgSb
XkEAoL47rEGWPO2vcTrtJWi9Fl7zXkrL
=p9ar
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


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

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


Current thread: