Network mirroring methods (SPAN , N-TAP) and related inspection engines

This configuration is used in cases where an S-TAP® cannot be installed in the host where the database instances to be monitored are run. Instead, you can direct a copy of the network traffic that goes to the host running the database servers, to a Guardium collector. This method only captures network traffic, not local traffic within the database server host. The limitations are listed further on in this section. IBM strongly encorurages to use an S-TAP instead.

Port Mirroring: For network traffic, you can use port mirroring, which is mirroring through SPAN (Switched Port Analyzer) ports. This requires a network switch with port mirroring capability. Physical setup and configuration of the inspection engine is required for port mirroring.

Physical Setup: The LAN containing the desktop used for connecting to the Guardium collector GUI should be connected to the eth0 port on the Guardium collector appliance. The SPAN port from the network switch should be connected to the eth1 port of the Guardium collector appliance. You can also connect additional SPAN ports to the remaining ethernet ports of the Guardium appliance, in order. The network switch must then be configured to mirror all traffic to and from the databases to be monitored, to a port on which the appliance is connected. A network administrator should be able to perform this configuration. You may need to consult the switch vendor's documentation for the exact process for setting up this configuration.

Since all network traffic from the host is sent to the collector, there can be potentially a high amount of useless (non-DB related) traffic the collector has to check before deciding to ignore it.

The collector needs to have a separate port for the incoming traffic from SPAN/NTAP. The actual setup is beyond the scope of Guardium (and Guardium support). Your network administrators are responsible for configuring this solution. Once the mirrored traffic is directed to the collector, you need to define Inspection engines for each of the databases for which the traffic has been mirrored. Note that these inspection engine definitions are different from the definitions with the same name under S-TAP control.

The inspection engine extracts SQL from network packets; compiles parse trees that identify sentences, requests, commands, objects, and fields; and logs detailed information about that traffic to an internal database.

You can configure, start, and stop multiple inspection engines on the Guardium appliance. Inspection engines cannot be defined or run on a Central Manager unit. However, you can start and stop inspection engines on managed units from the Central Manager control panel.

Selecting IP addresses

Each inspection engine monitors traffic between one or more client and server IP addresses. In an inspection engine definition these are defined using an IP address and a mask. You can think of an IP address as a single location and a mask as a wild-card mechanism that allows you to define a range of IP addresses.

IP addresses have the format: n.n.n.n, where each n is an eight-bit number (called an octet) in the range 0-255.

For example, an IP address for your PC might be: 192.168.1.3. This address is used in the examples. Since these are binary numbers, the last octet (3) can be represented as: 00000011.

The mask is specified in the same format as the IP address: n.n.n.n. A zero in any bit position of the mask serves as a wildcard. Thus, the mask 255.255.255.240 combined with the IP address 192.168.1.3 matches all values from 0-15 in the last octet, since the value 240 in binary is 11110000. But it only matches the values 192.168.1 in the first three octets, since 255 is all 1s in binary (in other words, no wildcards apply for the first three octets).

Specifying binary masks can be a little confusing. However, for the sake of convenience, IP addresses are usually grouped in a hierarchical fashion, with all of the addresses in one category (desktop computers, for example) grouped together in one of the last two octets. Therefore, in practice, the numbers you see most often in masks are either 255 (no wildcard) or 0 (all).

Thus a mask 255.255.255.255 (which has no zero bits) identifies only the single address specified by IP address (192.168.1.3 in the example).

Alternatively, the mask 255.255.255.0, combined with the same IP address matches all IP addresses beginning with 192.168.1.

Selecting all addresses

The IP address 0.0.0.0, which is sometimes used to indicate all IP addresses, is not allowed by Guardium®. To select all IP addresses when using an IP address/mask combination, use any non-zero IP address followed by a mask containing all zeroes (for example: 1.1.1.1/0.0.0.0). However, 0.0.0.0/0.0.0.0 is a valid combination.

Configure Settings that apply to all Inspection Engines

  1. Go to Manage > Activity Monitoring > Inspection Engines to open the Inspection Engine Configuration.
  2. Refer to the table and make any changes desired.
  3. Click Apply to save the updated system configuration when you are done making changes.
  4. Optionally add comments to the configuration.
  5. Click Restart Inspection Engines.
