Depending on how it is installed and configured, Unix S-TAP collects traffic using a variety of mechanisms. To collect network traffic, it always uses PCap (see below). Regardless of the mechanism used, the traffic is filtered, so that only database related traffic for specific sets of client and server IP addresses is collected.
PCap is a packet-capturing mechanism that listens to network traffic from and to a database server. PCap is used to monitor network traffic, regardless of whether the K-Tap or Tee mechanism is used for local traffic. On Linux, PCap is also used to capture local TCP/IP traffic on the lo device.
K-Tap is the recommended mechanism to collect local traffic on a Unix database server. Unlike the Tee (see below), with K-Tap you do not need to change how database clients connect to the server. K-Tap is a kernel module that is installed into the operating system. Once installed, it can be enabled or disabled using a configuration file setting. When enabled, it observes all local access to a database server by hooking the mechanisms used to communicate between the database client and server. There are several mechanisms used for each database type, and K-Tap hooks all of them. When K-Tap is disabled, the Tee can be used to monitor local traffic (see below). K-Tap and Tee are almost always mutually exclusive – to monitor local access you either use K-Tap or the Tee.
At installation time, you will choose whether or not to load the K-Tap kernel module to the server operating system. This is the only way to load that module. If you do not load K-Tap initially, and decide later that you want to use it (instead of the Tee - described below), you will need to remove S-TAP, and then re-install it.
Some traffic can only be tapped at the database server application level. This may be required because the DBMS uses its own encryption, or because of other internal database implementation details. For these cases, the A-Tap (application-level tapping) mechanism monitors communication between internal components of the database server. A-Tap depends on K-Tap, and it must be configured separately for each database instance to be monitored.
A-Tap is used for monitoring the following:
ASO encrypted traffic for Oracle (versions 9, 10 and 11) on AIX, HPUX, Solaris and Linux.
Shared memory for DB2 and Informix on Linux
A-Tap is installed as an added product and requires separate configuration on the database machine itself.
The Tee is a proxy mechanism that reads and forwards traffic from local clients to a database server. As the Tee receives database traffic, it forwards one copy to the database server and one copy to S-TAP. When the Tee is used, database clients must connect to the Tee listening port instead of the database listening port. This means that you must either modify how the database client connects to the server, or how the database server accepts client connections. In either case, this is usually a minor configuration change to one or two files (depending on the database type) and the end result is that, as far as the clients are concerned, the Tee is the database, and as far as the database is concerned, the Tee is the client. All this is transparent to both the clients and the server – but the configuration change is required to ensure that the connection is made through the Tee. When the Tee is used, database clients can bypass the Tee by connecting to the database listening port (instead of the Tee listening port), or by using named pipes, shared memory, or other inter-process connection mechanisms depending in the database type. For detailed information about configuring clients to connect to the Tee, see Prepare for Local Clients to Use the Tee.
We refer to any connections that are not made through the Tee listening port as rogue connections. When the Tee is used, you can enable an optional component called the Hunter to watch for, report upon, and optionally disable rogue connections. The Hunter runs at random intervals, so it may not detect all such connections, and while it can report on rogue connections and optionally disable them, it cannot audit what actions were performed by those connections. Another aspect of the Hunter is that when it wakes up to hunt for rogue connections, it can be CPU-intensive, so if you look at the Hunter process at that instant, it may appear to be consuming a lot of a server CPU resource. (The CPU use will drop quickly after a momentary spike.)
Note: To use the Hunter, version 5.8.0 or later of Perl must be installed in the /usr/bin/ directory.
If you are upgrading S-TAP, you can remove the previous version first, see Remove Previous Unix S-TAP, below, or you can use the new Unix upgrade procedure, also below: Upgrade Procedure Utility.
When installing S-TAP in a Solaris zones configuration, S-TAP must be installed in the global zone only, regardless of the zone in which the database runs. (From the global zone, S-TAP monitors access to databases in all zones.)
Obtain the IP address of the database server on which you are installing S-TAP. If virtual IPs are used, note those as well (you will need to configure those later, when completing the configuration from the administrator portal).
Obtain the IP address of the Guardium appliance that will control this S-TAP, and to which this S-TAP will report.
If there is a firewall between the Guardium appliance and the database server, verify that the ports used for connections between those components are not being blocked. See Guardium Port Requirements in the S-TAP Installation Overview.
Choose the monitoring method to be used by S-TAP:
K-Tap is a kernel module, and it supports all protocols and connection methods (TCP, TLI, SHM, Named Pipes, etc.)
TEE is not a kernel module, and supports only TCP connections. In this configuration there is an option to alert on rogue connections. See the description of the S-TAP monitoring mechanisms, in the Overview topic above. This option requires Perl. See Get Perl Information, below, to verify that you have the correct version of Perl.
Decide if you want to install the CAS agent. (The Change Audit System is a separate product.) If so, see Get Java Information, below, to verify that you have the correct distribution and version of Java, and to obtain the JAVA_HOME directory location.
Decide if you need to install A-Tap, which is an add-on product. If so, see Configure A-Tap, below.
Check the S-TAP Prerequisites topic in the S-TAP Overview to see if any additional software components must be installed or configured in a particular way for S-TAP.
To install Unix S-TAP, run the appropriate installation script, as described below. If any stage of the installation fails, undo all of the steps up to that point. Do not leave S-TAP partially installed.
Log on to the database server system using the root account.
Some companies require the use of native installers to register packages on the system, or to perform other house-keeping functions. If this is a requirement for you, see Use Unix S-TAP Native Installers, below, before continuing with the next step.
Copy the appropriate S-TAP installer script from the Guardium Installation CD (or network), to the local disk on the database server. The installer script name identifies the database server operating system. For example, the Suse 10 installer program for for x64 version 7.0 of S-TAP is named:
suse10-x86_64-sqltap_installer-70_0.sh
See full list of Unix installer files to select the correct file.
Decide how you will run the installer:
Non-interactive mode is recommended for larger S-TAP deployments (10 or more servers). To use this mode, skip the remainder of this procedure and go to Install Unix S-TAP from the Command Line, below.
Interactive mode is recommended for smaller deployments (less than 10 servers). Continue with this procedure for interactive mode.
Run the installer
and respond to the legal notification and other prompts, as directed by
the installer. We suggest that you accept all of the supplied defaults.
The installer opens the S-TAP configuration file for editing, under
vi. Although you can modify
all of the configuration file properties at this time, we strongly recommend
that you modify only the properties described below. Setting these properties
will allow you to start the S-TAP and connect to the Guardium appliance.
After that, you can complete the configuration from the administrator
portal of the Guardium appliance, which is the easier and safer than editing
the configuration file manually.
After the installer opens the configuration file under
vi, locate and set the following
required parameters:
tap_ip=your_database_server_ip_address
For systems other than HPUX, you can enter
the symbolic name of the sever instead of the IP address.
sqlguard_ip=guardium_appliance_ip_address
Enter the IP address of the
primary Guardium host for this S-TAP. The primary host is the one that
S-TAP will try to connect with each time that it restarts. You can identify
secondary (failover) Guardium hosts later, from the Guardium administrator
portal.
Depending on the monitoring method to be used, set the two parameters as shown in the following table:
|
K-Tap Monitoring Kernel module installed. Monitor all local connections to the database. |
Tee Monitoring No kernel module installed. Monitor only TCP connections. |
|
tap_installed=1 |
tap_installed=0 |
Use the wq command to save the configuration file and quit vi. The install program will check the parameter values you have set. If OK, it will continue to the next prompt. Otherwise, you will need to correct any erroneous parameters and then save the file again.
Respond to the CAS installation prompt, and if installing CAS enter the name of the JAVA_HOME directory.
This step applies for AIX only (skip for all others). Restart the database service and the listener.
Complete the S-TAP configuration from the administrator portal. See Configure S-TAPs from the GUI.
If you are using the Tee to monitor local connections, perform the appropriate procedure below:
You can supply all of the parameters needed to install Unix S-TAP from the command line. In fact, if you are installing the same operating-system version of S-TAP on multiple database servers, you can perform the task by running a single command, using the -tapfile parameter.
Variables are shown enclosed in angled brackets: < >. Each component is described below.
<s-tap_installer.sh> -ni -tapfile <file> -tapip <tap_ip_address> -sqlguardip <guardium_ip> -k -t -c -dir <s-tap_dir> -jdir <java_dir>
<s-tap-installer.sh> is the name of the shell script file.
-ni indicates that the shell is being run in non-interactive mode.
-tapfile <filename> identifies a text file listing one or more servers on which the S-TAP agent is to be installed. Each row of the text file must have the following format, with each of the following three variables separated from the next by a tab character: <hostname> <tap_ip> <sqlguard_ip>, where hostname is the name of the database server, tap_ip is the IP address of the database server, and sqlguard_ip is the IP address of the Guardium appliance. Omit this parameter if the next two are used.
-tapip <ip_address> specifies the IP address of the database server. Omit if -tapfile is used.
-sqlguardip<guardium_ip> specifies the IP address of the Guardium appliance. Omit if -tapfile is used.
-k indicates that K-Tap should be installed, or -t indicates that the Tee should be installed.
-c indicates that CAS should be installed.
-dir <s-tap_dir> identifies the s-tap installation directory
-jdir <java_dir> identifies the JAVA_HOME directory. See Get Java Information.
Upgrader is a new utility that gives the administrator the option to upgrade to a higher S-TAP version the next time that the system is rebooted.
NOTE: If you have installed A-Tap, you must deactivate it before attempting any upgrade/install operations; see the description of the A-Tap deactivation command, in the Configure A-Tap topic, below.
To use the upgrader utility:
Transfer the following files to the same directory on the database server machine:
g-upgrader
upguard
guard_tap.ini (the default guard_tap.ini file of 7.0)
Transfer the appropriate installation file for the database server to the same directory as above. For example: suse10-x86_64-sqltap_installer-70_0.s. See Unix Installer Files for a complete list of files.
Grant 754 permissions to the upgrader files and the installer file.
Run the following command (see the example below):
g-upgrader --dir "full path of current install
dir"
--ini "full path and name of the ini file for the new version"
--installer "full path and name of the installer"
[ -c --jdir "java dir"]
Assume that the installer file named suse10-x86_64-sqltap_installer-70_0.sh and the two installer files (g-upgrader & upguard) have been placed in /var/tmp.
To run the upgrader utility for an installation without CAS, the following command would be used:
g-upgrader --dir /usr/local/guardium/guard_stap --ini /usr/local/guardium/guard_stap/guard_tap.ini --installer /var/tmp/ suse10-x86_64-sqltap_installer-70_0.sh
To run the upgrader utility for an installation with CAS, the following command would be used:
g-upgrader --dir /usr/local/guardium/guard_stap --ini /usr/local/guardium/guard_stap/guard_tap.ini --installer /var/tmp/ suse10-x86_64-sqltap_installer-70_0.sh -c --jdir /usr/java
After running the upgrader the system must be rebooted in order for the upgrade to take place. Note that the 'reboot' command cannot be used in some operating systems as a trigger for the upgrade process - instead, the following commands needs to be executed (per OS):
Linux Redhat : shutdown -r
Linux SuSe : reboot
HP : shutdown -r
Solaris : shutdown -i [6|0] (Note : '0' can be used only if shutdown is done from the terminal server)
AIX : reboot
Note: The upgrader does not currently support OSF1/Tru64 platforms.
The upgrader performs a full un-install and then a full scratch install. After the system is up, two log files can be found in the directory where the installer in located:
ginstall.log
guinstall.log
The upgrader will not rollback following a failure. Manual steps will have to be taken in order to reinstall the previous version.
Perform this procedure before installing a new version of S-TAP if you want to save the old configuration file. For an upgrade, we recommend that you use the Upgrade Procedure Utility described above.
If S-TAP was previously installed, there will be a directory named: /usr/local/guardium/guard_stap.
NOTE: If you have installed A-Tap, you must deactivate it before attempting any upgrade/install operations; see the description of the A-Tap deactivation command, in the Configure A-Tap topic, below.
If you are removing a previous version of S-TAP that used K-Tap, you will need to reboot the database server (twice on HP-UX) as described below. If K-Tap has been installed, you will have a device file named: /dev/guard_ktap.
Log on to the database server system using the root account.
Open the /etc/inittab file for editing.
Remove the guard_stap, guard_tee, and guard_hnt entries in the /etc/inittab file (regardless of whether or not any of them have been commented). In a default installation, these statements should look like this (in an AIX environment, the comment character is the colon (:), not the pound sign (#) as illustrated below):
utap:<nnnn>:respawn:/usr/local/guardium/guard_stap/guard_stap /usr/local/guardium/guard_stap/guard_tap.ini
#utee:<nnnn>:respawn:/usr/local/guardium/guard_stap/guard_tee /usr/local/guardium/guard_stap/guard_tap.ini
#hsof:<nnnn>:respawn:/usr/local/guardium/guard_stap/guard_hnt
If uninstalling version 6.0 or later of S-TAP, remove the CAS agent entry in the /etc/inittab file (regardless of whether or not it has been commented). In a default installation, this statement should look like this:
cas:<nnnn>:respawn:/usr/local/guardium/guard_stap/cas/bin/run_wrapper.sh /usr/local/guardium/guard_stap/cas/bin
Save the /etc/inittab file.
Run the init q command, and then run ps –ef | grep stap to verify that S-TAP is no longer running.
Copy the S-TAP configuration file to a safe location
(a “non-Guardium” directory). By default, the full
path name is:
/usr/local/guardium/guard_stap/guard_tap.ini.
You can use this file later if you have to re-install this version
of the software, or you can refer to it when configuring an updated version
of S-TAP. Do not ever use an older
configuration file directly with a newer version of the software – newer
properties may be missing, and the defaults taken may result in unexpected
behavior when you start S-TAP.
This step applies to HP-UX servers only (skip for all others). If you are uninstalling a previous version of S-TAP that included K-Tap, reboot the database server now.
Run the uninstall program: uninstall.sh.
For example, if the default directory has been used:
[root@yourserver ~]# /usr/local/guardium/guard_stap/uninstall.sh
Note: Do not run the uninstall program with S-TAP running. Be
sure that you have stopped S-TAP as described above.
If your previous version of S-TAP included K-Tap, reboot the database server now, for the second time. Do not skip this step.
If upgrading, upgrade the Guardium appliance that serves as the S-TAP host, before upgrading S-TAP.
Return to the installation procedure: Install Unix S-TAP.
When installing CAS (the Change Audit System) on a Unix system, there are two requirements:
You must locate the JAVA_HOME directory. You will be prompted for its location during the CAS installation.
You must verify that a supported version of Java is installed (see the table below). If a supported version is not installed, you must install it before installing CAS.
|
OS Type |
Java Version |
|
HPUX |
1.5 or higher |
|
All others |
1.4.2 or higher |
Perform this procedure first, and after locating the JAVA_HOME directory, perform the following procedure to check the Java version. You can print this page and note the directory location and version in the space below:
|
JAVA_HOME |
|
|
Java Version |
|
The JAVA_HOME directory is the directory above the directory containing the java command. For example:
If the java command is /usr/local/j2sdk1.4.2_03/bin/java
the JAVA_HOME directory is /usr/local/j2sdk1.4.2_03
Use one of the following techniques to locate the java command directory.
Enter the which java command. For example:
[root@yourserver ~]# which java
/usr/local/j2sdk1.4.2_03/bin/java
If the which java command returns a symbolic link, use the ls –ld <symbolic_link> command to determine the real Java directory name.
If the which java command returns the message command not found, Java may be installed, but it has not been included in the PATH variable. In this case, use the find command to locate the Java directory; for example:
[root@yourserver ~]# find . –name java
./usr/bin/
From the java directory, run the java –version command to check the version number. For example:
[root@yourserver ~]# /usr/local/j2sdk1.4.2_03/bin/java –version
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
Note the Java version above. You will not be prompted for this information, but in the event that an issue arises later, you will be able to eliminate the possibility of an unsupported Java version.
This Perl requirement applies only to the following combination:
Unix S-TAP
The TEE mechanism selected to monitor local traffic
The Hunter process is used to detect and optionally kill processes that bypass the Tee listening port
In this situation, you must have:
Version 5.8.0 or later of Perl
Perl must be installed in the /usr/bin directory
To verify that you have version installed, use the following command:
/usr/bin/perl -v
If Perl is not installed, is installed in a different directory, or an older version is installed, you must install version 5.8.0 or later of Perl in the /usr/bin directory, before installing S-TAP.
A-Tap is controlled by guardctl utility, which is installed in <guardium_base>/guard_atap/bin directory, where
<guardium_base> is the directory where the Guardium software is installed. By default, it is /usr/local/guardium.
Note: The guardctl utility requires version 3 or greater of bash.
The guardctl utility provides commands to:
Install or remove A-Tap
Upgrade A-TAp
Activate or de-activate A-Tap
To use the guardctl utility, you must log in as root, since it requires superuser privileges.
<guardium_base>/guard_atap/bin/guardctl [<name>=<value>]
[<name>=<value> ...] [command]
help - Default command, prints the list of supported commands, parameters and their default values
store-conf - Allows storing parameter values as defaults
list-active - Lists DB instance user names of all active DB instances
is-active - Returns 1 if there is at least one active instance, 0 otherwise
activate - Activates DB instance. Requires DB-specific parameters (see details below)
deactivate - Deactivates one DB instance
deactivate-all - Deactivates all active DB instances
For most of these commands the db_instance parameter is mandatory. See the description of the individual commands bellow for details on all other parameters.
Once installed, A-Tap must be configured separately for each instance of the database on the server.
The following table summarizes the configuration parameters that have to be specified for different databases.
|
DB Type |
Parameter |
Default Value |
Description |
Mandatory? |
|
All |
db_instance |
none |
Unique identifier for the DB instance. For Oracle, use $ORACLE_SID value, for Informix and DB2 use OS user name or DB instance name. |
yes |
|
|
db_user |
none |
OS user name for this DB instance. Has to be specified explicitly even if the user name is used as db_instance |
yes |
|
|
db_type |
none |
oracle, informix or db2 |
yes |
|
|
db_base |
db_user 's home directory |
DB instance user home directory |
no |
|
|
db_bits |
guessed based on DB executable |
DB instance architecture (32 for 32-bit, 64 for 64-bit) |
no |
|
Oracle Only1 |
db_home |
$ORACLE_HOME value if defined, db_base otherwise |
Where DB software is installed |
yes |
|
|
db_version |
any (must be a numeric value on AIX ) |
DB instance version |
no (yes on AIX ) |
|
|
db_relink |
no (yes on AIX ) |
ATAP activation method |
no |
|
Informix Only |
db_home |
db_base |
Where DB software is installed |
no |
|
|
db_version |
must be a numerical value |
DB instance version |
yes |
|
|
db_info |
/INFORMIXTMP/.inf.sqlexec |
Additional DB info file |
no |
|
DB2 Only |
db_home |
db_base |
Where DB software is installed |
no |
|
|
db2_shmsize |
131072 |
DB2 shared memory size2 |
yes |
|
|
db2_c2soffset |
61440 |
DB2 shared memory client-to-server area offset2 |
yes |
|
|
db2_header_offset |
20 |
DB2 shared memory header offset2 |
yes |
|
|
db_version |
any |
DB instance version |
no |
1 If the Oracle Listener and all Oracle instances are not running under the same user, all users must belong to the same group (a shared one) in order to capture Oracle TCP traffic. In addition, in HPUX, HP-2005-security-patch is required.
2 The DB2 shared memory-related parameters should be determined at installation time using the procedure described under the DB2 Linux S-TAP Configuration Parameters topic, below.
Use the store-conf command to name and save the configuration for an instance of the database.
<guardium_base>/guard_atap/bin/guardctl db_instance=<instance>
[<name>=<value> ...] store-conf
The value specified for instance can be used later to reference this configuration in other guardctl commands.
Use the activate command to activate A-Tap. A-Tap must be activated for each DB instance to be monitored on the server. Note the following:
A-Tap cannot be activated or deactivated while the database instance is up and running.
A configuration must be stored for an instance (using store-conf, above), before A-Tap can be activated for that instance.
Additional A-Tap parameters may be specified on the command line.
Command line parameters override and replace stored parameters.
All users for the database instance must be logged off from the system during A-Tap database instance activation.
<guardium_base>/guard_atap/bin/guardctl db_instance=<instance> [ <name1=value1> ... <nameN=valueN> ] activate
Use the deactivate command to deactivate A-Tap for a specific database instance. Note the following:
A-Tap cannot be activated or deactivated while the database instance is up and running.
All users for the database instance must be logged off from the system during A-Tap database instance activation.
<guardium_base>/guard_atap/bin/guardctl db_instance=<instance>
deactivate
[ --force-action=yes ]
If the optional --force-action parameter is specified and its value is set to yes, forced deactivation will be attempted. In particular, it will try to deactivate a DB instance even if it is running or the OS user is logged in.
In addition, the --force-action option may be used to clean up leftovers of previous activations; for example. if a database instance has been removed or reinstalled without deactivation, the --force-action switch instructs guardctl to clean up its records and get rid of stale information.
Use the deactivate-all command to deactivate A-Tap for all database instances on the server
<guardium_base>/guard_atap/bin/guardctl db_instance=<instance>
deactivate-all
A-Tap is removed or upgraded by the standard S-TAP remove or upgrade procedures. However, in order to be removed, A-Tap must first be deactivated on all database instances (see the deactivate-all Command topic, immediately above).
To obtain a list of currently active A-Tap database instances, use the list-active command described below.
Use the following command to list all active A-Tap database instances:
<guardium_base>/guard_atap/bin/guardctl list-active
Alternatively, use the following command to determine if there is an active instance:
<guardium_base>/guard_atap/bin/guardctl db_instance=<instance_name> is-active
This command returns true if there is an instance, or false otherwise.
A native installer ensures that S-TAP is registered in the operating system asset repository. This is not required by Guardium for the installation of the S-TAP agent, but it may be a requirement at your company. There is a separate native installer for each supported variation of Unix.
To use a native installer, refer to the appropriate topic for your operating system:
Note: There are no native installers for Tru64 systems.
Locate the appropriate native installer file from the Guardium S-TAP Installation CD, for your version of AIX:
|
AIX Version |
Native Installer Filename |
|
5.1 |
aix51-powerpc-sqlstap-installer-70_0-1.bff |
|
5.2 |
aix52-powerpc-sqlstap-installer-70_0-1.bff |
|
5.3 |
aix53-powerpc-sqlstap-installer-70_0-1.bff |
|
6.1 |
aix61-powerpc-sqlstap-installer-70_0-1.bff |
If you are unsure about which file to use, contact Guardium support.
Enter the following command, substituting the appropriate
filename from the table above:
/usr/lib/instl/sm_inst installp_cmd -a -Q -d '.' -f <filename>
'-c' '-N' '-g' '-X' '-G'
Continue with Step 3 of the installation procedure, running the generated installation script rather than the default installation script for the operating system version.
Return to Step 5 of the Unix Installation procedure.
To remove AIX S-TAP using the native installer, use the following command, replacing filename as described above:
/usr/lib/instl/sm_inst installp_cmd -u -f <filename>
To install, use the following command to generate the HPUX native installer script, and then continue with Step 3 of the installation procedure, running the generated script rather than the default installation script for the operating system version.
Locate the appropriate native installer file on the Guardium S-TAP Installation CD, for your version of HPUX.
|
HPUX Version |
Native Installer Filename |
|
11.00 |
GuardiumSTAP-hpux11.00-parisc.depot.gz |
|
11.11 |
GuardiumSTAP-hpux11.11-parisc.depot.gz |
|
11.23 PA-RISC |
GuardiumSTAP-hpux11.23-parisc.depot.gz |
|
11.23 IA-64 |
GuardiumSTAP-hpux11.23-parisc.depot.gz |
|
11.31 PA-RISC |
GuardiumSTAP-hpux11.31-parisc.depot.gz |
|
11.31 IA-64 |
GuardiumSTAP-hpux11.31-ia64.depot.gz |
If you are unsure about which file to use, contact Guardium support.
Enter the swinstall command as follows, supplying the selected filename (from the table above) and your database server hostname. This is an interactive program. Follow the prompts and use the appropriate controls to install the appropriate S-TAP installation program, which will be located in /var/spool/sw/var/tmp
swinstall -s /var/tmp/<filename>.depot @ <hostname>:/var/spool/sw
Continue with Step 3 of the installation procedure, running the generated installation script rather than the default installation script for the operating system version.
Return to Step 5 of the Unix Installation procedure.
To remove HPUX S-TAP using the native installer, use the following command:
swremove @<hostname>:/var/spool/sw
To install, use the following command to generate a Linux native installer script, and then continue with Step 3 of the installation procedure, running the generated script rather than the default installation script for the operating system version.
To install:
Locate the appropriate Linux native installer file on the Guardium S-TAP Installation CD, for your version of Linux. There is a separate table for each supported Linux vendor, below.
Red Hat Enterprise Linux - Versions 3, 4, and 5
|
OS |
Installer Filename |
|
32-Bit |
redhat3-i386-sqlstap-installer-7.0-1.i686.rpm redhat4-i386-sqlstap-installer-7.0-1.i686.rpm redhat5-i386-sqlstap-installer-7.0-1.i686.rpm |
|
64-Bit |
redhat3-x86_64-sqlstap-installer-7.0-1.x86_64.rpm redhat4-x86_64-sqlstap-installer-7.0-1.x86_64.rpm redhat5-x86_64-sqlstap-installer-7.0-1.x86_64.rpm |
|
Itanium |
redhat3-ia64-sqlstap-installer-7.0-1.ia64.rpm redhat4-ia64-sqlstap-installer-7.0-1.ia64.rpm redhat5-ia64-sqlstap-installer-7.0-1.ia64.rpm |
SUSE Linux Enterprise - Versions 9, 10
|
OS |
Installer Filename |
|
32-Bit |
suse9-i386-sqlstap-installer-7.0-1.i686.rpm suse10-i386-sqlstap-installer-7.0-1.i686.rpm |
|
64-Bit |
suse9-x86_64-sqlstap-installer-7.0-1.x86_64.rpm suse10-x86_64-sqlstap-installer-7.0-1.x86_64.rpm |
If you are unsure about which file to use, contact Guardium support.
Enter the rpm command supplying the selected filename:
rpm -i <filename>
For example:
rpm -i suse10-x86_64-sqlstap-installer-7.0-1.x86_64.rpm
Continue with Step 3 of the installation procedure, running the generated installation script rather than the default installation script for the operating system version.
Return to Step 5 of the Unix Installation procedure.
To remove S-TAP using the native installer, use the following command (selecting filename as above):
rpm -e <filename>
If you have used other Unix S-TAP native installers, note that this one runs an installation script, whereas the others only generate an installation script.
Locate the appropriate native installer file on the Guardium S-TAP Installation CD, for your version of Solaris:
|
Solaris Version |
Native Installer Filename |
|
6 |
GuardiumSTAP-solaris6-sparc.pkg |
|
8 |
GuardiumSTAP-solaris8-sparc.pkg |
|
9 |
GuardiumSTAP-solaris9-sparc.pkg |
|
10 |
GuardiumSTAP-solaris10-sparc.pkg |
|
10 (Intel 32-Bit) |
GuardiumSTAP-solaris10-i386.pkg |
|
10 (Intel 64-Bit) |
GuardiumSTAP-solaris10-i386-64.pkg |
Enter the pkgadd command to run the installer using the selected file:
pkgadd -d <filename>
The installation output should look something like this:
## Installing part 1 of 1.
/var/tmp/sparc-solaris8-sqltap_installer-nn_m.sh
WARNING: installing with
default mode of 644
verifying class ]
## Executing postinstall script.
sparc-solaris8-sqltap_installer-nn_m.sh available on /var/tmp
Installation of was successful.
Return to Step 5 of the Unix Installation procedure.
To remove Solaris S-TAP using the native installer, use the following command:
pkgrm GrdTapIns?
This topic does not apply if the K-Tap mechanism will be used to monitor local connections. The Tee is a non-kernel-based data collection mechanism that can be used as an alternative to K-Tap, and as such, requires the clients to explicitly connect to the Tee.
Do not perform this procedure until S-TAP has been installed on the DB2 server, and you are ready to start collecting data. For the local DB2 clients to use the Tee, you will create a database alias named tee, and the clients will change their login sequence to log into tee (instead of the DB2 server).
Log on to the database server system using an administrative account.
Locate the entry in the /etc/services file for the node name that clients use to connect to the database. Each entry in this file is in the following format:
node_name port_number/protocol [aliases]
For example:
db2inst1 50000/tcp # DB2 connection service port
Note the node name (db2inst1, in the example above) and the port number (50000). When you configure the inspection engine, this is the port number you will specify as the Tee Real Port.
Select an unused port number in the range of 1025-65535 for use by S-TAP. Search the /etc/services file for the selected port number to be certain that it is not used. When you configure the inspection engine, this is the port number you will specify as the Tee Listen Port.
Enter the db2 command to start the db2 command-line interface. To execute this command, you may need to add the command to the $PATH, or switch users to a db2 user on the system.
Enter the list node directory command to list all nodes defined. A very simple example is illustrated below:
db2 => list node directory
Node Directory
Number of entries in the directory = 2
Node 1 entry:
Node name = GACCTEST
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = merlin
Service name = 50000
Node 2 entry:
Node name = LOCGOOSE
Comment =
Directory entry type = LOCAL
Protocol = LOCAL
Instance name = db2inst1
Note that the /etc/services entry that we looked at previously related the instance name db2inst1 to the service name 50000.
Use the catalog command to create a node on the local server for the port to be assigned as the Tee Listen Port. For example, to define a node named localtee for port 12344 on the server named goose, we would enter the following command:
db2 => catalog tcpip node localtee remote goose server 12344
DB20000I The CATALOG TCPIP NODE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is refreshed.
Enter the terminate command to update the directory. (This closes the db2 utility.)
db2 => terminate
DB20000I The TERMINATE command completed successfully.
Restart the db2 utility using the db2 command, and then enter the list node directory command again to verify that the new node has been defined correctly. Continuing with our simple example, the new node now appears in the list:
db2 => list node directory
Node Directory
Number of entries in the directory = 3
Node 1 entry:
Node name = GACCTEST
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = merlin
Service name = 50000
Node 2 entry:
Node name = LOCALTEE
Comment =
Directory entry type = LOCAL
Protocol = TCPIP
Hostname = goose
Service name = 12344
Node 3 entry:
Node name = LOCGOOSE
Comment =
Directory entry type = LOCAL
Protocol = LOCAL
Instance name = db2inst1
Configure a database alias named tee for the database. In our example we will use a database named SAMPLE (replace this with the name of your database):
db2 => catalog database SAMPLE as tee at node localtee
DB20000I The CATALOG DATABASE command completed successfully.
DB21056W Directory changes may not be effective until the directory cache is
refreshed.
Enter the terminate command to update the directory. (This closes the db2 utility.)
db2 => terminate
DB20000I The TERMINATE command completed successfully.
Restart the db2 utility using the db2 command, and then enter the list database directory command to verify that the tee database alias has been defined correctly. Continuing with our simple example, the new database should appear in the list of databases (partial list only shown below):
db2 => list database directory
System Database Directory
Number of entries in the directory = 6
Database 1 entry:
...
Database 3 entry:
Database alias = DN0GOOSE
Database name = SAMPLE
Node name = DN0GOOSE
Database release level = a.00
Comment =
Directory entry type = Remote
Catalog database partition number = -1
Database 4 entry:
...
Database 5 entry:
Database alias = TEE
Database name = SAMPLE
Node name = LOCALTEE
Database release level = a.00
Comment =
Directory entry type = Remote
Catalog database partition number = -1
Enter the quit command to close the db2 utility:
db2 => quit
Do not log out of the database server system yet. After configuring an S-TAP inspection engine, you will enter one or more SQL commands using the DB2 command-line SQL utility to verify the alias connection.
When you are ready to start collecting data, from the administrator portal of the Guardium appliance that is the active host for the S-TAP, use the S-TAP Configuration panel to define a DB2 inspection engine to listen on the selected Tee Listen Port (12344 in the example), and forward messages to the Tee Real Port (50000 in the example). Be sure to set all other properties required for a DB2 inspection engine, as described elsewhere.
Use the DB2 command-line SQL utility, db2sql92, to verify that the database connection through the local tee process works correctly. Log in to the database from the command line using a command like the following (where db2inst1 is the database user name, passwd is the password, and tee is the database alias):
$ db2sql92 -a db2inst1/passwd -d tee
SQL authorization ID = DB2INST1
Local database alias = TEE
Running in Embedded Dynamic mode.
---------------------------------------------
Enter a command that you know will create an SQL exception (for example, select * from my_mistake), and then quit the session.
Log in to a user portal on the Guardium appliance, and navigate to the Reports & Alerts – Report Templates – Exceptions tab, and select the SQL Errors report. You should be able to locate your SQL error near the “top” of the report, and thus verify that the tee is seeing the Informix traffic.
Now modify all client logins to log into the tee alias (instead of the DB2 server)
This topic does not apply if the K-Tap mechanism will be used to monitor local connections. The Tee is a non-kernel-based data collection mechanism that can be used as an alternative to K-Tap, and as such, requires the clients to explicitly connect to the Tee.
Do not perform this procedure until S-TAP has been installed on the Informix server, and you are ready to start collecting data. For the local Informix clients to use the Tee, you will create an staptcp service name in the /etc/services file, create an stap_sqlhosts file, and modify several environment variables such that local Informix clients will connect to the Tee Listen Port instead of to the Informix server.
Locate the sqlhosts file. The default file name is sqlhosts, and by default it is located in the $INFORMIXDIR/etc/ directory. The default filename and location can be overridden using the INFORMIXSQLHOSTS environment variable, which when present, defines the full path name for the file.
Make a copy of the sqlhosts file and name it stap_sqlhosts. You will modify the copy. Do not modify the original sqlhosts file. There are no naming requirements for the file. We will use the name stap_sqlhosts for the remainder of this section.
Open the stap_sqlhosts file in a text editor.
Locate the entry that local clients use to connect to the database. Each entry contains several positional parameters, in the following format:
dbservername netptype hostname servicename [options]
For example:
jumboinformix onsoctcp jumbo nettcp
Note the servicename parameter value (nettcp in the example above). It identifies a servicename that maps to a port number for this database server, in the services file. You will use this name later to locate an entry in that file.
Replace the servicename specified with a new servicename for S-TAP. There are no naming requirements. We will use staptcp for our example. Continuing the example, the entry would be changed as follows:
jumboinformix onsoctcp jumbo staptcp
Save the stap_sqlhosts file.
Locate the services file. By default, it is in the /etc directory, but if Network Information Service (NIS) is used, you must edit the services file on the NIS server.
Make a backup copy of the file, and open the original for editing.
Locate the entry in the services file for the servicename that you replaced in the stap_sqlhosts file. Each entry in this file is in the following format:
servicename port_number/protocol [aliases]
In our example services file, the nettcp entry is defined as follows:
nettcp 1400/tcp
Note the port number (1400, in the example). When you configure the inspection engine, this is the port number you will specify as the Tee Real Port.
Select an unused port number in the range of 1025-65535 for use by S-TAP. Search the services file for the selected port number, to be certain that it is not used. In our example, we will use 12344. When you configure the inspection engine, this is the port number you will specify as the Tee Listen Port.
Add a line to the services file for S-Tap’s listening port, staptcp in the example:
staptcp 12344/tcp
Save the services file.
Set the environment variable INFORMIXSQLHOSTS, to specify the full path name for the cloned version of the sqlhosts file that you created earlier. For example:
setenv INFORMIXSQLHOSTS $INFORMIXDIR/etc/stap_sqlhosts
When you are ready to start collecting data, from the administrator portal of the Guardium appliance that is the active host for the S-TAP, use the S-TAP Configuration panel to define an Informix inspection engine to listen on the selected Tee Listen Port (12344 in the example), and forward messages to the Tee Real Port (1400 in the example).
You can use the dbaccess command to verify that client SQL requests are being seen by S-TAP. To use dbaccess, three environment variables must be set appropriately: INFORMIXDIR, INFORMIXSERVER, and INFORMIXSQLHOSTS. Verify that those variables are set correctly using the following command:
-bash-3.00# env | grep INFO
INFORMIXDIR=/data/informix
INFORMIXSERVER=jumboinformix
INFORMIXSQLHOSTS=/data/informix/etc/stap_sqlhosts
INFORMIXSERVER identifies the database server that we are trying to connect to (jumboinformix above).
INFORMIXSQLHOSTS identifies the sqlhosts file used to resolve connections to jumboinformix. During this resolution it will be either shared memory or a TCP connection. In our previous definition, it is a TCP connection with a service name of staptcp. This will connect to the correct TCP port of 12344 which is resolved in the /etc/services file.
Enter the dbaccess command.
Navigate to connection – connect – Select Database Server and select the database servername (jumboinformix in our example).
When prompted, enter an appropriate database user name and password.
Exit from the connection portion of the configuration and select Query-language – select database.
Select New and enter an SQL command, for example: select * from my_mistake.
Log in to a user portal on the Guardium appliance, and navigate to the Reports & Alerts – Report Templates – Exceptions tab, and select the SQL Errors report. You should be able to locate your SQL error near the “top” of the report, and thus verify that the tee is seeing the Informix traffic.
This topic does not apply if the K-Tap mechanism will be used to monitor local connections. The Tee is a non-kernel-based data collection mechanism that can be used as an alternative to K-Tap, and as such, requires the clients to explicitly connect to the Tee.
Do not perform this procedure until S-TAP has been installed on the Oracle server, and you are ready to start collecting data. Follow the procedure outlined below to modify the tnsnames.ora file, which maps service aliases to ports. Do not change this file until S-TAP has been installed and you are ready to start collecting data.
Make a backup copy of the tnsnames.ora file, which is located in the $ORACLE_HOME/network/admin directory.
Open the tnsnames.ora file for editing in a text editor program.
Locate the entry in this file for the service alias used to access the database. An entry named EAGLE10 on the EAGLE host is illustrated below:
EAGLE10 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = eagle)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = GUARD10))
)
Note the port number used (1521,
in the example). When you configure the inspection engine, this is the
port number you will specify as the Tee
Real Port.
Do not change the above entry until you have verified that S-TAP
is configured correctly.
Select an unused port number in the range of 1025-65535 for use by S-TAP. Search the file for the selected port number, to be certain that it is not used. In our example, we will use 12344. When you configure the inspection engine, this is the port number you will specify as the Tee Listen Port.
Create a duplicate entry for the service by copying and pasting the entry, and making the highlighted changes. We will name our duplicate LOCALTEE:
LOCALTEE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = eagle)(PORT = 12344)))
(CONNECT_DATA = (SERVICE_NAME = GUARD10))
)
Save the tnsnames.ora file.
When you are ready to start collecting data, from the administrator portal of the Guardium appliance that is the active host for the S-TAP, use the S-TAP Configuration panel to define an Oracle inspection engine to listen on the selected Tee Listen Port (12344 in the example), and forward messages to the Tee Real Port (1521 in the example).
Log on to the database server locally, using sqlplus to verify that S-TAP is configured properly and will see a local access. For example:
# sqlplus scott/tiger@LOCALTEE
Where scott is the database user name, tiger is the password, and LOCALTEE identifies the service.
Enter an invalid SQL command to create an SQL exception that will be easy to find. For example: select * from my_mistake
Log in to a user portal on the Guardium appliance, and navigate to the Reports & Alerts – Report Templates – Exceptions tab, and select the SQL Errors report. You should be able to locate your SQL error near the “top” of the report, and thus verify that the tee is seeing the local Oracle traffic.
Reopen the tnsnames.ora file and replace the database service port number with the selected number. Continuing our example, the EAGLE10 entry would be UPDATED as follows:
EAGLE10 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = eagle)(PORT = 12344)))
(CONNECT_DATA = (SERVICE_NAME = GUARD10))
)
Save the tnsnames.ora file. All local clients connecting to EAGLE10 will now connect to port 12344 (the Tee Listen Port) instead of the actual database port (the Tee Real Port).
This topic does not apply if the K-Tap mechanism will be used to monitor local connections. The Tee is a non-kernel-based data collection mechanism that can be used as an alternative to K-Tap, and as such, requires the clients to explicitly connect to the Tee.
Follow the procedure outlined below to modify local interfaces file, which maps servers to ports. Do not change this file until S-TAP has been installed and you are ready to start collecting data.
Make a backup copy of the interfaces file, which is located in the $SYBASE/ directory.
Open the interfaces file for editing in a text editor program.
Locate the entry in this file whose name matches the Sybase server name. For example, a server named parrot might be defined as follows:
parrot
master tcp ether parrot 4100
query tcp ether PARROT 4100
Note the port number (4100, in the example). When you configure the inspection engine, this is the port number you will specify as the Tee Real Port.
Select an unused port number in the range of 1025-65535 for use by S-TAP. Search the file for the selected port number, to be certain that it is not used. In our example, we will use 12344. When you configure the inspection engine, this is the port number you will specify as the Tee Listen Port.
Replace the port number with the selected number. For example:
parrot
master tcp ether parrot 12344
query tcp ether PARROT 12344
Save the interfaces file.
When you are ready to start collecting data, from the administrator portal of the Guardium appliance that is the active host for the S-TAP, use the S-TAP Configuration panel to define a Sybase inspection engine to listen on the selected Tee Listen Port (12344 in the example), and forward messages to the Tee Real Port (4100 in the example).
Follow this procedure to stop Unix S-TAP.
Log on to the database server system using the root account.
Open the /etc/inittab file for editing.
Locate and comment the following two statements in the /etc/inittab file, by inserting a comment character (colon (:) for AIX, pound sign (#) for all others) at the start of each statement:
utap:2345:respawn:/usr/local/guardium/guard_stap/guard_stap /usr/local/guardium/guard_stap/guard_tap.ini
cas:2345:respawn:/usr/local/guardium/guard_stap/cas/bin/run_wrapper.sh /usr/local/guardium/guard_stap/cas/bin
Optional. If you are using the TEE monitoring mechanism, comment the following two statements by inserting a comment character (colon (:) for AIX, pound sign (#) for all others) at the start of each statement. Note that these processes are not used in the default configuration, so the statements may be commented already.
#utee:2345:respawn:/usr/local/guardium/guard_stap/guard_tee /usr/local/guardium/guard_stap/guard_tap.ini
#hsof:2345:respawn:/usr/local/guardium/guard_stap/guard_hnt
Run the init q command to restart the S-TAP processes.
Run ps –ef | grep stap to verify that the S-TAP processes have been stopped.
From the administrator portal of the Guardium appliance to which this S-TAP was reporting, verify that the Status light in the S-TAP control panel is now red.
After stopping S-TAP on a Unix server, restart it by un-commenting either two or four statements in the /etc/inittab file, as described below.
Log on to the database server system using the root account.
Open the /etc/inittab file for editing.
Un-comment the following two statements by deleting the comment character (colon (:) for AIX, pound sign (#) for all others) at the start of each line:
#utap:2345:respawn:/usr/local/guardium/guard_stap/guard_stap /usr/local/guardium/guard_stap/guard_tap.ini
#cas:2345:respawn:/usr/local/guardium/guard_stap/cas/bin/run_wrapper.sh /usr/local/guardium/guard_stap/cas/bin
Optional. If you are using the TEE monitoring mechanism, un-comment the following two statements by deleting the comment character (colon (:) for AIX, pound sign (#) for all others) at the start of each line. Note that these processes are not used in the default configuration, and must not be started if you are using the K-Tap monitoring mechanism.
#utee:2345:respawn:/usr/local/guardium/guard_stap/guard_tee /usr/local/guardium/guard_stap/guard_tap.ini
#hsof:2345:respawn:/usr/local/guardium/guard_stap/guard_hnt
Run the init q command to restart the S-TAP processes.
Run ps –ef | grep stap to verify that S-TAP is running.
From the administrator portal of the Guardium appliance to which this S-TAP reports, verify that the Status light in the S-TAP control panel is green.
When installing an S-TAP or CAS agent on a database server system, it is useful to verify that there is connectivity between the two systems. On a Unix system, you can use the nmap command to check for connectivity, using the following options:
nmap –p <port> <ip_address>
To check that port 16018 (the port Guardium uses for TLS) is reachable at IP address 192.168.3.104, you would enter the following command:
> nmap -p 16018 192.168.3.104
Starting nmap V. 3.00
Interesting ports on g4.guardium.com (192.168.3.104):
Port State Service
16018/tcp open unknown
>
From the administrator portal of a Guardium server for an S-TAP, the S-TAP version number displays in the STAP Status Monitor report on the System View tab.
If the administrator portal is not available, you can display the S-TAP version number from the Unix command line of the database server, by running the guard_stap binary with the -version or --version argument. For version 7.0 or later, this displays the version number. For an S-TAP version prior to 7.0, the -version or --version argument will not be recognized. For example, assuming S-TAP has been installed in the default installation directory:
-bash-3.00# /usr/local/guardium/bin/guard_stap --version
STAP-7.0.0-20080523-1335
-bash-3.00#