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

[Kris Katterjohn <katterjohn () gmail com>]

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

On 08/11/2010 08:24 AM, Djalal Harouni wrote:
> Hi Kris,
>
> On 2010-08-10 19:19:41 -0500, Kris Katterjohn wrote:
> > * 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.

OK, that makes sense.  I wasn't thinking about it the right way: I was more
just in a mode of "cool, we can script host discovery".  prerule + target
adding just seemed to be synonymous since I only glanced at commits and emails
but hadn't followed closely (too bad for me).

> > 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.

Cool, I look forward to this (I'm having a hard time thinking of concrete
examples for postrules, although I haven't yet dug around in the registry to
see what all is all ready available).

> > * 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.

Cheers,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJMYvGkAAoJEEQxgFs5kUfuLpIP/i6D+wswgQISoaMZ7hXNMPaG
0oKp4exOKBkjbvDEUy6Kp4hSzkgl8WPIGB/i+8eJbUqlfbKT7LEObLJ7pz5hDNB6
KjSqYVY7U4KyXFL3rb2u3aqcYSfA6IhODE3SiKvRSksvw6z+KiXLsusWZpcaW79w
FIWRBWkFc71IuR/NePhmwwXCirKrs1aRapdpbdRNxVtoV22IEbeJRf7ph4phdf5Q
EXixB2wyAEAGajv6uPAa1wWDkRMEI/EULm7GQgrb3dkwj+xC6B61Fah7rNJS5tyv
jUdPxSV2Qu1ClA+4IGiAPNNBs81FzBehRMcU4YWPiacf3ZC9TfiXLjZetF2WO4d/
2GsGTGi+h5HBV50fbJoU7htlTnhukzDeHrTwReXvBb2trnuWOCnKg4sS8NAdr/sQ
FXGDaDpkSXrqPqGTSX8/2Ti0MPaoKfkpmo7XPfXaSYKPKSu4ydOZPbSahN1b7B+8
+n2Z65MCPpk+ZRrXjoU6ou/yT9G8BhVGjy4eFs3lAjk/lhuRqU//h9z55Ek2oYX+
xNeJTxm0lMgjI+ztMfGgpvLoEYNI6KPw8v8vVRB9cu+/R5al+oIYUw5jaEJDTBs5
fkJQVtZJc+7/HVNSue9hCjeTnHCh71Q07aGazS0x0AVOZ3mUV7W4bczlG0ao1hsU
n6Mo5/81MBKwRmMvtanu
=Mz7j
-----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/