Linux-UNIX: Troubleshooting S-TAP problems
You can use the S-TAP® Status monitor tab of the System View to begin investigating any problems. Sometimes you might need to use other tools, particularly if you are monitoring databases for which the inspection engines cannot be verified.
- If an S-TAP is not connected to your Guardium® system
- Check whether the IBM Security Guardium S-TAP service is
running on the database server:
On the database server, from the command line, run the command ps -ef | grep stap to verify that the S-TAP process is running. In the process list, look for /guardium/guard_stap.
- How to identify the S-TAP version?
-
- From the GUI, the S-TAP version number is displayed in
- Alternatively, you can display the S-TAP version number from the command line of the database server.
- Run debug from the command line to quickly identify configuration issues
- Use the GUI or the guard_tap.ini file to change the debug level to 4.
(Other values do different things, not all of them debug). There are a few guard_stap* logs, which
are located in the filepath that is specified by the tap_log_dir parameter.
- guard_stap.stderr.txt: contains all the output (and the extra debugging output) of S-TAP
- guard_stap.fam.txt: Exists only if FAM is enabled; contains all the output (and extra debug) of FAM monitoring.
- guard_stap.stdout.txt: Since v10.1.4, it is present in the system, but not used.
- Verify the connection between the database server and the Guardium system
-
- Verify that you can ping the Guardium system at sqlguard_ip from the database server.
- If the ping is successful, verify that you can telnet to the following ports on the Guardium system: 16016/16018.
- If there is a firewall between the database server and the Guardium system
- Verify that the following ports are open for traffic between these two systems: 16016, or 16018
for encrypted connections; if you're using FAM then verify ports 16022 or 16023 for
encrypted.Note: Use the following command to check the port availability: nmap -p port guardium hostname or IP
- Verify that the sqlguard_ip parameter is set to the correct guardium hostname or the IP for the Guardium system that you are connecting to.
-
- Click S-TAP Control. to open
- Locate the S-TAP Host for the IP address that corresponds to your database server.
- Expand the Guardium Hosts subsection, and verify that the active Guardium Host is correctly configured.
- If necessary, click Modify to update the Guardium Hosts.
- Verify that the S-TAP process is not repeatedly restarting
- On the database server, run the command ps -eaf | grep stap to verify that the process for S-TAP is not changing.
- Verify that S-TAP Approval is not turned on
- If S-TAP Approval is turned on, any new S-TAP that connects to the Guardium system is refused.
- Click S-TAP Certification. to open
- Look at the S-TAP Approval Needed checkbox . If this box is checked, new S-TAPs can connect to this Guardium system only after they are added to the list of approved S-TAPs.
- If S-TAP Approval is turned on, access the Approved Tap Clients report to view a list of approved S-TAPs. If the S-TAP that you are investigating is not on this list, return to the S-TAP Certification page, enter the IP address of the S-TAP in the Client Host field, and click Add.
- If the S-TAP shows green status but no data is being processed
- Check the status of the A-TAP.
- Db2 shared memory traffic is not captured
- Verify that the IE configuration is correct. Run the script
find_db2_shmem_parameters.sh
, located under stap_directory/bin. Execute it either as root or Db2 user, that uses the Db2 instance name as a parameter. It returns the shared memory parameters, including Db2 shared memory size, client position and header size. Verify that the IE parameters defined in the S-TAP match these returned values.
- S-TAP verification issues
-
The verification process attempts to log in to your database's STAP client with an erroneous user ID and password to verify that this attempt is recognized and communicated to the Guardium system. Your S-TAP might be configured in a way that prevents the inspection engine message from reaching the Guardium system from which the request was made.
These configuration details include:- Load balancing: if the S-TAP is configured to return responses to more than one Guardium system, the error message might be sent to a different Guardium system.
- Failover: If secondary Guardium systems are configured for the S-TAP, the error message might be sent to a secondary Guardium system if the primary Guardium system is too busy.
- db_ignore_response: if the S-TAP is configured to ignore all responses from the database, it does not send error messages to the Guardium system.
- Client IP/mask: if any mask is defined that is not 0.0.0.0, it might prevent the error message from being sent.
- Exclude IP/mask: if any mask is defined that is not 0.0.0.0, it might prevent the error message from being sent.
- Enable FAM as S-TAP is installed with default value of fam_installed as 0 so the FAM does not load and is disabled.
- To enable FAM, follow the applicable instructions:
- For Shell installation on the database server
- In the
guard_tap.ini
S-TAP configuration file, update the value of fam_installed and fam_enable parameters to 1 and then restart the server. - For GIM S-TAP bundle installation
- Update the value of STAP_FAM_INSTALLED and STAP_FAM_ENABLED parameters to 1 and then restart the server.
- TLS 1.3 and FIPS 140-3 not supported on Solaris operating system
- IBM Security Guardium does not support Transport Layer Security (TLS) 1.3 in Guardium Data Protection version 12.0 and later on the Solaris operating system.