An inspection engine monitors the traffic between a set of one or more servers and a set of one or more clients using a specific database protocol (Oracle or Sybase, for example). 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 and start or 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. See Central Management for more information.
Inspection engines are also defined on S-TAPs. If S-TAPs report to this Guardium appliance, be sure the appliance does not monitor the same traffic as the S-TAP. If that happens, the analysis engine will receive duplicate packets, will be unable to reconstruct messages, and will ignore that traffic.
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 below. 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 above).
Alternatively, the mask 255.255.255.0, combined with the same IP address matches all IP addresses beginning with 192.168.1.
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).
Select Administration Console > Inspection Engines.
Referring to the table below, make any changes desired.
Click the Apply button to save the updated system configuration when you are done making changes.
Optionally add comments to the Inspection Engine Configuration. See Comments.
Click the Restart Inspection Engines button.
Note: The applied changes do not take effect until the inspection engines are restarted. After applying inspection engine configuration changes, click the Restart button to stop and restart the system (using the new configuration settings).
Control |
Description |
Log Request Sql String |
If marked, each SQL request statement is logged in its sanitized format. Otherwise, no statements are logged. |
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 |
If marked, the number of records affected is recorded for each SQL statement (when applicable) |
Log timestamp per second |
If marked, allows you to display the distribution of requests down to the second, regardless of the default logging granularity (see below). |
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 above check box is not marked, 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. |
Inspect Returned Data |
Mark to inspect data returned by SQL requests. If extrusion rules will be used in the security policy, this checkbox must be marked. |
Max. Hits per Returned Data |
When returned data is being inspected, indicate how many hits (policy rule violations) are to be recorded. |
Compute Avg Response Time |
When marked, for each SQL construct logged, the average response time will be computed. |
Record Empty Sessions |
When marked, sessions containing no SQL statements will be logged. When cleared, these sessions will be ignored. |
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. |
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 will 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 |
Restart Inspection Engines |
Click the Restart Inspection Engines button to stop and restart all inspection engines. |
Comment |
Click the Comment button to add comments to the Inspection Engine Configuration. See Comments. |
Apply |
Click the Apply button to save the configuration. Note: Any global changes made (and saved using the Apply button) do not take effect until you restart the inspection engines. However, individual inspection engine attributes, such as exclude, sequence order, etc., take effect immediately. |
Select Administration Console > Inspection Engines.
Click the Add Inspection Engine link to expand the Add panel.
Enter 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.
From the Protocol box, select either the protocol to be monitored (FTP, Informix, Teradata, DB2, Sybase, MSSQL, Named Pipes, MySQL, Windows File Share, or Oracle) or the keyword Ignore. Select Ignore if you want all traffic between the specified clients and servers to be ignored.
Mark the Active on startup box if this inspection engine should be started automatically on start-up.
Mark the Exclude From-IP box if you want the inspection engine to monitor traffic from all clients except for those listed in the From-IP/Mask list (see below). Be sure that you understand the difference between this and the Ignore protocol selection (above). This includes all traffic except for the from IP addresses specified below. 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 (see above).
In the From-IP/Mask
boxes, enter a list of clients to be monitored (or excluded if the Exclude
From-IP box is marked, as described above). The clients are identified
by IP addresses and subnet masks. There are detailed instructions on how
to use these fields in the overview, above.
Click to add
an IP address and subnet mask. Click to remove the last IP address and subnet mask (at the
bottom of the list).
In the Ports 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 right 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.
Click the Add button to save the definition.
Optionally 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.
Optionally click the Start button to start the inspection engine just configured. The Start button will be replaced by a Stop button, once the engine has been started.
Select Administration Console > Inspection Engines.
To start an inspection engine, click it's Start button.
To stop an inspection engine, click it's Stop button.
Note: If using Central Management, you can also start or stop inspection engines from the Central Management control panel. See Central Management.
If you are no longer using an inspection engine, we suggest that you remove the definition, so that it is not restarted accidentally.
Select Administration Console > Inspection Engines.
If the inspection engine to be removed has not been stopped, click the Stop button.
To remove an inspection engine, click it's Remove button.