Nmap Development mailing list archives
Re: Output|Input pipe and forcing script run
From: Patrik Karlsson <patrik () cqure net>
Date: Sat, 30 Apr 2011 12:21:54 +0200
On Apr 30, 2011, at 9:53 AM, David Fifield wrote:
On Mon, Nov 29, 2010 at 12:02:04AM +0100, Martin Holst Swende wrote:Hi, On 10/03/2010 04:48 PM, David Fifield wrote:On Wed, Sep 29, 2010 at 10:47:37AM +0200, Martin Holst Swende wrote:Also, a while ago there was a discussion about forcing a script to be run . That is a feature I would really love. Is anybody working on that? Fyodor suggested placing the patch in NSE, if that means in "lua-space" I could implement that if given some hints on where to place it.First you should try implementing this in the shortport library. Add a check to each of the functions for the script argument "force": local force = stdnse.get_script_args("force") Then try running some scripts with this to see how it works. I think there will be unexpected surprises when forcing scripts to run with the large number of ports Nmap scans by default. The next step is to make it apply to all scripts in nse_main.lua. Try editing the "main" function in Script:new_thread. That's where the rules are actually called and can be overridden. Keep us updated with patches and your progress. I am interested to see how this works.A lot of other things have got in the way, but tonight I did a first stab at it. It was trivial to implement, and you can check it out at the usual place; at http://martin.swende.se/hgwebdir.cgi/nsescripts/rev/48ee0f905d68 (<-- NOT tip) you can see the diff from the original. With my patch you can do e.g. nmap www.google.com -p80 --script firewalk --script-args=force=1 -d3I want to reopen discussion about forcing a script to run. I tried this patch and it works as I expect. The problem I see is that there are easy ways to accidentally and confusingly use it. nmap --script-args force -d2 localhost -sC -F This is going to run every default script against every open port: NSE: Starting runlevel 1 (of 1) scan. NSE: Starting 'ms-sql-info' (thread: 0x91cb7d0) against 127.0.0.1. NSE: Starting 'nbstat' (thread: 0x90dc580) against 127.0.0.1. NSE: Starting 'p2p-conficker' (thread: 0x909b348) against 127.0.0.1. NSE: Starting 'smb-os-discovery' (thread: 0x90c17f8) against 127.0.0.1. NSE: Starting 'smbv2-enabled' (thread: 0x916aee8) against 127.0.0.1. NSE: Starting 'auth-owners' (thread: 0x91ecad8) against 127.0.0.1:6000. NSE: Starting 'backorifice-info' (thread: 0x90bf0e8) against 127.0.0.1:6000. NSE: Starting 'dhcp-discover' (thread: 0x91ea950) against 127.0.0.1:6000. NSE: Starting 'dns-recursion' (thread: 0x8fd3d40) against 127.0.0.1:6000. NSE: Starting 'dns-service-discovery' (thread: 0x916c240) against 127.0.0.1:6000. NSE: Starting 'dns-zone-transfer' (thread: 0x8fba2a8) against 127.0.0.1:6000. NSE: Starting 'epmd-info' (thread: 0x8fd6288) against 127.0.0.1:6000. NSE: Starting 'finger' (thread: 0x8fb8648) against 127.0.0.1:6000. NSE: Starting 'ftp-anon' (thread: 0x9123040) against 127.0.0.1:6000. NSE: Starting 'ftp-bounce' (thread: 0x91d8110) against 127.0.0.1:6000. NSE: Starting 'gopher-ls' (thread: 0x8fcd4a8) against 127.0.0.1:6000. NSE: Starting 'hddtemp-info' (thread: 0x920e1d0) against 127.0.0.1:6000. NSE: Starting 'http-auth' (thread: 0x8fb83c0) against 127.0.0.1:6000. NSE: Starting 'http-favicon' (thread: 0x90bfa88) against 127.0.0.1:6000. NSE: Starting 'http-methods' (thread: 0x9123988) against 127.0.0.1:6000. NSE: Starting 'http-open-proxy' (thread: 0x90c1390) against 127.0.0.1:6000. NSE: Starting 'http-robots.txt' (thread: 0x9213b18) against 127.0.0.1:6000. NSE: Starting 'http-title' (thread: 0x90ef6f8) against 127.0.0.1:6000. NSE: Starting 'http-vmware-path-vuln' (thread: 0x91f0ca8) against 127.0.0.1:6000. NSE: Starting 'imap-capabilities' (thread: 0x91ce880) against 127.0.0.1:6000. NSE: Starting 'irc-info' (thread: 0x91d02c8) against 127.0.0.1:6000. NSE: Starting 'mongodb-databases' (thread: 0x91c5f68) against 127.0.0.1:6000. NSE: Starting 'mongodb-info' (thread: 0x91c1ea8) against 127.0.0.1:6000. NSE: Starting 'mysql-info' (thread: 0x91bb298) against 127.0.0.1:6000. NSE: Starting 'nat-pmp-info' (thread: 0x91b9a08) against 127.0.0.1:6000. NSE: Starting 'netbus-info' (thread: 0x913ebc8) against 127.0.0.1:6000. NSE: Starting 'ntp-info' (thread: 0x90fcd10) against 127.0.0.1:6000. NSE: Starting 'pop3-capabilities' (thread: 0x90db0c8) against 127.0.0.1:6000. NSE: Starting 'quake3-master-getservers' (thread: 0x90c6700) against 127.0.0.1:6000. NSE: Starting 'realvnc-auth-bypass' (thread: 0x9047570) against 127.0.0.1:6000. NSE: Starting 'rmi-dumpregistry' (thread: 0x9033318) against 127.0.0.1:6000. NSE: Starting 'rpcinfo' (thread: 0x91f2940) against 127.0.0.1:6000. NSE: Starting 'servicetags' (thread: 0x91ca4c8) against 127.0.0.1:6000. NSE: Starting 'smtp-commands' (thread: 0x9168e20) against 127.0.0.1:6000. NSE: Starting 'snmp-interfaces' (thread: 0x9158670) against 127.0.0.1:6000. NSE: Starting 'snmp-netstat' (thread: 0x9157710) against 127.0.0.1:6000. NSE: Starting 'snmp-processes' (thread: 0x91e7d60) against 127.0.0.1:6000. NSE: Starting 'snmp-sysdescr' (thread: 0x923f990) against 127.0.0.1:6000. NSE: Starting 'snmp-win32-services' (thread: 0x91c2b40) against 127.0.0.1:6000. NSE: Starting 'snmp-win32-shares' (thread: 0x91bf2d8) against 127.0.0.1:6000. NSE: Starting 'snmp-win32-software' (thread: 0x909ba20) against 127.0.0.1:6000. NSE: Starting 'snmp-win32-users' (thread: 0x917e6f8) against 127.0.0.1:6000. NSE: Starting 'socks-open-proxy' (thread: 0x9177f38) against 127.0.0.1:6000. NSE: Starting 'ssh-hostkey' (thread: 0x9156f90) against 127.0.0.1:6000. NSE: Starting 'sshv1' (thread: 0x9144378) against 127.0.0.1:6000. NSE: Starting 'sslv2' (thread: 0x9237d40) against 127.0.0.1:6000. NSE: Starting 'upnp-info' (thread: 0x913a048) against 127.0.0.1:6000. NSE: Starting 'wdb-version' (thread: 0x91034b8) against 127.0.0.1:6000. NSE: Starting 'wsdd-discover' (thread: 0x90cb6d0) against 127.0.0.1:6000. NSE: Starting 'x11-access' (thread: 0x90d4e38) against 127.0.0.1:6000. I think that a global "force" option only makes sense if 1) you are narrowly targeting a list of ports and 2) you are narrowly limiting the set of scripts. Can we think of a way to make this work naturally without strange cases like the above? My first thought is that you usually only want one or a few scripts to be forced. So what if we invent a new syntax that allows applying the force script to one script only? I don't think this is a good syntax, but it will illustrate what I mean: nmap www.google.com -p80 --script force:firewalk This is no more typing in the (expected) case when only one script is used. It would be possible to run one script forced and one non-forced, though I don't have a realistic use case for that. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
I've discussed this a number of times with Martin. As far as I remember Martin had the problem with RMI popping up on different ports and I had the same problem with MsSQL instances. The use case (or problem) here is that you don't wan't to spend a humongous amount of time with the highest service detection intensity to discover a service you already know is running on a specific port. What you wan't to do instead is basically tell Nmap that you know that port 1234 is MsSQL or RMI and that it should treat it that way a match all portrules as if it had been detected that way. At some point I came up with the "named probe" approach, which would allow you to select a specific probe (or multiple ones) and simply run them against the ports you were scanning. We both agreed that this would solve the problem in a more elegant way. I've sent a number of e-mails requesting feedback about this in the past but haven't received any response (except from Martin). This could be either because I haven't been clear enough with the intensions or maybe the idea simply sucks. Anyway, in my personal opinion, I would rather have something like that than the force argument. The problem with this approach is that it wouldn't cover your example with firewalk, which is triggered by a hostrule. //Patrik -- Patrik Karlsson http://www.cqure.net http://www.twitter.com/nevdull77 _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Output|Input pipe and forcing script run David Fifield (Apr 30)
- Re: Output|Input pipe and forcing script run Patrik Karlsson (Apr 30)
- Re: Output|Input pipe and forcing script run Ron (Jun 15)
- Re: Output|Input pipe and forcing script run Hani Benhabiles (Jun 15)
- Re: Output|Input pipe and forcing script run Martin Holst Swende (Jun 16)
- Re: Output|Input pipe and forcing script run Patrik Karlsson (Jun 16)
- Re: Output|Input pipe and forcing script run Gorjan Petrovski (Jun 17)