Re: using previously discovered hosts, ports, and services?

[Daniel Miller <bonsaiviking () gmail com>]

On Wed, Apr 30, 2014 at 8:22 AM, Royce Williams <royce () techsolvency com>wrote:

> What is the simplest way to use existing lists of IP:port sets for use
> with multiple separate runs of service discovery, or recycling
> existing IP:port:service sets for use with multiple script runs?

Right now, the simplest way is to extract sets of hosts with the same port
open and pass the IPs to Nmap with -iL. Because Nmap is a port scanner
primarily, we've never really approached inputting port states from some
other source. It's usually just best to re-scan.


> Ideally, it would be great to be able to pass a 'grepable'-style
> host/port file straight to -iL, and have nmap DWIM, skip discovery,
> and go straight to service detection.  If services were also supplied,
> nmap could go straight to running requested scripts.

Other than the services part (but who knows?) this could possibly be
implemented with NSE-based port scanning, one of the potential outcomes of
d33tah's GSOC proposal this year. We'll see how that goes.


> Details and use cases follow.
>
> I would like to do something like the following:
>
> 1. Run a simple host and port discovery, saving the results.
>
> 2. Feed discovery results from #1 into various levels of service
> detection until I find the combination that I need, then run that
> service detection against the entire corpus. Save the results.
>
> 3. Feed service detection results from #2 into various scripts as needed.
This is essentially what Nmap already does, but spread across multiple
invocations. Can you explain more what you mean by "various levels of
service detection"? Nmap already tries to send only the most-likely probes
to each port.


> I've also read up on '--resume', but it sounds like it would not
> provide the granular control that I'm looking for.  It won't let me
> decide to use a different script, or easily combine sets of discovered
> hosts and ports, or easily repurpose existing discovery data.

Using --resume will not re-scan any machines that previously produced
output. Rather, it will continue scanning roughly where the previous scan
left off, using the same options. More to the point, Nmap does not produce
output (suitable for --resume) until some hosts have completely finished
the scanning process: host discovery, port scan, service detection, script
scanning, OS detection, etc.


> I would also like to be able to combine multiple host/port sets,
> including "pre-discovered" data from non-nmap sources, into a single
> corpus.
>
> This would also be great to "prime the pump" for service detection by
> using output from a previous run.  Nmap could quickly verify existing
> hosts, ports and services, and fall back to the general discovery and
> detection routines if there's a mismatch.  (Could this improve
> performance for re-scanning existing networks?)
Using this approach to re-scanning networks could leave you open to missing
newly-opened ports or newly-discovered services. We already try to use the
quickest means of discovering hosts and services, so I'm not sure how
having old results would provide any extra information.


> If there's no direct support for reusing discovery, is it possible to
> construct an artificial log file (for use with --resume) that
> accomplishes the same result?  (The 'grepable' format looks simplest,
> and I could write a script that would convert other data into grepable
> format.)  Or could I do an ordinary host/port/service run, save the
> logfile off, and then modify the logfile to let me "resume" at the
> point that a script would have started?
>
> If there is already a way to do this, please let me know which search
> terms would have turned it up.  Otherwise, please consider this a
> feature request. :-)

I think scripting this would be your best option currently. You may find it
easiest to create outputs using NSE scripts, since these can run at several
phases of a scan. Particularly, the reverse-index script (
http://nmap.org/nsedoc/scripts/reverse-index.html) may be of use.

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