Re: How to cancel a script scan

[Toni Ruottu <toni.ruottu () iki fi>]

There was some problem with p2p systems. We find an open port. The
port tells us that node has connections to certain other nodes running
on some host:port pairs. If we add all those hosts and ports as scan
targets, and scanning those hosts add further hosts and ports. Then
when we reach the last node, we are scanning a huge amount of ports
even, when we know exactly which port the service is running on.

There are two solutions to this problem. I call them "snipe scanning",
and "playlist scanning".

With snipe scanning support, a script could ask nmap to scan a
specific port on a specific host outside the actual scanning
specification. The problem with this approach I think, is that nmap
needs to then reserve memory on demand for storing the results of that
scan.

With playlist scanning the scans would be defined as scan
specification objects. When a script wants to scan some peer-to-peer
node, it takes the current scan specification, copies it, and modifies
the copy to target only that port on that host. It then asks nmap to
queue this scan specification in a "playlist", and after nmap has
fully completed the current scan it launches the new one. The problem
with this approach is that we will end up having results of completely
separate scans, and we need to figure out how we can aggregate them,
it may also be complex to avoid doing similar scans multiple times.

I think I'd be voting for the "snipe scan", but I am not sure what
kind of architectural changes implementing it would require. The
"playlist scanning" might be easier to implement, but I think the user
experience might end up ugly.

On Mon, Apr 4, 2011 at 9:43 AM, Rob Nicholls <robert () robnicholls co uk> wrote:
> Although I hadn't been thinking about that specifically, it definitely
> sounds like something that should be taken into consideration. If NSE script
> prescanning adds hosts at the start of the scan, for example, how does
> --resume know to add them again if it tries to resume halfway through a scan
> (as I presume, but haven't tested yet, that it won't redo the prescanning
> and effectively forgets about any new targets that were added by NSE)?
>
> If we had some sort of queue system that meant Nmap was always scanning X
> number of hosts (each time a host is complete it starts scanning the next),
> we could simply add hosts to the queue if they're not in the completed or
> current list of hosts. We could leave it to Nmap to internally remove
> duplicate hosts (or scripts), when letting NSE scripts add hosts to the
> scan.
>
> This might also help us improve one of the workarounds, where multiple FQDNs
> that resolve to the same IP will (IIRC) be port scanned repeatedly in
> separate host groups (as we lost some port scan results when in the same
> host group), when perhaps all we really want is to grab the existing port
> scan results for that IP and then run, for example, service and/or NSE
> scripts to capture information from a different virtual host (I imagine this
> could get tricky if we're running things like SMB scripts against the same
> host as we will duplicate tests unless we somehow mark scripts as being per
> IP or per host name, and should the results be duplicated/reported for each
> hostname? I'd suggest it'd be much easier to duplicate the output, at least
> initially).
>
> Rob
>
> -----Original Message-----
> From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org]
> On Behalf Of Toni Ruottu
> Sent: 03 April 2011 23:24
> To: Rob Nicholls
> Cc: nmap-dev () insecure org; Ron
> Subject: Re: How to cancel a script scan
>
> 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/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/