IBM Support

Troubleshooting IBM Security Guardium Configuration and Activation of A-TAP on MongoDB instance: "WARNING: db-base directory <path> does not exist!!!"

Troubleshooting


Problem

When attempting to configure the Application TAP (A-TAP) on a MongoDB node as a way to perform Database Activity Monitoring (DAM) of encrypted client to server communications, you may be presented with the following message:

[<mongo_server> tmp]$ sudo /usr/local/guardium/guard_stap/guardctl --db-instance=<mongo_server_hostname> --db-home=/usr --db-base=/home/mongodb --db-type=mongodb --db-user=mongod store-conf
WARNING: db-base directory /home/mongodb does not exist!!!
WARNING: No Inspection Engine definition found with db_install_dir=/home/mongodb.
         STAP requires that at least one Inspection Engine is defined with
         db_install_dir set to the same value as db_base.
         STAP may not run if this ATAP is activated.

Symptom

When the above error message is presented, it may happen that you won't be able to correctly perform DAM of the desired MongoDB instance, for example, IBM Security Guardium Session reports do not show any traffic being Collected (reports are empty).

Cause

This type of issues happen when the parameters in the guard_tap.ini file (the Software TAP (S-TAP) configuration file) and the parameters passed to the guardctl configuration utility are not the same.

The error message reflects this inconsistency.

Environment

The contents in this technote were tested at the following environment:
Guardium version: 10.6.
MongoDB: v3.4.23, NON-Cluster server.
Operating System: Red Hat Enterprise Linux 7
The process referred to as Solution hereby should apply to upper versions.

Diagnosing The Problem

N/A (The Problem and Symptom sections of this document reflect the diagnose information)

Resolving The Problem

 

The following step-by-step is an example of what you can do in order to complete the A-TAP configuration.

This resolution is for a single MongoDB instance (non cluster) that is not installed inside a container (No Docker, No Kubernetes or similar are in place).

All the commands and paths displayed here are referential only. You must use the ones at the host where your MongoDB instance was installed.

1) First, the guard_tap.ini file must be configured properly by setting up a correct Inspection Engine. For a non-cluster MongoDB, a typical Inspection Engine may look like the one below. Once the configuration is done restart the S-TAP and check the configuration file to confirm the setup is correct.

[DB_0]
connect_to_ip=127.0.0.1
db2_fix_pack_adjustment=80
db2_shmem_client_position=0
db2_shmem_size=131072
db2bp_path=NULL
db_exec_file=/usr/bin/mongod
db_install_dir=/var/lib/mongo
db_type=Mongodb
db_user=mongod
encryption=0
db_version=0
instance_running=1
intercept_types=NULL
load_balanced=1
port_range_end=27017
port_range_start=27017
priority_count=20
real_db_port=27017
tap_identifier=MongoDB
tee_listen_port=0
unix_domain_socket_marker=NULL
networks=0.0.0.0/0.0.0.0

Tip 1: Most of the times, the S-TAP will be able to discover the DB product and setup an Inspection Engine for you.
If that does not happen, you can use the above inspection engine as an example.
Tip 2: The db_type parameter of the inspection engine has some special meaning in MongoDB, and you must set the proper value depending on your environment.
For single instance servers, use the value mongodb (just like in the example given).
For sharded MongoDB clusters, check what is the binary associated to the Mongo Database service: use the value mongodb where the mongod executable is present and the value mongodbs where mongos executable is present. Check with your MongoDB administrator to accurately identify what executable is present.

2) If any changes were done to the guard_tap.ini file , restart the S-TAP service.

3) Identify the proper values of the parameters that will be passed to the A-TAP configuration utility (guardctl) during the setup.

Below  you can find an example of how to accomplish the task.

a) --db-instance . You can use any value for this parameter. The advice is to use the MongoDB hostname.

b) --db-user. This is the administrative user who can start and stop mongodb service. Typically, this is an O.S. user for the database or a user that owns the process for the database executable. This user should be the same with guardctl parameter.

