Nmap Development mailing list archives
RE: Nmap-NSE Release candidate 2
From: "Mike C (sec)" <check () imjc com>
Date: Thu, 10 Aug 2006 13:32:42 +0100
I think the ability to pass username and password to scripts is going to be very important - not only for ftp - but especially for SMB/CIFS. How about something similar to nessus whereby you save "sessions" - so there would be a file you could specify as an argument to NSE/Nmap which contained a list of hosts to scan, which scripts to use and any additional information such as passwords and usernames for individual scripts as required. Just a thought... Regards, Mike -----Original Message----- From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org] On Behalf Of Diman Todorov Sent: 09 August 2006 16:54 Cc: nmap-dev () insecure org Subject: Re: Nmap-NSE Release candidate 2 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 _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev
Current thread:
- Nmap-NSE Release candidate 2 Diman Todorov (Aug 07)
- Re: Nmap-NSE Release candidate 2 Fyodor (Aug 07)
- IPv6 Testing of Nmap-NSE? Fyodor (Aug 08)
- Re: Nmap-NSE Release candidate 2 doug (Aug 09)
- Re: Nmap-NSE Release candidate 2 Diman Todorov (Aug 09)
- Re: Nmap-NSE Release candidate 2 doug (Aug 12)
- Re: Nmap-NSE Release candidate 2 Fyodor (Aug 13)
- Re: Nmap-NSE Release candidate 2 Diman Todorov (Aug 09)
- <Possible follow-ups>
- RE: Nmap-NSE Release candidate 2 Mike C (sec) (Aug 10)