Re: [NSE] Script Pre-scanning and Post-scanning example

[Djalal Harouni <tixxdz () gmail com>]

Hi Kris,

On 2010-08-10 19:19:41 -0500, Kris Katterjohn wrote:
> This is from a scan against 192.168.1.1 (using Djalal's branch) with script
> args "newtargets,snmpinterfaces.server=192.168.1.1":
>
> Pre-scan script results:
> |_snmp-interfaces: Successfully added 3 new targets
> Nmap scan report for 192.168.1.1
> Host is up (0.022s latency).
> PORT    STATE  SERVICE
> 21/tcp  open   ftp
> 22/tcp  closed ssh
> 23/tcp  closed telnet
> 80/tcp  open   http
> 443/tcp closed https
>
> Nmap scan report for 192.168.10.6
> Host is up (0.017s latency).
> PORT    STATE  SERVICE
> 21/tcp  open   ftp
> 22/tcp  open   ssh
> 23/tcp  closed telnet
> 80/tcp  open   http
> 443/tcp closed https
>
> ssh is only running on the added interface (Ethernet), which would stay
> unknown if only 192.168.1.1 (SLIP) was scanned alone.
>
> (Also notice that the script adds 3 new targets but only 1 (192.168.10.6) is
> shown here.  Only one added host is scanned, but Djalal mentioned that he is
> working on fixing this in his branch [thus I haven't tested multiple added
> addresses].  These other addresses not added are actually the address we
> probed and the host's localhost-- Nmap itself needs to make these checks to
> keep this out of scripts.  Unfortunately I haven't yet checked Djalal's branch
> to see what all is checked so far so I can't comment any further.)
Yes, there is a bug that prevents Nmap from getting all the new targets,
however the targets are saved onto the cache. I'm working on it and I'll
perhaps do other changes too.

For target filtering, currently we filter only the new NSE scripts added
targets (to prevent to add the same target twice).  We do not filter
classic Nmap targets, so we can run in a situation when an NSE script adds
a target to the scan queue, that was already scanned or will be scanned
by Nmap.
The plan is to get the adding target feature work, and after that we
must provide a better solution for *all* targets filtering: Nmap targets
and new targets provided by NSE scripts.

> Notes on this patch:
>
> * The snmpinterfaces.server arg is required to specify the SNMP host to probe
> for interface addresses.  An optional port arg is available to specify a port
> other than 161.  This is just like the dns-zone-transfer changes.
>
> * The pre-scan output is not the usual snmp-interfaces output, but rather just
> a line stating how many targets were successfully added.  The prerule
> functionality for this script in this patch is to add targets and so I thought
> the output should pertain solely to that.
Yes, if the user runs the script scan with --script-args "newtargets"
then he wants to add targets to Nmap, however if the script argument
"newtargets" is not present, and the other necessary script arguments that
will let the script to run in the pre-scanning (prerule) phase, then
perhaps the user wants simply to see the *output* of the script in the
pre-scanning phase.

> Notes in general:
>
> * It started bothering me working on this patch that scripts could get quickly
> cluttered with different branches for prerule, postrule, etc. when script
> functionality may only be slightly related amongst phases.
>
> A thought I had would be to check if a script offers functions named things
> like postaction() and execute these hooks instead of action() in the post-scan
> phase (for example)-- this way script authors have control on clutter and can
> separate it with NSE easily obliging.  Scripts which don't have these hooks
> are just called with action() like normal.
>
> A counter-argument to this could be to just add more code to libraries and
> have separate script to prerule and postrule if they are substantially
> different enough to warrant things like postaction().  But the latter could
> mean very specific things added to libraries which only these scripts would
> use, which then just needlessly clutters libraries.
>
> If all multiphase scripts are simple enough (it wouldn't make sense to use
> postaction or something like that in my patch, for example) then this won't be
> a problem, but some forethought may save future headaches.  Who knows, maybe
> simply breaking up action() will always be best if the phases make it too messy.
The solution provided by Patrick is perfect. I want simply to add
something: I think that a script that can runs in both pre-scanning
phase (prerule) and script scanning one (hostrule and portrule) is a
greate feature and we can share the same code between these phases,
however the post-scanning phase is special one, it aims to be for results
and statistics gathering so it may collect other scripts results, and we
should use some standard name usage for them, like: snmp-stats.nse or
snmp-win32-stats.nse etc, in general these scripts will report any
results that were saved onto NSE registry. I'll try to post more examples
later.

> * Djalal's work on these different phases seems to work well.  I've only
> really tested with this patch (prerule), but I didn't have any problems.
Thx for testing and for these greate script ideas Kris.

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