2 Network-Based SQL Traffic Monitoring with Database Firewall

It’s impractical to audit every operation in a database, so a solution focused only on auditing can’t see the bigger picture of all database activity needed to identify anomalies, help identify suspicious activity, and block if any unauthorized activity is happening on your enterprise database.

Database Firewall is a multistage firewall that inspects SQL traffic going into the database and determines with high precision whether to allow, log, alert, substitute, or block the SQL. The SQL traffic goes through multiple stages including checks for the IP address, database or OS user, program name, SQL statement category, such as data definition language (DDL) and data manipulation language (DML), and database tables being accessed. It blocks and alerts both deny-listed SQL and SQL that is not in the allowed set of allowlist SQL statements, helping prevent SQL injection attacks.

Successful deployment of the Database Firewall depends on deciding an effective firewall policy and selecting the appropriate firewall deployment as described below.

2.1 Developing an Effective Firewall Policy

Prior to deciding the policies, you need to consider who are the actors, what actions they can perform, and what actions you want the firewall to take when that action happens. Based on this, you can create the firewall policy to implement this behavior.

How Policies Are Executed in the Database Firewall: Database Firewall evaluates the SQL statement, and at each stage of the firewall, if there is a match, then the actions as specified at that stage are executed, otherwise, the SQL statement is passed on to the next stage for evaluation.

The firewall policy consists of one or more rules such as Session Context rule, SQL Statement rule, Database Object rule and Default policy rule, and are evaluated in the following order:

Figure 2-1 Order of Execution of Rules

Description of "Figure 2-1 Order of Execution of Rules"

1. Session Context Rule

   Session Context provides a means of allowing or denying a SQL statement based on sets of sessions attributes, without looking at the specific SQL statement. Session Context rules override all other policy rules. This rule does not look at the structure of the SQL statement, but uses database session attributes such as IP address, database users, OS users and database clients as actors to make a decision.

   Session Context rules can be used to allow specific traffic from trusted application paths without requiring them to go through further processing in the Database Firewall policy engine. Typical use-case includes:

   • Allow SQL requests from a trusted set of allow-listed client IPs to be executed by the database.
   • Allow SQL requests from trusted set of application users to be executed by the database Combining multiple sets, such IP with database user or IP with OS user, provides flexibility in narrowing down the permitted traffic through the Database Firewall. Actions can be taken on any SQL traffic, which matches the condition defined by a combination of these session attributes, such as, blocking, alerting, or logging. In the case of alerts, the threat severity level can be specified. This is explained in detail in the section below titled Actions Taken When SQL Statement Matches the Policy. SQL statements that do not match the specified conditions are forward to the next stage of the firewall for execution, namely, the SQL statement rule.
2. SQL Statement Rule

   The next stage of the Database Firewall uses a SQL grammar based engine to parse the SQL statement and take actions as specified in the policy. It groups SQL statements with the same grammatical structure into clusters. For example, a SQL query that searches for a specific order number 234324 is essentially the same as the one that searches for another order number 333221. Understanding the similarity between different statements, the Database Firewall can take a policy and apply it to hundreds of equivalent SQL statements.

   The Database Firewall can be trained to take a set of SQL statements and group them into similar clusters. Groups of clusters are referred to as SQL cluster sets and are useful in creating policies. SQL cluster sets provides the flexibility to group the clusters so that you can enforce policy rules on them.

   SQL statement rule combines SQL cluster set, and profile, which is defined as a combination of database session attributes such as IP address, database users, OS users, and database clients.

   SQL Statement rules can be used to allow SQL traffic from trusted application paths to be executed by the database. Allow-lists of normal behavior could be created by running the Database Firewall in training mode where it logs unique SQL statements and captures a set of expected SQLs representing normal traffic, such as the set of SQLs generated in a test or QA system. These groups of SQLs, called SQL Clusters, can be used in creating the policies. Typical use-case include:

   • Allow allow-listed application SQL requests from a trusted set of application users.
   • Allow specific allow-listed SQL requests from trusted set of privileged users accessing using a tool such as Oracle SQL Developer.

   Actions that can be taken when a SQL statement matches the SQL statement rule are the same as that mentioned above for the Session context rule. It is explained in the section below titled Actions Taken When SQL Statement Matches the Policy. SQL traffic that does not match is sent to the next stage for processing, namely, the Database Object based rule.

