Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: NSE console script help
From: Fyodor <fyodor () insecure org>
Date: Tue, 18 Jan 2011 18:24:32 -0800

On Tue, Jan 18, 2011 at 08:27:10PM +0100, Martin Holst Swende wrote:

If I use: "nmap foobar.com --script=all --script-args=help", lets
say nmap discovers the for me totally unknown service
"gazonk". Perhaps there is a very uncommon script which is a bit
intrusive, and not default, written specifically for the gazonk
service.  The chances of me finding that script are small, normally,
but since the command above will print only[1] the help about that
particular script, I will have a higher chance of finding the right
script for the task.

Well, the way I see it, there are four main script help selection

1) Print the script help info for all scripts known by Nmap

2) Print the info for all scripts selected (by a specifier, like
   "default" or "safe" or "broadcast" or "asn-query" or whatever).  In
   this case, you can get behavior #1 by specifying "all".

3) Print just the scripts which pass their rule (portrule, hostrule,
   prerule, or postrule) and thus would be (or are) actually run by Nmap.

4) Print just the help for the scripts which actually produced output.
   That way users don't end up with output from scripts they don't
   really understand.

Speaking of #4, maybe our nmap.xsl converter should link link the
script name in script output directly to

Now which of these four selection possibilities are most important,
and what sort of API we should use to provide them, is a tougher

One question is how much work you want Nmap to do when you ask for
help.  With #1 and #2, you could either print the information
immediately and then stop, or you could let the scan continue.  The
advantage of stopping is that it lets people see their script options
before committing to running them.  I suppose the advantages of
continuing are that it puts the information there in the Nmap report
along with the results (avoids running Nmap twice), and (more
importantly) might be more consistent if we also offer #3 and #4.

For #3, Nmap needs to do its port scanning, OS detection, version
detection, and run at least the script portrules.  For #4, Nmap needs
to completely execute.  So if we want to support these, it pretty much
dictates an interface which runs the scan AND produces help.

There is also the issue of interface ease of use.  To support only #1,
we just need a new Nmap option without requiring any options.  "nmap
--script-help" would do the trick.  We'd probably just print the help
and not do a scan.

To support only #2, we would either have to take a script specifier
like "default" for --script-help, or we'd have to require that the
user also pass an existing scripting option like --script, -A, or -sC.
We would have the option of doing an actual script scan, or just
printing the help.

To support only #3 or #4, we'd need a new option like --script-help
and it would have to pair with existing scripting options like
--script, -A, or -sC.  And we would have to do the actual scanning too
(possibly just to the point of rule evaluation for #3).

We could support multiple stages #1 through #4, but that also
increases complexity.

It is worth noting that each one is a superset of the higher-numbered
options.  So #2 contains all the scripts (and possibly more) in #3,
and so on.

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]