Re: Script force - Named probes

[Djalal Harouni <tixxdz () opendz org>]

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/