Re: Script force - Named probes

[Martin Holst Swende <martin () swende se>]

On 12/04/2011 12:50 PM, Djalal Harouni 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.
I think this is important. Adding a + sign is tremendously powerful and
simple. I don't think
the complexity regarding what is forced and what is not goes away if we
do it the more
difficult way - on the contrary.

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

>  
> > 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!
+1
This is an option for folks who know what they 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 ?
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)?

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

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

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

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/