Note: The applied changes do not take effect until the inspection engines are restarted. After applying inspection engine configuration changes, click Restart to stop and restart the system (using the new configuration settings).
Note: For HTTP support, there are inspection engine configuration limitations. The following inspection engine settings are not supported for HTTP: Default Capture Value; Default Mark Auto Commit; Log Sequencing; Log Exception Sql String; Log Records Affected; Compute Avg. Response Time; Inspect Returned Data; Record Empty Sessions.
Table 1. Settings that apply to all inspection engines
Control Description
Default Capture Value Default value is false. Used by Replay function to distinguish between transactions and capture values, meaning that if you have a prepared statement, assigned values will be captured and replayed. If you want to replay your captured  prepared statements as prepared statements the check box should be checked for the captured data.
Default Mark Auto Commit Default value is true. Due to various auto-commit models for different databases, this value is used by Replay function to explicitly mark up the transactions and auto commit after each command.
Note: If the check box is checked then commits and rollbacks will be ignored. Databases currently supported include DB2®, Informix®, and Oracle.
Log Sequencing If marked, a record is made of the immediately previous SQL statement, as well as the current SQL statement, provided that the previous construct occurs within a short enough time period.
Log Exception Sql String If marked, when exceptions are logged, the entire SQL statement is logged.
Log Records Affected Records affected - Result set of the number of records which are affected by each execution of SQL statements.
The records affected feature is not supported in:
  • DB2 when streaming is used to send the results.
  • AWS
  • Couchbase
  • Hadoop integration

If marked, the number of records affected is recorded for each SQL statement (when applicable). Default value for log records affected is FALSE (0).

Note: The records affected option is a sniffer operation which requires sniffer to process additional response packets and postpone logging of impacted data which increases the buffer size and might potentially have a adverse effect on overall sniffer performance. Significant impact comes from really large responses. To prevent large amount of overhead associated with this operation, Guardium uses a set of default thresholds that allows sniffer to decide to skip processing operation when exceeded.
Note: Usually, Records Affected is set correctly when the user turns on Log Records Affected via Inspection Engines > Log Records Affected. However using MS-SQL via stored procedure will set Records Affected as -1.

Refer to Configuration and Control CLI Commands store max_results_set_size, store max_result_set_packet_size and store max_tds_response_packets, to set levels of granularity.

Example of result set values:
  • Case 1, record affected value, positive number. This represents correct size of the result set.
  • Case 2, record affected value, -2. This means number of records exceeded configurable limit (This can be tuned through CLI commands).
  • Case 3, record affected value, -1. This shows any unsupported cases of packets configurations by Guardium.
  • Case 4, record affected value, -2. If the result set is sent by streaming mode.
  • Case 5, record affected value, less than -2. Intermediate result during record count to update user about current value, ends up with positive number of total records. For example, the server returns 1000 records in 4 packets:
    • Packet #1 250
    • Packet #2 200
    • Packet #3 250
    • Packet #4 200

    Then records affected are reported as

    • Packet #1 -250
    • Packet #2 -500
    • Packet #3 -750
    • Packet #4 1000
Compute Avg Response Time When marked, for each SQL construct logged, the average response time is computed.
Inspect Returned Data Mark to inspect data returned by SQL requests  as well as update the ingress and egress counts.

If rules are used in the security policy, this checkbox must be marked.

