Discussion:
[SCRIPT] DB2 Information gathering script
Tom Sellers
2009-11-09 03:28:55 UTC
Permalink
I have written a NSE script that enhances version detection for DB2. It also
gathers platform (OS) and database instance information. It functions in a similar
way to the MS SQL script.

The script sends a DB2 EXCSAT (exchange server attributes) command packet and
parses the response. This is a legitimate DB2 command and, based on my reviews
of logs, causes no problems on the server. DB2 does log the connection and the
source IP address though.


PORT STATE SERVICE VERSION
523/tcp open ibm-db2 IBM DB2 Database Server 9.07.0
50000/tcp open ibm-db2 IBM DB2 Database Server 9.07.0 (QDB2/LINUX)
| db2-info: DB2 Version: 9.07.0
| Server Platform: QDB2/LINUX
| Instance Name: db2inst1
|_ External Name: db2inst1db2agent000051B3%FED%Y00

In the sample output above the version of the DB2 DAS service on port 523 was
detected using nmap-service-probes. Historically, unlike the DAS port on 523,
we have been unable to detect the exact version number on the DB2 database
instances themselves. There may be multiple DB2 database instances and they
typically cluster around port 50000 and 60000.

Port 50000 would normally be detected as service "ibm-db2" with a version string
"IBM DB2 Database Server". The attached NSE script can now detect the exact
version number and platform as well as the instance name for each of the
databases.

Any testing or feedback with the functionality and structure of the script would
be greatly appreciated!


Here are my current concerns with the script:
1. Is the default output too verbose? Should I limit the output to the info
on the port line by default and add the other lines with -v?

2. The data from the server is encoded in EBCDIC. I am decoding this will what
amounts to a lookup table. Is there a more appropriate/efficient way to
handle this?

