Re: [NSE] Script Dependencies Replacement for Runlevels

[David Fifield <david () bamsoftware com>]

On Tue, Nov 10, 2009 at 09:25:16AM -0600, Ron wrote:
> David Fifield wrote:
> > My question is, do we need support for strong dependencies? I'm assuming
> > I'm correct in thinking that strong dependencies are a new future, and
> > that weak dependencies are equivalent to runlevels. If there is a use
> > case for strong dependencies I'm not against them, but I would like to
> > avoid having a --script-autoadd option.
>
> Once http-spider.nse exists, I'd like to write some scripts that depend
> on it. They wouldn't just be helped by http-spider.nse, but they'd
> *require* its output to run.

That's a pretty good example. How do you see your script being invoked.
I can think of a few options. Below when I say "list all scripts" I mean
you can name the scripts individually or by category with --script, or
have them selected automatically by being in the default category.

1. You have to list all scripts, including dependencies, or Nmap will
   stop with an error.
2. If a dependency for a script is not listed, that script just won't
   run even if you asked for it.
3. Nmap won't run if not all dependencies are listed, but there is an
   option to automatically include any required dependencies.
4. Same as #2, with an option to automatically add dependencies.
5. Required dependencies are always added automatically; you may have
   scripts run that you didn't ask for specifically.

> > I can think of one thing that runlevels offer that explicit dependencies
> > don't. Say you have a brute force script, and you want it to run after
> > every script that can potentially find a login for you. For example,
> > telnet-brute might want to run after http-userdir-enum because the
> > latter can identify usernames. We could do this with runlevels by giving
> > a the login-finding scripts a low runlevel, but with explicit
> > dependencies every brute force script will need to know about every
> > login script. I suspect this is not easy to solve from a user interface
> > point of view. One idea I had was something like
> >
> > weak_dependencies = {"*login"}
> >
> > "*login" would stand for a class of scripts that would somehow signify
> > that they satisfy it. The runlevel assigned to the brute script would
> > have to be at least one more than the highest runlevel of any *login
> > script.
>
> Not sure if this really affect what you're saying, but you made me think
> of it. There are sort of three types of auth* scripts:
> 1. Finding users
> 2. Finding passwords (based on users)
> 3. Using users/passwords to get more information
>
> With the smb-* scripts, I sort of do 1 and 2 backwards -- you can't
> necessarily get good user output in step (1), so I enumerate users in
> step (3), but I abstracted the functions out and sort of combine it into
> step (2). But that's besides the point -- for http-*, telnet-*, etc,
> finding users before finding passwords which is before finding deeper
> info is useful.
>
> Also, usernames and such should carry across scripts (like snmp-*
> scripts could use the telnet-* and ftp-* bruteforced accounts, perhaps?)

Yeah--we should have some standard place in the registry where we can
store such things.

I think solving the *login problem could use some more discussion, but I
don't want it to stand in the way of this patch being integrated.
Patrick's implementation of dependencies is better than runlevel, and
this limitation is academic because it wouldn't break anything we're
doing now. I think it's worth thinking about, though.

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