RE: Nmap Attack Scripting Language (NASL)

["Arun Vishwanathan" <arun.vishwanathan () nevisnetworks com>]

Fyodor,

Please correct me if I am wrong but when you say the following 

"So, for example, KX would be able to add his ASN lookup feature to Nmap
without much trouble.  By following the API, he just returns the
appropriate code and string, and the new information is automatically
printed below each host entry in normal output (and in the XML output
too)."

Aren't you talking of something similar to a plugin based architecture?
Why don't we invest in building the architecture in C itself? I mean
projects like ethereal have done it successfully. Why should we add a
language and take away the programmers freedom? 

Or better still I think it should be a plugin architecture with plugins
possible in various languages. For the ambitious ones, they could do it
in C and for people with less time it could be some simple script like
plugin.


Regards,
Arun

-----Original Message-----
From: nmap-dev-bounces () insecure org
[mailto:nmap-dev-bounces () insecure org] On Behalf Of Fyodor
Sent: Tuesday, May 23, 2006 12:57 PM
To: David Warde-Farley
Cc: nmap-dev () insecure org; prigor () uci edu
Subject: Re: Nmap Attack Scripting Language (NASL)

On Tue, May 23, 2006 at 02:54:45AM -0400, David Warde-Farley wrote:
> However I think you've stumbled upon an interesting point, Paul. Why  
> embed a scripting language in Nmap when you can embed Nmap in  
> (possibly several) scripting languages?

That is an excellent point - there is a lot of value in accessing Nmap
functions through scripting languages.  And in fact, many languages
already do have bindings for Nmap.  For example, with Perl CPAN you
can choose between Nmap::Scanner and Nmap::Parser (there are also more
specialized ones, like NetworkInfo::Discovery::Nmap).  If you are
building a larger application (or even just a simple script) which
uses Nmap, these are great to have.

But I think it would also be nice to have an embedded language.  That
way you can use Nmap::Scanner from Perl CPAN with options such that
Nmap executes an embedded LUA or TCL script, which could then call
Python to access an msrpc library to fingerprint some Windows box.

No, I guess that isn't the reason at all.

A better reason for standardizing on a language embedded within (or,
perhaps I suppose, executed by) Nmap is so there can be a standard
and portable language and API for communicating with Nmap.  So, for
example, KX would be able to add his ASN lookup feature to Nmap
without much trouble.  By following the API, he just returns the
appropriate code and string, and the new information is automatically
printed below each host entry in normal output (and in the XML output
too).  It wouldn't be as fast as a custom C ASN-lookup engine
integrated into Nmap, but it could still be quite fast and do the job
unless/until a hardcoded implementation is added.  And Nmap could ship
with a directory full of simple contributed scripts like that.  So you
could use -sC ASN,WHOIS (or something like that) and Nmap would know
to execute ASN.lua and WHOIS.lua from its script directory.

By calling Nmap from a language like Perl or Python, you can do
whatever you want.  But you also then have to worry about merging the
output and such.  Its not as easy as writing a 10-line TCL script that
you can test and then post to nmap-dev.

But I'm glad the language bindings to Nmap exist too.  Projects like
the new GUI and results viewer, or the hosted CGI scanner could
potentially use that approach.

> What I'm saying is, why not have the SoC'ers, maybe 2 or more of  
> them, implement Python/Ruby/etc. bindings for the underlying  
> libraries, or a C abstraction layer on top of them, with SWIG etc.  
> the way Subversion does it? Then people can choose the scripting  
> language they want to work with from a set of them that have
> bindings.

While we don't have any SoCers doing this for this summer, I'm all for
it in general.  When people add a binding to a new language, please do
post to nmap-dev, and I'd also be happy to add it to the Nmap related
projects page.

Cheers,
-F


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


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