Linux-UNIX: S-TAP monitoring mechanisms
The Guardium® UNIX S-TAP® uses several different monitoring mechanisms to collect database traffic. During configuration, you can choose the method that best meets your requirements. All mechanisms filter the traffic to reduce network overhead and increase performance.
You choose the mechanism during installation. All mechanisms filter the traffic so that only database-related traffic for specific sets of client and server IP addresses is collected. The mechanisms are presented here in order of preference: exit libraries, K-TAP, A-TAP, PCAP. See Linux-UNIX: S-TAP monitoring mechanisms support matrix and choose the mechanism that meets your needs.
- Exit libraries
- The exit libraries are the preferred monitoring mechanism. They give the best performance, and can handle both local and network traffic, whether encrypted or not. They always capture DB_USER. The only disadvantage is that exit libraries are supported only for Db2, Informix, and Teradata.
- K-TAP
- K-TAP is
a kernel module that is installed into the operating system. It supports all protocols and
connection methods (for example, TCP, TLI, SHM, Named Pipes). When enabled, it observes access to a database server by hooking into the
mechanisms that are used to communicate between the database client and server.
With Linux, the kernel frequently updates, and there are many kernel versions. The K-TAP version depends on the Linux version. See Linux-UNIX: S-TAP compilation of K-TAP.
K-TAP is installed during S-TAP installation. If K-TAP fails to install, PCAP is installed instead. After it is installed, it can be enabled or disabled with a configuration file setting. If you do not load K-TAP during the S-TAP installation, and decide later that you want to use it, you need to reconfigure and restart the S-TAP.
- A-TAP
-
The A-TAP (application-level tap) sits in the application layer to support monitoring of encrypted database traffic, which cannot be done in the kernel by K-TAP. A-TAP monitors communication between internal components of the database server. It picks up unencrypted data in the application layer, and sends it to the K-TAP. K-TAP is a proxy to pass data to S-TAP, which then sends it to the Guardium collector.
With A-TAP, instead of capturing data from the kernel, where the data is still encrypted, Guardium captures data by loading a TAP library before executing the original database binary. The A-TAP libraries are a no-op (no interface). The libraries tap the database in application-mode, after the data is decrypted or before it is encrypted by the database. Hence there are no changes made to how the database would normally operate other than the encrypted traffic is now being captured by Guardium. This means that you do not need to update scripts and tools to call the Guardium code before executing the Oracle code.
A-TAP is included in every S-TAP but must be configured separately for each database instance to be monitored. See Linux-UNIX: A-TAP management.
Restrictions:- A-TAP is not supported in an environment where a 32-bit database is located on a 64-bit server.
When to use A-TAP?
A-TAP is required when DBMS encryption in motion is used, but there may be other internal database implementation details such as shared memory that require it.
Informix and Db2 on Linux integrate with Guardium more closely using an exit and thus are the recommended method for shared memory support when applicable.
- PCAP
- PCAP is
a packet-capturing mechanism that listens to network traffic from and to a database server. In a
UNIX
environment, since the K-TAP captures all
network traffic, PCAP is rarely used.
PCAP is used to
capture local TCP/IP traffic on the device. Restriction:
- PCAP only works on ports (no shared memory, and so on).