Record Empty Sessions When marked, sessions containing no SQL statements are logged. When cleared, these sessions are ignored.
Parse XML The Inspection Engine does not normally parse XML traffic. Mark this checkbox to parse XML traffic.
Logging Granularity The number of minutes (1, 2, 5, 10, 15, 30, or 60) in a logging unit. If requested in a report, Guardium summarizes request data at this granularity. For example, if the logging granularity is 60, a certain request occurred n times in a given hour. If the check box is not selected, exactly when the command occurred within the hour is not recorded. But, if a rule in a policy is triggered by a request, a real time alert can indicate the exact time. When you define exception rules for a policy, those rules can also apply to the logging unit. For example, you might want to ignore 5 login failures per hour, but send an alert on the sixth login failure.
Max. Hits per Returned Data When returned data is being inspected, indicate how many hits (policy rule violations) are to be recorded.
Ignored Ports List A list of ports to be ignored. Add values to this list if you know your database servers are processing non-database protocols, and you want Guardium to not waste cycles analyzing non-database traffic. For example, if you know the host on which your database resides also runs an HTTP server on port 80, you can add 80 to the ignored ports list, ensuring that Guardium does not process these streams. Separate multiple values with commas, and use a hyphen to specify an inclusive range of ports. For example: 101,105,110-223
Buffer Free: n % Display only. n is the percent of free buffer space available for the inspection engine process. This value is updated each time the window is refreshed. There is a single inspection engine process that drives all inspection engines. This is the buffer used by that process.
Restart Inspection Engines Click Restart Inspection Engines to stop and restart all inspection engines.
Add Comments Click Comment to add comments to the Inspection Engine Configuration.
Apply Click Apply to save the configuration.
Note: Any global changes made (and saved by using Apply) do not take effect until you restart the inspection engines. However, individual inspection engine attributes, such as exclude, sequence order, etc., take effect immediately.

Create an Inspection Engine

  1. Click Manage > Activity Monitoring > Inspection Engines to open Inspection Engines.
  2. Click Add Inspection Engine to expand the panel.
  3. Type a name in the Name box. It must be unique on the appliance. We recommend that you use only letters and numbers in the name, as the use of any special characters prevents working with this inspection engine via the CLI.
  4. From the Protocol box, select the protocol to be monitored, one of: DB2, Informix, MSSQL, Mysql, Oracle, Sybase.
  5. In the DB Client IP/Mask boxes, enter a list of clients (a client host from which the database connection was initiated) to be monitored (or excluded if the Exclude DB Client IP box is marked). The clients are identified by IP addresses and subnet masks. There are detailed instructions on how to use these fields in the overview.
    • Click the plus sign to add additional IP address and subnet mask.
    • Click the minus sign to remove the last IP address and subnet mask.
  6. In the DB Server IP/Mask boxes, enter a list of database servers (where a database sits) to be monitored. The servers are identified by IP addresses and subnet masks. There are detailed instructions on how to use these fields in the overview.
    • Click the plus sign to add additional IP address and subnet mask.
    • Click the minus sign to remove the last IP address and subnet mask.
  7. In the Port box, enter a single port or a range of ports over which traffic between the specified clients and database servers will be monitored. Most often, this should be a single port.
    Warning: Do not enter a wide range of ports, just to be certain that you have included the correct one! You may cause the inspection engine to bog down attempting to analyze traffic on ports that carry no database traffic or traffic that is of no interest for your environment.
  8. Mark the Active on startup box if this inspection engine should be started automatically on start-up.
  9. Mark the Exclude DB Client IP box if you want the inspection engine to monitor traffic from all clients except for those listed in the DB Client IP/Mask list. Be sure that you understand the difference between this and the Ignore protocol selection. This includes all traffic except for the from IP addresses. To ignore a specific set of clients without including all other clients, define a separate inspection engine for those clients and use the Ignore protocol.
  10. Click Add to save the definition.
  11. Reposition the inspection engine in the list of inspection engines. Filtering mechanisms defined in the inspection engines are executed in the order. If necessary, reposition the new inspection engine configuration, or any existing configurations, using the Up and/or Down buttons in the border of the definition.
  12. Click Start to start the inspection engine just configured. The Start button is replaced by a Stop button, once the engine has been started.

Start or Stop an Inspection Engine

Go to Manage > Activity Monitoring > Inspection Engines to open the Inspection Engines. To start an inspection engine, click Start. To stop an inspection engine, click Stop.

Remove an Inspection Engine

If you are no longer using an inspection engine, remove the definition, so that it is not restarted accidentally.

  1. Click Manage > Activity Monitoring > Inspection Engines to open the Inspection Engines.
  2. If the inspection engine to be removed has not been stopped, click Stop.
  3. To remove an inspection engine, click Delete.