3. I have built the EBCDIC table containing the ASCII chars that we should
encounter in this context. Should I go ahead and build out the full ASCII
table? (And wow, I am glad we don't use EBCDIC for much.)

Thanks much,

Tom
Matt Selsky
2009-11-09 14:51:39 UTC
Permalink
Post by Tom Sellers
I have written a NSE script that enhances version detection for DB2. It also
gathers platform (OS) and database instance information. It
functions in a similar
way to the MS SQL script.
Here's the output for my DB2 server on Solaris:

$ nmap -sV -p50000 spinach

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-09 09:44 EST
Interesting ports on spinach (192.168.1.233):
PORT STATE SERVICE VERSION
50000/tcp open ibm-db2 IBM DB2 Database Server 7.02.4
Service Info: OS: SUN

Service detection performed. Please report any incorrect results at http://nmap.org/submit/
.
Nmap done: 1 IP address (1 host up) scanned in 11.30 seconds
$ NMAPDIR=. nmap -sV -p50000 --script=db2-info spinach

Starting Nmap 5.05BETA1 ( http://nmap.org ) at 2009-11-09 09:47 EST
NSE: Script Scanning completed.
Interesting ports on spinach (192.168.1.233):
PORT STATE SERVICE VERSION
50000/tcp open ibm-db2 IBM DB2 Database Server DB2 UDB 7.2 (QDB2/SUN)
| db2-info: DB2 Version: DB2 UDB 7.2
| Server Platform: QDB2/SUN
| Instance Name: db2inst1
|_ External Name: db2inst1db2agent000052FF
Service Info: OS: SUN

Service detection performed. Please report any incorrect results at http://nmap.org/submit/
.
Nmap done: 1 IP address (1 host up) scanned in 11.68 seconds


Why does the version with script scanning have a less precise version
number? (7.02.4 vs 7.2)
--
Matt
Tom Sellers
2009-11-10 00:23:06 UTC
Permalink
Post by Matt Selsky
Why does the version with script scanning have a less precise version
number? (7.02.4 vs 7.2)
Thanks for testing the script! Based on my testing it looks like the service,
at least with the 7.x family, is actually returning less precise information.

With other families I see EBCDIC encoded "SQL090204" which I convert to 9.02.04.
With 7 it returns EBCDIC encoded "DB2 UDB 7.2". I will add code to the script to
see if the normal probe has returned a version number, and if so, determine if
it is more precise than what the script has returned.

Thanks again!

Tom
Tom Sellers
2009-11-11 05:10:41 UTC
Permalink
Post by Matt Selsky
Post by Tom Sellers
I have written a NSE script that enhances version detection for DB2.
It also
gathers platform (OS) and database instance information. It functions in a similar
way to the MS SQL script.
$ nmap -sV -p50000 spinach
<SNIP>
Post by Matt Selsky
Why does the version with script scanning have a less precise version
number? (7.02.4 vs 7.2)
Thanks everyone for the feedback!

I have attached an updated version of the db2-info.nse script that should
keep the probed version string if it is more precise. Either way the additional
data is generated when the verbosity is high enough.

Also, the categories have been updated to be more appropriate:

categories = {"safe", "discovery", "version"}

If no one objects, I will also tweak the nmap-service-probes entry for ibm-db2 from
ports 523,50000 to
ports 523,50000-50025,60000-60025

This should improve the likelihood that DB2 is detected without having to use
--version-all. There aren't any other probes in that range and, I think, mainstream
products using this range are limited so there should be almost no performance impact.


Tom
David Fifield
2009-11-11 15:15:28 UTC
Permalink
Post by Tom Sellers
Thanks everyone for the feedback!
I have attached an updated version of the db2-info.nse script that
should keep the probed version string if it is more precise. Either
way the additional data is generated when the verbosity is high
enough.
categories = {"safe", "discovery", "version"}
The only thing I can see to change is the ebcdic2ascii table. It should
be able to handle any byte value, or unless I'm mistaken, the script can
Post by Tom Sellers
data_string = data_string .. ebcdic2ascii[string.format("%x",string.byte(response,i))]
You can do it by setting a default value on the table as is described
here: http://www.lua.org/pil/13.4.3.html. So in this case it might be

setmetatable(ebcdic2ascii, { __index = function() return "." end })

David Fifield
Tom Sellers
2009-11-11 17:19:17 UTC
Permalink
Post by David Fifield
The only thing I can see to change is the ebcdic2ascii table. It should
be able to handle any byte value, or unless I'm mistaken, the script can
Post by Tom Sellers
data_string = data_string .. ebcdic2ascii[string.format("%x",string.byte(response,i))]
You can do it by setting a default value on the table as is described
here: http://www.lua.org/pil/13.4.3.html. So in this case it might be
setmetatable(ebcdic2ascii, { __index = function() return "." end })
Thanks David, changed. I feel much better about that table now.
I set the default character as a space as the script does some testing
based on number of "." in the version string.

Tom
Matt Selsky
2009-11-11 19:54:35 UTC
Permalink
Post by Tom Sellers
I have attached an updated version of the db2-info.nse script that should
keep the probed version string if it is more precise. Either way the additional
data is generated when the verbosity is high enough.
I just tested this and the output maintains the precision. Thanks!
--
Matt
Ron
2009-11-09 16:18:57 UTC
Permalink
Hi Tom,

I couldn't find any DB2 servers in our environment that listen on 50000
or 60000. Perhaps it has to do with our lockdown profile, or something?

I found one that I could connect to on 6789, though I didn't try that
port on all of them.

Ron
Post by Tom Sellers
I have written a NSE script that enhances version detection for DB2. It also
gathers platform (OS) and database instance information. It functions in a similar
way to the MS SQL script.
The script sends a DB2 EXCSAT (exchange server attributes) command packet and
parses the response. This is a legitimate DB2 command and, based on my reviews
of logs, causes no problems on the server. DB2 does log the connection and the
source IP address though.
PORT STATE SERVICE VERSION
523/tcp open ibm-db2 IBM DB2 Database Server 9.07.0
50000/tcp open ibm-db2 IBM DB2 Database Server 9.07.0 (QDB2/LINUX)
| db2-info: DB2 Version: 9.07.0
| Server Platform: QDB2/LINUX
| Instance Name: db2inst1
|_ External Name: db2inst1db2agent000051B3%FED%Y00
In the sample output above the version of the DB2 DAS service on port 523 was
detected using nmap-service-probes. Historically, unlike the DAS port on 523,
we have been unable to detect the exact version number on the DB2 database
instances themselves. There may be multiple DB2 database instances and they
typically cluster around port 50000 and 60000.
Port 50000 would normally be detected as service "ibm-db2" with a version string
"IBM DB2 Database Server". The attached NSE script can now detect the exact
version number and platform as well as the instance name for each of the
databases.
Any testing or feedback with the functionality and structure of the script would
be greatly appreciated!
1. Is the default output too verbose? Should I limit the output to the info
on the port line by default and add the other lines with -v?
2. The data from the server is encoded in EBCDIC. I am decoding this will what
amounts to a lookup table. Is there a more appropriate/efficient way to
handle this?
3. I have built the EBCDIC table containing the ASCII chars that we should
encounter in this context. Should I go ahead and build out the full ASCII
table? (And wow, I am glad we don't use EBCDIC for much.)
Thanks much,
Tom
------------------------------------------------------------------------
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/
d***@hcsw.org
2009-11-09 23:20:47 UTC
Permalink
Works good for me:

PORT STATE SERVICE
50000/tcp open ibm-db2
| db2-info: DB2 Version: 8.02.9
| Server Platform: QDB2/SUN
| Instance Name: db2inst1
|_ External Name: db2inst1db2agent00002B430
Fyodor
2009-11-10 02:46:46 UTC
Permalink
Post by Tom Sellers
I have written a NSE script that enhances version detection for DB2.
It also gathers platform (OS) and database instance information. It
functions in a similar way to the MS SQL script.
From the feedback and functionality so far, it sounds like a winner!
If you commit it in the next day or two, it should be in time for the
new release.

Cheers,
-F
Continue reading on narkive:
Search results for '[SCRIPT] DB2 Information gathering script' (Questions and Answers)
3
replies
how do i make a good plan for a webapplication?
started 2006-12-07 07:41:19 UTC
programming & design
Loading...