Tip 3: You can use standard Linux/UNIX utilities to figure out who is the owner of a process. For example, the below command can help you to identify what user is running the MongoDB so you can set this value properly during the A-TAP setup:
ps -fea | grep -i mongo

c) --db-home. Follow the tip 3 above to identify the full path to the MongoDB service executable. Then, simply remove the string /bin/<mongo_binary_file_name> from the path. The resulting string will be the value of db-home.

Example:

image-20200228162815-1

Above, you can see the MongoDB service binary is located at /usr/bin/mongod, if we remove "/bin/mongod", the resulting string is /usr. That will be the value of the --db-home parameter passed to the guardctl utility.

d) --db-base.  Every MongoDB instance comes with a configuration file (typically named mongod.conf). Search for the full path to this file and open it.

Tip 4. Again, checking the process table at the operating system level may give you a clue about where the MongoDB configuration file is located.
If you have doubts, check with your MongoDB administrator, or the MongoDB documentation.
image-20200228162815-2

Often the MongoDB configuration file will have a parameter to refer the data folder location. In the example given, the line "dbPath:    /var/lib/mongo" suggests the MongoDB installation can be found at the folder "/var/lib/mongo", which we will use as the value of the parameter db-base.

image-20200228162815-3

Tip 5. This method is also great to ensure your Inspection Engines have the proper value of db_install_dir defined at the guard_tap.ini file.

e) --db-type. Use the same value as defined at the Inspection Engines section of the guard_tap.ini file. Read the tip 2 in this technote.

4) Up to this point, you should have configured a proper Inspection Engine for your MongoDB and you able to map the values to be used during the A-TAP configuration. The next step is to try the A-TAP activation by executing the guardctl utility. The configuration utility path will change depending on the method used to install the S-TAP, but the idea remains the same:

a) If you installed the S-TAP using the Shell Script (NO GIM):

a1) Authorize the administrative user who can start/stop the MongoDB service if the user it not an LDAP user or if the guardium group is not an LDAP group, otherwise make sure the db_user parameter is correctly set at the guard_tap.ini file:

/opt/guardium/guard_stap/guardctl authorize-user mongod

a2) Store the A-TAP configuration, using the parameter values obtained at step 3:

/opt/guardium/guard_stap/guardctl --db-instance=localhost --db-home=/usr --db-base=/var/lib/mongo --db-type=mongodb --db-user=mongod store-conf

a3) We activate the A-TAP for the given instance.

/opt/guardium/guard_stap/guardctl --db-instance=localhost activate

b) If you installed the S-TAP using GIM:

b1) Authorize the administrative user who can start/stop the MongoDB service if the user it not an LDAP user or if the guardium group is not an LDAP group, otherwise make sure the db_user parameter is correctly set at the guard_tap.ini file:

/home/GIM/modules/ATAP/current/files/bin/guardctl authorize-user mongod

b2) Store the A-TAP configuration, using the parameter values we obtained at step 3:

/home/GIM/modules/ATAP/current/files/bin/guardctl --db-instance=localhost --db-home=/usr --db-base=/var/lib/mongo --db-type=mongodb --db-user=mongod store-conf

b3) We activate the A-TAP for the given instance.

/home/GIM/modules/ATAP/current/files/bin/guardctl --db-instance=localhost activate
 
Note 1: You must stop the MongoDB instance or service before trying to activate the A-TAP. After the activation is successful, you must restart the instance.
Note 2: REMEMBER. The commands above are only an example. You must always execute the guardctl utility using its full path, based upon your own IBM Security Guardium software installation.

Document Location

Worldwide

Operating System

System x:Red Hat Enterprise Linux 7

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSMPHH","label":"IBM Security Guardium"},"Component":"S-TAP, A-TAP","Platform":[{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"}],"Version":"10.x, 11.x","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}]

Document Information

Modified date:
02 April 2020

UID

ibm15611065