Linux-UNIX: UID chains

UID chain is a mechanism that allows S-TAP (by way of K-TAP) to track the chain of users that occurred before a database connection.

You can change usernames several times before you connect to the database. For example, you can run the following commands: ssh informix@barbet, then su - db2inst1, then su - , then su - oracle9, and end with sqlplus scott/tiger@onora1. With UID Chains, Guardium® can trace this process back to the process that called it, and back to the original (offending) user.

The UID chain values vary by OS platform. For example, under AIX the string IBM might appear as a prefix. For MongoDB, you can use a UID chain to determine the DB_USER for reports, as MongoDB does not include OS_USER in the login packet.

Enabling UID chains should not affect performance.

See the Guardium support matrix for a full list of operating systems and databases that support UID chains.

Limitations

  • For Solaris Zones, user IDs might be reported instead of usernames.
  • The SSH client's IP address and port are added to the UID chain.
  • PostgreSQL on Solaris 11 with zones is not supported, due to zone configuration not allowing access from primary to subordinate zones in some directories.
  • Solaris Zones and AIX® WPAR - set the db2bp_path in the guard_tap.ini file to the full path of the db2bp executable file (the full path of the relevant db2bp as seen from the global zone/wpar).
  • UID Chains are not reported for Inter-process Communication (IPC) on Solaris 8/9.
  • UID chains are not detected for Hadoop databases.
  • UID chain does not support local TCP on Linux for Db2. In addition, Db2 exit requires a specific version of the database to support UID chains.
  • When running as a non-root user, UID chain does not work for Db2 Shared Memory (SHM) with S-TAP.
  • Guardium does not log UID chain for network traffic.
  • Guardium might not log UID chain for very short sessions since Guardium relies on the process ID of the application to determine the UID chain. If the process that starts the session exits before S-TAP can examine it, UID chain does not work.
  • UID is not captured for Cassandra Datastax when Audit logging is used.
  • UID is not captured for Cassandra Apache when Audit logging is used.
  • UID chain is supported in these scenarios that require A-TAP for intercepting the traffic:
    • Sybase SSL traffic when the min and max port are set in the executor.
    • Mongo and Postgres SSL traffic.
    • Teradata encrypted traffic.
    All other scenarios that require A-TAP are not supported.

Configuring UID chain

You can control UID configuration with the following parameters,
  • hunter_trace - Enable this guard_tap.ini parameter to log UID chain for all database connections.
  • uid_chain_sshd_ip - Enables adding an SSH client IP:port to the UID chain when SSH is identified as one of the processes in the chain.
The UID chains are logged in the collectors,
  • UID_CHAIN - The full chain of users, for example,
    (1,root,init [5])>(3746,root,/usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid)>
(6948,root,sshd: root@pts/2)>(6950,root,-bash)>(7481,root,su - informix)>(7482,informix,-bash)>
(7522,informix,su - db2inst1)>(7523,db2inst1,-bash)>(7941,db2inst1,su - oracle12)>
(7942,oracle12,-bash)>(7982,oracle12,sqlplus)
  • UID_CHAIN_COMPRESSED - The UID chain, excluding the first user and the last user, in this example, informix, db2inst1.

UID chains in reports

To view UID chains in reports, use the UID Chain and UID Chain Compressed attributes in the Session entity.
Note: When you call the UID Chain or UID Chain Compressed attributes in a report, you might see a delay of up to 3 minutes in the UID Chain response.

UID chains can be logged to Syslog with %%compressed_uid_chain or %%uid_chain alert messages.

Purging of UID chain records

UID chain records that are older than 2 hours are purged when the regular inference process runs. (Inference goes over all the records and consolidates them.) Records that are older than 24 hours are purged on a nightly basis.