Re: [NSE] DRDA protocol

[Patrik Karlsson <patrik () cqure net>]

I'm answering my own e-mail, sorry for the confusion.

On 14 aug 2010, at 10.42, Patrik Karlsson wrote:

> On 11 aug 2010, at 19.14, David Fifield wrote:
>
> > On Fri, Jul 23, 2010 at 12:19:36AM +0200, Patrik Karlsson wrote:
> > > Hi all,
> > >
> > > While looking at Informix 11.50 I realized that the database server has support for DRDA [1].
> > > DRDA is the protocol that I've implemented a small piece of in the db2.lua library which is used by db2-info and my 
> > > db2-brute scripts.
> > > It turns out that both these scripts work great against an Informix servers with a DRDA instance running.
> > >
> > > The db2-info script currently identifies Informix servers as DB2 servers and sets the service field to ibm-db2.
> > > I'm attaching a patch that allows it to detect both Informix and DB2 servers properly and sets the service field to 
> > > drda instead.
> >
> > --- scripts/db2-info.nse        (revision 19142)
> > +++ scripts/db2-info.nse        (arbetskopia)
> > @@ -29,8 +29,8 @@
> > -- parseVersion was ripped from the old db2-info.nse written by Tom Sellers
> > --
> >
> > -portrule = shortport.version_port_or_service({50000,60000},
> > -                                            "ibm-db2", "tcp",
> > +portrule = shortport.version_port_or_service({50000,60000,9090},
> > +                                            {"drda"}, "tcp",
> >                                            {"open", "open|filtered"})
> >
> > Do you recommend also changing the name of ports 523 and 50000 in
> > nmap-services from ibm-db2 to drda? If not, then the portrule should
> > also contain "ibm-db2" so the script can run without version detection.
>
> Well, this is where it get's a little bit confusing:
> - Port 523 is only recognized by the ibm-db2 probe and NOT by the drda probe
> - Port 50000 is recognized by both probes. I guess this means that this port supports both protocols.

Never mind, I looked closer into this and db2 gets identified on port 523 by the ibm-db2-das probe and on port 50000 by 
the ibm-db2 probe.

> Setting the service in the scripts to {"drda","ibm-db2"} does not work if I remember correctly.

This actually works well, I don't know what I missed last time. Sorry for the confusion.
I've commited the portule change together with a small fix for drda-brute and an updated scripts.db as r19748.
So, I guess we don't need to change anything in nmap-services for now.

> I think we would need to ensure that the drda probe is matched before the ibm-db2 to make sure all scripts get 
> executed.
> I guess we could do this by moving it before the ibm-db2 probe and changing it from a softmatch to a match?
> The problem with this approach is that the version script won't run if it's hard matched and the version info won't 
> be retrieved.


> > > In order to reflect the change I propose the following name changes:
> > > db2.lua => drda.lua
> > > db2-info.nse => drda-info.nse
> > > db2-brute.nse => drda-brute.nse
> >
> > This is fine with me. You can commit it. Also add the old names to
> > OLD_SCRIPT_NAMES in Makefile.in.
>
> It's commited in r19747, any suggestions on what to do with the probes?
> Unfortunately for me the scripts won't run for my databases listening on ports that are not in the script range.
>
> > > I noticed that the db2-brute script fails to run against ports that are not specified in the port_or_services 
> > > function.
> > > As far as I can tell the db2-info properly sets all detected fields, but I guess it does this "too late" for the 
> > > db2-brute script to pick it up?
> > > I tried to add the db2-info script as dependency for the db2-brute script without success.
> >
> > I'm not sure why this happens. Maybe the setting of the version only has
> > an effect if the script is run through -sV, and not through ordinary
> > script scanning?
> >
> > David Fifield
>
> //Patrik
> --
> Patrik Karlsson
> http://www.cqure.net
> http://www.twitter.com/nevdull77


//Patrik
--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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