Nmap Development mailing list archives
Re: Nmap-LUA release candidate
From: Fyodor <fyodor () insecure org>
Date: Sun, 30 Jul 2006 19:40:16 -0700
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
Current thread:
- Nmap-LUA release candidate Diman Todorov (Jul 30)
- Re: Nmap-LUA release candidate kx (Jul 30)
- Re: Nmap-LUA release candidate Fyodor (Jul 30)
- Re: Nmap-LUA release candidate kx (Jul 30)
- Re: Nmap-LUA release candidate Fyodor (Jul 30)
- Re: Nmap-LUA release candidate Fyodor (Jul 30)
- Re: Nmap-LUA release candidate Fyodor (Jul 31)
- Re: Nmap-LUA release candidate kx (Jul 30)