Re: Script suggestions, take #3

[Martin Holst Swende <martin () swende se>]

On 02/07/2012 06:17 AM, Patrick Donnelly wrote:
> Hi Martin,
>
> On Sat, Feb 4, 2012 at 4:28 PM, Martin Holst Swende <martin () swende se> wrote:
> > I consider this feature finished, but would like some more eyes on it,
> > especially where I've touched the nse core stuff. Hoping to make this
> > stuff my first commit :)
> Good work with this patch! I have a couple implementation comments:
Thanks!

> o I don't think it's worth adding setVectorfield until we have more
> than one call site.
Sure, but I need to place it somewhere in order to get it into lua -
should I place the code directly where it's used instead?
> o All functions in nse_main.lua should be local.
> o string.len is not used in favor of the length operator (#)
Gotcha!
> General comments:
>
> I'd rather see "suggest" scripts be a special case of a regular
> "Script" (the class in the nse_main.lua). In that case, scripts would
> "run" normally but the action function would be replaced with a
> function that returns tailored output specific to the script-suggest
> feature. Then, the majority of the engine remains unaffected and the
> tailored script output would simply be "script-suggest: yadda yadda".
I made an attempt at that early in the development. One thing that
didn't quite work out
with that approach was that the output becomes a bit haphazard:
80/tcp open  http
|_http-enum: suggested {default, ...}
|_http-title: Go ahead and ScanMe!
|_http-foo : suggested {foo, bar}
 
The desired (and current) effect is that all suggestions are gathered
under a common
heading. I don't mind changing the underlying implementation to use
another mechanisms such
as the one you are proposing, but I want to keep the way it is presented.
Do you have any suggestion as to how that can be done?

> I also think that parsing the two sets of rules could be done
> simultaneously. You could add a prefix [1] which specifies a suggest
> flag similar to the force flag. The script-suggest rule set would
> presumably always follow the rule set specified in --script. So
> scripts which match --script-suggest are only loaded if they didn't
> match a rule in --script.
>
> That should eliminate a lot of the redundant code...
>
> [1] http://seclists.org/nmap-dev/2011/q4/467
I'm not sure I understand. Do you propose that the command-line syntax
is changed, or only the implementation?
I think you mean the former.

Below are some usecases. Let's say we use the $-char for the
suggestions, I'll outline possible syntaxes:

#Typical scan with defaults, but show me what more I can do:
Current #1: nmap target <ports> -sV -sC -sCS
Current #2: nmap target <ports> -sV --script default --script-suggest all
Flagmode  : nmap target <ports> -sV --script default,$all

#Want to see less info, but still know what is not included in default
Current:     nmap target <ports> -sV --script-suggest "not default"
Flagmode:    nmap target <ports> -sV --script "$not default"

#Want to see info about potentially disruptive scripts while still doing
default
nmap target <ports> -sV -sC --script-suggest "not safe"
nmap target <ports> -sV --script "default,$not safe"


> From a user syntax PoV, I would prefer keeping them separate. The -sCS
or e.g. --script-suggest <rule> can always
be appended to any scan syntax very easily. I also suspect that a
suggest-flag is even more difficult for a user to
understand and use than the force-flag. I can go either way depending on
what people think.
/Martin



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