Nmap Development mailing list archives
Re: Script force - Named probes
From: Martin Holst Swende <martin () swende se>
Date: Fri, 16 Dec 2011 21:21:00 +0100
On 12/16/2011 05:34 AM, Patrick Donnelly wrote:
Hi Djalal, On Sun, Dec 4, 2011 at 6:50 AM, Djalal Harouni <tixxdz () opendz org> wrote:On Sun, Dec 04, 2011 at 04:00:42AM -0500, Patrick Donnelly wrote:I've followed the development of this patch and find it very interesting. I have some concerns: o --script is used for choosing which scripts may run. I'm concerned that the purpose will become convoluted because not only is the user now choosing which scripts are allowed to run, the user is also choosing which scripts *will* run. I feel like changing the meaning of --script will only explode with the addition of other useful features into something terribly difficult to manage and, most importantly, difficult to explain to users.For users: The advantage of using '--script' is that users do not have to specify the script name in '--script' and '--script-args', but yes '--script' can explode with the addition of new features.This type of "time savings" for the user just doesn't seem that significant to me. Specifically, not requiring the user to enumerate each script via script-args or similar. Someone preparing an Nmap command should do so with careful consideration. In the past I have dealt with network administrators who were annoyed I had scanned them with some "dangerous" scripts when using the "all" category by accident. It has caused me to be much more cautious when designing Nmap commands and I like think other experienced users are likewise cautious. While typing options like "--script 'not broadcast and safe and not exploit'", etc., takes a while, it *does* make you think about it. [Of course, I imagine it's easy to forget a category to throw out. Maybe that's a good thing as it forces the user to consult the manual.] Nmap is not a command you blindly execute without forethought like "ls" or similar.
I don't really understand the concerns. It sounds a bit like there would be some kind of benefit from making the syntax difficult instead of simple.
o I'm worried about problems arising from the portrule being "skipped" and the action function missing data set in the portrule. For example, dns-zone-transfer.nse sets a few values in the portrule which would not exist if the script were forced to run against an abnormal port.The rules should not be skipped (and they are not), we just ignore the returned results if the force flag is set. I assume when you force a script to run you know what you are doing!Skipped was the wrong word. I meant that NSE ignores the return value.But yes from another point of view ignoring the returned results is not really optimal."Not optimal" is not how I'd describe it. We are deliberately breaking our own design. Scripts logically assume some code is run inside the portrule/hostrule when this is not the case. Forcing scripts to have logic accounting for external forces complicates their design considerably. This patch may seem innocuous by itself but it opens the floodgates for similar extensions.
As I see it, the scripts should *not* account for the force-option. They should just keep doing what they already do : assume that the target is what they normally run against. This is an advanced user option to override the way things work normally. We just give the user the power to choose (instead of, like earlier, having to manually modify the portrule as I and several of my colleagues have had to do on occasion). If someone goes and runs smb-enum against a database, that's totally up to the user. (Also, it can be an interesting excercise to run all scripts in order to test the stability of a service - a poor mans fuzzing :) ) /Martin
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}"Patrik's solution (1) looks good too. Thanks for making me aware of it.
_______________________________________________ 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 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)
- Re: Script force Patrik Karlsson (Dec 16)
- Re: Script force Fyodor (Dec 19)