Nmap Development mailing list archives
RE: Nmap Attack Scripting Language (NASL)
From: "Arun Vishwanathan" <arun.vishwanathan () nevisnetworks com>
Date: Tue, 23 May 2006 13:10:33 +0530
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
Current thread:
- Re: Nmap Attack Scripting Language (NASL), (continued)
- Re: Nmap Attack Scripting Language (NASL) doug (May 23)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- RE: Nmap Attack Scripting Language (NASL) Brandon Enright (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- Re: Nmap Attack Scripting Language (NASL) Paul Rigor (May 22)
- Re: Nmap Attack Scripting Language (NASL) David Warde-Farley (May 22)
- Re: Nmap Attack Scripting Language (NASL) Paul Rigor (May 22)
- Re: Nmap Attack Scripting Language (NASL) Fyodor (May 23)
- Re: Nmap Attack Scripting Language (NASL) Paul Rigor (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 23)
- Re: Nmap Attack Scripting Language (NASL) Diman Todorov (May 23)