DB2 Processes

Before we examine how DB2 can be attacked and how it should be defended, let's look at some of the terminology used when talking about DB2. A computer running DB2 is known as a host . Each host can have one or more instances of DB2 and each instance can have one or more databases . In a default install two instances are created ”one known as DB2 and the other as DB2CTLSV. If the sample database has been installed, then this can be found in the instance named DB2. The tools database, toolsdb, can often be found in this instance as well. The Satellite control database, satctldb, if installed, can be found in the instance named DB2CTLSV. Each instance listens on its own distinct TCP port. For example, the DB2 instance listens on TCP port 50000 and the DB2CTLSV instance listens on TCP port 50001 (on Windows, DB2 can be configured to listen on named pipes, as well). Further to this there is the DB2 Database Administration Server, otherwise known as the DAS. The DAS listens on TCP and UDP port 523. As the name implies, the DAS is responsible for dealing with database administration requests .

Figure 6-1 shows a stylized representation of the processes that are integral to DB2. Instances, and its databases, are held in a process called DB2SYSCS on Windows or DB2SYSC on Linux. If you're wondering what the DB2FMP process is it's a host process for running fenced routines. Just in case the routine is buggy or behaves badly in some way, so as not to crash the main database process routines are generally loaded into db2fmp ”that is, the routine is "fenced." Administration requests are received by the DAS (DB2DASRRM).

Figure 6-1: DB2 processes.

Tip  

When I first started looking into DB2 security one of the most frustrating problems I had was simply trying to connect the DB2 client to a remote system. I'm sure if I'd read the documentation this wouldn't have been quite so frustrating and for those out there, who like me have a "right-here, right-now, right-away" mentality , I'll quickly describe how to hook up the client to a remote system. First, run the db2 client from a command line and when at the db2 prompt, enter the following:

 catalog tcpip node mynode remote 192.168.0.99 server 50000 

This creates a node called mynode locally. It points to a server listening on TCP port 50000 on IP address 192.168.0.99.

Next, you need to tell the client what database to connect to. You can do this with

 catalog database toolsdb as mydb at node mynode 

Note that you use mynode from the previous command and give the database a name of mydb. These are completely arbitrary ”you can call them what you want. toolsdb is the name of the database on the remote instance.

With this done you can then connect to the server.

Connect to

 mydb user root using quib1e 

where root is the user and quib1e is the (somewhat poor) password.

The session should flow as follows :

 db2 => catalog tcpip node mynode remote 192.168.0.99 server 50000 DB20000I  The CATALOG TCPIP NODE command completed successfully. DB21056W  Directory changes may not be effective until the directory cache is refreshed. db2 => catalog database toolsdb as mydb at node mynode DB20000I  The CATALOG DATABASE command completed successfully. DB21056W  Directory changes may not be effective until the directory cache is refreshed. db2 => connect to mydb user administrator using "foobar!!"        Database Connection Information      Database server        = DB2/NT 8.1.6  SQL authorization ID   = ADMINIST...  Local database alias   = MYDB     db2 => select 1 from sysibm.sysdummy1     1 -----------           1       1 record(s) selected.     db2 =>