Nmap Development: Re: Nmap-NSE Release candidate 2

[Diman Todorov <diman.todorov () chello at>]

Hello Doug,

> Do we make the user edit the lua source file? Do we add some means  
> to pass
> parameters through Nmap into the lua script? Or do we simply  
> consider these
> cases beyond the scope of NSE?
>
> 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.

> Accounting for just the service name should also add another layer  
> of stability
> and assurance to somebody running or writing lua scripts: version  
> detection has
> verified that, at least superficially, this port seems to speak the  
> service we're
> hoping it to speak.
This sounds quite reasonable to me. I would still provide the  
port.number because
theoretically you can do network I/O in the rule section.

> portrule = "http/tcp"
>
> instead of the longer
>
> portrule = function(host, port)
>   if port.service == "http"
>      and port.protocol == "tcp"
>   then
> end
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")

If you're getting my drift ;)

> Until I looked at the lua source code, it wasn't clear to me that  
> port 113
> needed to be scanned and determined to be an auth service before the
> showOwner.lua script would run. Perhaps some sort of documentation  
> or warning
> is appropriate? Also, in a similar vein to above, what if we (god  
> knows why)
> find an auth service on a port other than 113? Couldn't somehow the  
> showOwner.lua
> script try the scan with any auth services discovered? And could we  
> make this
> general so that this sort of behaviour is automatic (by having some  
> sort
> of connect() wrapper that accepts service names instead of ports,  
> for example)?
I agree that the dependency on port 113 is not a very good thing. I  
would
nevertheless refrain from a connect() wrapper which accepts service  
names as
this introduces a number of ambiguities which need to be dealt with.  
What
if there are 25 ports with open auth on the target? While this is  
just an
example for the sake of discussion, I believe that sometimes it is  
better
to go a conservative way for the sake of simplicity.

The problem above can be easily solved using the new nmap.registry:

portrule = function(host, port)
   if port.service == "auth" then
      nmap.registry.authnumber = port.number
      return true
   else
      return false
   end
end

action = function(host, port)
    connect(host.ip, nmap.registry.authnumber)
end

While this doesn't resolve ambiguities, it is very helpful imho. Perhaps
the standard library can have routines to easily store and retrieve  
several
port numbers...

> I know lua provides a fairly complete regular expression library  
> but I still
> wonder if it would be worthwhile creating some sort of lua binding for
> PPCRE. Nmap requires libppcre for version detection so we can  
> always count on
> it being linked. (Interestingly, Nmap will soon have 3 distinct,  
> incompatible
> regular expression libraries available - POSIX, PPCRE, and lua's)
Either adding a ppcre wrapper or even replacing the lua expressions  
in NSE entirely
with ppcre is already on my TODO list. Currently it has very low  
priority though.

> This is handy because a whole heap of protocols use the concept of  
> "lines" to
> divide data and functions like this one make it really easy to read  
> and process
> data line-by-line.
That's not my idea, this is a function provided by nsock, I've simply  
provided a wrapper ;)
In fact I am contemplating switching to marek's buffered i/o nsock  
wrapper but this
too will have to wait for now.

As far as your abstraction ideas are concerned, I totally agree.  
Building some kind
of NSE standard library is planned. I hadn't thought of adding  
shortcuts for idioms
but it definitely sounds like a good idea to me. I had in mind adding  
routines which
would reduce the pain of having to use low level sockets and thus  
buggily reinventing
the wheel in every NSE script.


> I can't seem to find any use of the 'description values in the C  
> source or
> any of the lua scripts. Does the description serve any purpose  
> other than
> being a comment in the source code?
It's because they currently only serve the purpose of a comment. I think
that in the long term NSE will definitely need some form of GUI. One  
of the
purposes for a GUI would be to give users a sane way to browse scripts -
I have rewritten the script storage system so that scripts can be in  
multiple
categories unfortunately at the cost of losing the structured  
filesystem layout.
It would also be nice to have a graphical debugger for NSE scripts.  
The GUI could
also handle the issue with parameters for scripts.

Is that something which should be put in NmapFE or should we extend
Adriano's UMIT?

> Out of curiosity, I'm wondering why you chose NSE for some of your  
> scripts
> instead of version detection. For example, malware/ 
> kibuvDetection.lua seems
> to accomplish the same thing that adding a match line or 2 to the  
> probes file
> would.
I do apologize. Some of the scripts currently distributed are  
definitely not
going in the final release. They were written just for testing  
purposes -
you know - the 'yay it works' feeling ;)
The kibuv script in particular is one of the NASL scripts I have
ported to NSE to compare both languages.

> Anyways, these are just some random ideas. Take them for what  
> they're worth.
greatly appreciated

cheers
Diman


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