Firewall and latency issues examples

If your site uses the Guardium® database firewall, you can encounter latency issues when Guardium reconnects. These examples show how to use session-level policies to prevent unwanted traffic.

In the following example, the application can automatically reconnect and restore a terminated session. In this case, a query that violates the rules is automatically sent at the begin of the session. Because the database firewall was too late, the violating query is sent to the database server.

In this example, the following steps occur within milliseconds:
  1. The session is put under a firewall watch as soon as the user is verified in the analyzer.
  2. The analyzer ends the session after the first query that contains the object CREDIT_CARD.
The following session-level policy addresses this issue:
  • Session level criteria:
    • Client IP address = 10.10.10.10
    • Client net mask = 255.255.255.0
    • Server IP address = 20.20.20.20
    • Database user = Hermione
    • Server port = 1521
  • Rule actions:
    1. S-GATE SESSION ATTACH
      • ATTACH
      • ATTACH ON REQUEST
    2. S-GATE SESSION TERMINATE ON REQUEST
      • Request type = SQL
      • Search prefix = SELECT
      • Search pattern = CREDIT_CARD

For the following example, Guardium attaches the session to the firewall for sessions when a database user tries to access database server objects for which they do not have permission. In this case, the Oracle database server issues error ORA-01031 – insufficient privileges.

Tip: Make sure that STAP_FIREWALL_DEFAULT_STATE (Linux®-UNIX) or Firewall default state (Windows) S-TAP parameter is set to 2 to help prevent a security hole. If STAP_FIREWALL_DEFAULT_STATE is set to 0 or 1, database clients that are not authorized by the security system database client can create database server sessions. A user can issue an SQL statement and the firewall reacts only after the first SQL statement (when a database session is already created).
The following session-level policy uses two rules to address this issue.
  • Rule 1: Session level criteria
    • Server IP address = 20.20.20.20
    • Database user = Bellatrix
    • Server port = 1521
  • Rule action = S-GATE SESSION ATTACH
    • Request type = SQL ERROR
    • Search prefix = ORA-01031
  • Rule 2: Session level criteria
    • Server IP address = 25.25.25.25
    • Server port = 9160
  • Rule action = S-GATE SESSION ATTACH ON REQUEST
    • Request type = RPC
    • Search prefix = LOGIN
    • Match pattern = ^.*bella.*$

SR language example

Example 1:
SR_POLICIES
{
        IF (CLIENT_IP = '10.10.10.10' CLIENT_NET_MASK = '255.255.255.0' SERVER_IP = '20.20.20.20' SERVER_PORT = 1521 DB_USER = 'Bellatrix' )
        {
                VERDICT_ATTACH
                VERDICT_TERMINATE REQ_TYPE = SQL SEARCH_PREFIX = 'SELECT' SEARCH_PATTERN = 'CREDIT_CARD'
        }
}
Example 2:
SR_POLICIES
{
        IF (SERVER_IP = '9.70.145.22' SERVER_PORT = 1521 DB_USER = 'SCOTT' )
        {
                VERDICT_ATTACH REQ_TYPE = SQL_ERROR SEARCH_PREFIX = 'ORA-01031' 
        }
}