Nmap Development mailing list archives
Re: Script force - Named probes
From: Djalal Harouni <tixxdz () opendz org>
Date: Sun, 4 Dec 2011 22:11:07 +0100
On Sun, Dec 04, 2011 at 09:26:56PM +0100, Martin Holst Swende wrote:
On 12/04/2011 12:50 PM, Djalal Harouni wrote:On Sun, Dec 04, 2011 at 04:00:42AM -0500, Patrick Donnelly wrote:For developers: Yes I must admit that if we let the code in this form and add other features it will be hard to manage. In my opinion this patche is not ready to be committed, we can improve it by using something like 'selection_flags'.I'm not sure I follow. I actually think it just needs some more tuning and maybe some more error messages.
Yes error checking and IMHO a small improvement. I was referring that instead of using: function Script.new (filename, selected_by_name) We could use: function Script.new (filename, selection_flags) Where the 'selection_flags' is a mask so we can use bitwise operations. It should handle: selected_by_name, selected_by_category, selected_by_directory (which is currently not supported) and script_forced. This way it will be easy to add new features.
Further, a script can't know it's being forced (with the current patch) to run.I thought of this too, but do the scripts really need to know that they are beeing forced ?Is that a bad thing? Why should the script second-guess the commander? Anyway, theoretically, wouldn't it be possible if it really wanted to? By saving it's return-value (or checking the portrule again during the action-phase)?
If we support this, a last solution would be to add an environment variable in the Script:new_thread() function (e.g: a boolean value SCRIPT_FORCED).
My position would be that this is better solved by the user with --script-args and scripts having some abstraction to make forcing execution simple. In your original use-case, you describe the problem of having scripts run against services on non-standard ports: "The primary usecase people seem to have is that they e.g. do a configuration review of a lot of ms-sql servers, say you have a list of 20 servers where the database is located on an uncomon port. They don't want to have to do -sV --version-all just to run a script, since they already know what's on the port. I myself was recently stung by this when testing the new hadoop-* scripts [1]. If I were to write a solution using the current system, I would probably change the shortport "port_or_service" function to allow the user to say "this port is running this service". A user might say --script-args "services.ms-sql-s = {23,24}" where 23 and 24 are the non-standard ports. Scripts which then do: portrule = shortport.port_or_service({standard_ports}, {"ms-sql-s"}, "tcp", "open"); would still run. The shortport function would take into account the --script-arg and understand that the ms-sql-s service is running on the port(s) 23 and 24 even though version checking wasn't done.I think this is connected to Patrik suggestion about named probes [1] or a replacement for it where --script-args "services.*" will set the service manually. (1) Patrik's named probe example: ./nmap -sV -p 1433-1500,1521-1600 1.2.3.4 --probes ms-sql-s,oracle-tns --script oracle-brute,ms-sql-brute (2) Patrick's --script-args example:--script-args "services.ms-sql-s = {1433,1434}"Yes, this would also solve the problem. These three have been discussed as solutions : 1) Named probes. Heavily wished, not implemented. 2) Postulated services: User tells nmap that port 23 is ms-sql-s. 3) Forced scripts I'd happily go with 1), but noone has created the patch for that. As for 2), well, I could live with that also. There's some complexity down that path aswell though; for example, the user would have to look up the portrule for the script he wanted to run in order to figure out what service name to use.
Thanks for this input. Hopefully these solutions can be implemented together and cohabit, especially for 1) and 3).
As a specific example for my problem with the hadoop scripts [2]. I would see running the following command instead: nmap --script hadoop-* --script-arg 'service.hadoop-region=8000,service.hadoop-tasktracker=8000,service.hadoop-namenode=8001,service.hadoop-datanode=8002,service.hadoop-jobtracker=8003' namenode.hadoop.example.edu disc1.hadoop.example.edu ... What's nice about this design is that if the port is closed, the shortport won't blindly run the script anyway against the port. The script-arg would essentially be manually setting the service for each port. The shortport function would ignore the version for the port and instead use the service -> port mapping given in the script-arg. On the other hand, if the user doesn't know which ports the services are running on, the user would be out of luck. But isn't that why we have version scanning?Yes, there is also *targeted* version scanning Patrik's proposition, and services will be set *automatically*. I'll try to get back to this thread, thanks Patrick.Yes, I can see som benefit to that approach, since you could more easily cover several different ports in the case that a service, such as hadoop, is spread out across several services/ports. Named probes could also achieve that though if it took a list of probe names as input. /Martin
Yes perfectly. -- tixxdz http://opendz.org _______________________________________________ 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: Script force, (continued)
- Re: Script force Djalal Harouni (Nov 19)
- Re: Script force Martin Holst Swende (Nov 19)
- Re: Script force David Fifield (Nov 29)
- Re: Script force Martin Holst Swende (Nov 30)
- Re: Script force Fyodor (Nov 30)
- Re: Script force Djalal Harouni (Dec 01)
- Re: Script force Martin Holst Swende (Dec 03)
- Re: Script force Patrick Donnelly (Dec 04)
- Re: Script force - Named probes Djalal Harouni (Dec 04)
- Re: Script force - Named probes Martin Holst Swende (Dec 04)
- Re: Script force - Named probes Djalal Harouni (Dec 04)
- Re: Script force - Named probes Patrick Donnelly (Dec 15)
- Re: Script force - Named probes Martin Holst Swende (Dec 16)
- Re: Script force - Named probes Djalal Harouni (Dec 18)
- Re: Script force Martin Holst Swende (Dec 07)
- Re: Script force Patrick Donnelly (Dec 07)
- Re: Script force Martin Holst Swende (Dec 07)
- Re: Script force Martin Holst Swende (Dec 07)
- Re: Script force Martin Holst Swende (Dec 11)
- Re: Script force Djalal Harouni (Dec 11)
- Re: Script force Martin Holst Swende (Dec 13)