Re: Nmap-LUA release candidate

[Fyodor <fyodor () insecure org>]

On Sun, Jul 30, 2006 at 03:22:33PM +0200, Diman Todorov wrote:
> Hello,
> there is now a quite complete, stable and portable version of Nmap-LUA.
> Nmap-LUA does for nmap what NASL does for nessus.

Great!  The Nmap Scripting Engine is one of the most exciting SoC
projects of the summer.  I hope other Nmap users will try your new
system and send comments.  User feedback will help us decide whether
to integrate this into the main Nmap trunk.

> If you have installed lua on your unix system remember that --with-
> liblua=included is a recomended configure option.

Can you autodetect this like Nmap does with other libraries (libpcre,
libdnet, libpcap, etc.)?

Also, there should be a way to remove the whole scripting
functionality at configure time.  Maybe --without-liblua or something.
That would be similar to the way you can compile w/o OpenSSL or
without NmapFE by specifying --without-openssl and --without-nmapfe.

For your next release, would you try to distribute Windows binaries as
well (.zip and the self-installer)?  nmap/mswin32/Makefile contains
rules for creating these.  You'll probably have to edit some files
(such as in mswin32/nsis/), but we'll need to do this when integrating
the feature into base Nmap anyway.  Many Windows users don't have a
compiler set up, unfortunately.

Can one set the service detection flags from LUA?  I think that would
be quite useful in extending version detection to support more complex
services such as skype (as we've discussed on nmap-dev lately).  We
haven't found a way to detect Skype V2 without adding somewhat ugly
hackes to the version detection format, but it would be pretty easy to
do with LUA.  I think certain scripts (like a vscan category/tag)
should run by default when version detection is requested.

How is script ordering handled?  Can we specify dependencies, so that,
say, a skype exploitation script is always run after the skype
detection script?  That would probably be quite useful.

I notice that you have a solid new man page in docs/nmap-lua.1 .
Users may want to read through this before testing the system to get a
better idea of what is going on.  It definitely helped me.

There are a couple command-line options which I would recommend
shortening.  I think --scripts should be used instead of --script-scan
and --script-trace rather than --script-scan-trace.  This is
consistent with the way we use --version-trace rather than
--version-scan-trace.

Your new man page often refers to the system as "Nmap-LUA".  While
that make sense, maybe we should call it the Nmap Scripting Language
(NSE).  Many people won't know what Nmap-LUA means as they are
unfamiliar with that language.  Plus, NSE is much more than just
simply embedding a LUA interpreter into Nmap.  It has hooks all over
to improve performance, export results, etc.  Leaving the script
extention as .lua seems reasonable, since it is actually LUA code.  I
would also prefer having SCRIPT_ENGINE_LUA_DIR be 'scripts' rather
than the longer 'lua_scripts'.

Speaking of the man page, I get this message up top when I try to read
it with my (Fedora Core 5) version of 'man':

XXX
XXX WARNING: old character encoding and/or character set
XXX

I'm not sure why that is.

The man page says:

> The harmless category contains scripts who's queries will not
> surprise a system administrator. Examples are: echoTest.lua,
> showHTMLTitle.lua. Intrusive scripts perform actions which might
> result in compromising log entries. If the script tries to log onto
> the target using a default password, then it definitely goes into
> the intrusive category."

I like the idea of different classes based on how intrusive they are
likely to be.  But even the "harmless" tests might be logged and could
cause some overly-sensitive sysadmin to complain.  How about defining
the classes as:

The harmless category contains scripts which are unlikely to offend
remote sysadmins.  Most of these perform general network discovery.
Examples are echoTest (quick descript. of what it does) and
showHTMLTitle (grabs the title from a web page).  Intrusive scrips are
not intended to crash or damage anything, but are more likely to leave
suspicious logs or otherwise arouse sysadmin ire.  Scripts which
attempt to login to services with default passwords fall into this
class.

I think we should have a category like 'vulnscan' for scripts which
test for a vulnerability.  It should probably be one of the categories
which is performed by default when -sC is specified.  These would
normally fall under 'intrusive', but I think it is worth having a
separate category for them.

Honestly, I think we may find that having just one category per script
is too limiting.  Perhaps it would be better for the script to
contain a list of 'tags'.  The script name would probably be on that
list, explicitly or implicitly.  Then someone could pass a list of
tags to --scripts.

On a totally different topic, have you (or anyone) tested this on IPv6
or UDP ports?  Did it work well?

These are just my comments based on the docs/tarball.  I have tested
that it compiles on my FC5 system, but haven't tried this new version
yet.  I will send more comments when I do.

And as I mentioned, it would be great if other nmap-dev folks send
their comments as well.

Cheers,
Fydoor


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