Nmap Development: Re: Nmap-NSE Release candidate 2

[doug () hcsw org]

Hi Diman!

Thanks for your quick reply!

On Wed, Aug 09, 2006 at 05:54:13PM +0200 or thereabouts, Diman Todorov wrote:
> > A conceivable plan could be
> >
> > nmap -sC --script=whatever.lua --script-
> > params='user="desmond",passwd="molly"' target
> I am not sure I like this idea very much. The main use of NSE (at
> least I assumed this to be the main use while designing) will be
> running thousands of scripts against a target. I really can't imagine
> how this --script-params can be used to pass parameters to the
> scripts in a way that isn't a pita. You'd either need to tell the
> option which script it is meant for or you would need to cope with
> the fact that different scripts might interpret the same argument
> differently. But more on user interaction later.
That's a good point. I think that while, yes, there are a huge amount
of scripts that can be useful without customisation there is no point
limiting ourselves! NSE seems to be very powerful already and I think
we should try to make it as flexible as possible.

I don't think scripts distinguishing between parameters would have to
be that difficult at all. In fact, I think your registry implementation
is already very close!

What about allowing the user to set *very descriptive* values in the
registry from the command line? Maybe

nmap -sC --script-params='ftpexploit_user="desmond",ftpexploit_passwd="molly"' target

so the script could reference them like so:

login_to_ftpd(registry.ftpexploit_user, registry.ftpexploit_passwd)

Or if we're worried about conflicts,

login_to_ftpd(registry.params.ftpexploit_user, registry.params.ftpexploit_passwd)

As discussed in http://www.lua.org/pil/3.3.html , the script writer
could put something like the following in the lua script:

-------------------- Default values ----------------------

registry.ftpexploit_user = registry.ftpexploit_user
                           or "anonymous"
registry.ftpexploit_passwd = registry.ftpexploit_passwd
                           or "pwned () by NSE"

----------------------------------------------------------

Providing, of course, that the --script-params params option is processed
before the scripts are loaded.

(As an aside, in lisp this would be a perfect use for a macro defining a
syntax like so:

(default ftpexploit-user "anonymous")
(default ftpexploit-passwd "pwned () by NSE"))



As "Mike C" mentioned in a previous post, it would also be useful to be
able to store "sessions" so that it's easy to repeat script scans using the
same parameters. Maybe something like:

nmap -sC --script-session=mysession.lua target

with mysession.lua simply being a lua script loaded by NSE before any of
the real NSE scripts. It could look something like this:

-- Jimmy's session file
-- August '06

-- he wuz runnign auth on a phunny p0rt
registry.showOwner_authport = 9876

-- lol i got desmond g00d!!11
registry.ftpexploit_user = "desmond"
registry.ftpexploit_passwd = "molly"



> As far as your abstraction ideas are concerned, I totally agree.
> Building some kind of NSE standard library is planned.
> > portrule = "http/tcp"
> To be honest I would rather handle this in some sort of standard
> library.
>
> protorule = function(service, protocol)
>   return function(host, port)
>         if port.service == service
>            and port.protocol == protocol
>         then
>                 return true
>         else
>                 return false
>         end
>     end
> end
>
> and then
>
> portrule = protorule("http", "tcp")
That's a great idea and a good example of the power of lexical closures!

When you build the standard library it might be worth investing some time
into thinking about some other common portrule functions that people might
want to use. Things like:

common_nfs_portrule = function(host, port)
  return port.service == "nfs"
         and port.protocol == "tcp"
         and is_rpc_running_and_accesible(host)
end

so any NFS tests can just use

portrule = common_nfs_portrule




> Is that something which should be put in NmapFE or should we extend
> Adriano's UMIT?
As far as I'm concerned any new GUI development should probably be
focused away from NmapFE. I don't think very many people use NmapFE
and I, for one, always configure --without-nmapfe.


Best,

Doug


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