3. Database Object Based Rules

   Database Object based rules are used to prevent or allow specific types of SQL statements such as DML and DCL, on specific database objects such as tables and views. These rules are often used for controlling behavior of privileged users over the network where it might be necessary to stop them from accessing specific sensitive application database objects.

   Typical use cases include:

   • Allow only SELECT on application tables but alert or block if there are attempts to perform data modification on sensitive application tables.
   • Alert on any data modification attempts over the network that has not been allow-listed in the SQL statement rule. Actions that can be taken when a SQL statement matches the Database Object Based rule are the same as that mentioned above for the Session context rule. It is explained in the section below titled Actions Taken When SQL Statement Matches the Policy. SQL traffic that does not match is sent to the next stage for processing, namely, the Default rule.
   • Identify potential data exfiltration attempts by monitoring and alerting on the number of rows returned by the database in response to SQL SELECT queries (starting from Oracle AVDF 20.3).

   Monitoring the behavior of privileged users over the network and preventing them from accessing sensitive application database objects they are not authorized to access. For example, allowing only SELECT query on application tables, and block the SQL modifying sensitive application tables. This can be achieved using the Database Object rule. This is used to block or allow specific types of SQL statements (DML, DDL, etc.) on specific database objects such as tables and views.

   In addition to monitoring access to specific sensitive tables by privileged users, Database Firewall can be used to identify exfiltration attempts by capturing the number of rows returned (starting Oracle AVDF 20.3) and used for configuring alerts. For example, if the number of returned rows exceed a threshold on a specific sensitive table, an alert can be generated. Additionally, the returned row count can be used in reports for forensic analysis.

   Note:

   Profiles for Database Object rule in Database Firewall policy is introduced starting Oracle AVDF 20.4.
4. Default Rule

   The Default rule is executed if the SQL statement does not match any of the other rules defined, that is, session context, SQL statement, or database object. In this case, the actions specified, logging level, and threat severity are applied to this SQL statement similar to what is mentioned for the other policies and explained in detail below.

Actions Taken When SQL Statement Matches the Policy

Each of the above Firewall policy rule defines an action to be taken by the Database Firewall in case the conditions defined by the policy match. Action taken on SQL statements can be summarized as follows:

1. Action:
   • Pass: In this case, the SQL statement is passed on to the target for processing.
   • Alert: The SQL statement is sent to the Audit Vault Server as an alert, with the specified threat severity.
   • Block: The SQL statement is blocked, and the user can specify a substitute statement to execute against the target.
2. Logging level: This information is sent to the Audit Vault Server. Specifies whether or not to log the event and forward it to the Audit Vault Server.
3. Threat Severity: Threat level assigned to the Warning Database Firewall policy is essentially a multistage filtering mechanism formed by a combination of rules such as Session Context, SQL Statement, Database Object and Default rules. In each rule, you define conditions, and action to take when the SQL traffic matches that condition.

2.2 Choosing the Firewall Deployment

As part of defining the policy, you also need to decide if you want to only monitor and record the SQL statement or block it as well. Depending on that choice, you have three deployment modes, Monitoring/Blocking(Proxy), Monitoring (Host Monitor), or Monitoring (Out-of-Band).

See the below image and the following description to learn more about the different deployment modes.

Figure 2-2 Oracle AVDF Database Firewall Deployment Methods

Description of "Figure 2-2 Oracle AVDF Database Firewall Deployment Methods"

1. Monitoring and Blocking in Proxy Mode

   In this mode, the Database Firewall can both monitor and block SQL, as well as optionally substitute SQL statements. Database Firewall is configured as a proxy, so that all the traffic to the database server is routed through the Database Firewall. Database clients connect to the database firewall proxy that in turn connects to the database server, forwarding all data received from the database client. In all cases, the database server identifies the database firewall as the client.

   The clients must be reconfigured to connect to the database firewall instead of the database so that the firewall can intercept all traffic and based on the policies defined, take the necessary actions. Oracle recommends that you configure the database to reject all connections that do not come from the Database Firewall to ensure that all traffic can be routed via the firewall and policies can be applied to the SQL before it is executed in the database.

   To simplify the modification required for applications to connect to the database firewall proxy mode deployments, configure local domain name servers (DNS) to resolve fully qualified domain name of the target database to the IP address of the database firewall.

   If you want to only monitor the SQL traffic, you have two other choices of deployment: Out-of-band or Host Monitor.

2. Monitoring with Host Monitor

   Host Monitor captures SQL traffic going to the database by monitoring and capturing traffic received by the network interface card on the database. This helps to capture relevant traffic as compared to capturing all the network traffic from an out-of-band, that is, span port, technology. The Host Monitor gets a copy of SQL traffic and hence it can only monitor and cannot block them. This SQL event data is securely sent over the network to a database firewall. The data is then available for reports generated by Oracle AVDF.

   Host monitoring is designed for situations where network reconfiguration required for out-of-band deployment mode is ruled out due to complexity.

3. Monitoring in Out-of-Band Mode

   When you configure database activity monitoring in out-of-band mode, the database firewall listens to the network traffic, including client requests to the database and the response from the database. The database activity is monitored as per the defined policy. There are several technologies that can be used to send a copy of the database traffic to the database firewall. These technologies include, but are not limited to, span ports, network taps, and using packet replicators.

   In this mode, Oracle Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements. The out-of-band monitoring mode is the simplest deployment mode for a non-blocking policy requirement. There is no additional load on the database or the clients. There is no latency or single point of failure introduced by the Database Firewall.

2.3 Summary

Deploying the Database Firewall requires two steps:

• Deciding whether you want to only monitor and record the SQL, or monitor and block the SQL, then based on that you need to decide how you can deploy the firewall – proxy mode, out-of-band, or host monitor.
• Deciding the Database Firewall policy that will help you define the multi-stage filtering rule for SQL traffic over the network. What rules you want, and when the rule is satisfied, what actions you want the database firewall to take.