Re: Script force - Named probes

[Djalal Harouni <tixxdz () opendz org>]

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.

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'.

 
> 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!

But yes from another point of view ignoring the returned results is not
really optimal.

> 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 ?


> 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}"


> 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.

> This solution I propose is indeed more complicated and gives more work
> to the user. There is a good side and bad side to that argument.
> Something to think about...

[1] http://seclists.org/nmap-dev/2011/q1/605

-- 
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/