4 Database Firewall Deployment

Topics

• Introduction to Oracle Database Firewall Deployment

• Planning the Protection Level for Your Databases

• Understanding Oracle Database Firewall Policies

• Planning and Rolling Out the Database Firewall

4.1 Planning the Protection Level for Your Databases

To meet your protection level requirements, you can deploy Oracle Database Firewall in monitoring only mode, or monitoring and blocking mode.

Depending on your operational needs you can deploy Oracle Database Firewall in one of two modes:

• Monitoring only: In this mode, Oracle Database Firewall only monitors SQL traffic to the target database, and cannot block any SQL statements.

• Monitoring and blocking: In this mode, Oracle Database Firewall both monitors SQL traffic to the target database, and can block any SQL statements, based on the defined policy. In this mode, Oracle Database Firewall is inline with the traffic reaching the target database.

4.2 Overview of Oracle Database Firewall Deployment

Learn about the types of deployments available for Oracle Database Firewall.

• Introduction to Oracle Database Firewall Deployment
• In-line (bridge)
• Proxy
• Out-of-Band
• Host Monitor

4.2.1 Introduction to Oracle Database Firewall Deployment

Depending on your requirements, you can choose from one of three types of deployments available for Oracle Database Firewall.

To monitor SQL traffic and restrict SQL statements reaching the target databases:

• Place the database firewall inline with your database traffic on the network (between the database and its clients)
• Configure the database firewall
• Create and deploy a policy that includes blocking, and optionally substituting SQL statements

Table 4-1 Oracle Database Firewall Deployment Types

Deployment Type	Supported Modes	Minimum Number of Network Interface Cards (NICs)
Proxy	DPE	3 (for deployment with network separation) 1 (for deployment without network separation)
Out-of-Band	DAM	2
Host Monitor	DAM	1

The same database firewall can monitor traffic from multiple Host Monitors, and at the same time be a proxy for some databases, and out-of-band (span) for some databases.

Note:

• A single network interface card (NIC) is required in case the client and database are on the same sub-network. There is no network separation.
• You can require additional NICs in case the client and databases are on different sub-networks.

4.2.2 In-line (bridge)

Learn about features of the in-line (bridge) mode of Oracle Database Firewall.

Note:

In-line bridge mode is deprecated in release 12.2.0.8.0, and can be desupported in a future release. Oracle recommends that you use Proxy mode instead. Proxy mode provides equivalent network security deployment features.

In this mode, Oracle Database Firewall:

• Is placed in-line with the traffic traveling between the client and the target database
• Can monitor, block SQL statements, and optionally substitute SQL statements
• Is deployed as a network bridge, which is inserted into the network in a segment between database clients and the databases that are secured
• Intercepts the traffic destined for the IP addresses and ports of the configured targets
• Intercepts traffic, analyzes the same, makes an explicit outbound connection to the database server, and forwards all the received data
• Is identified as the as the client by the database server

This in-line bridge architecture requires no configuration changes to database clients, applications, or to the database itself. It can require a configuration change of the network topology.

Figure 4-1 In-line Bridge

Description of "Figure 4-1 In-line Bridge"

The image illustrates deployment under In-line Bridge mode for Oracle Database Firewall, which is indicated by DBFW in the illustration. The callouts in the image indicate the following:

• A: The clients connect to the database firewall component through the switch. The clients are not aware of the database firewall deployed on the network. It appears that they are connected to the database. However, they are actually connected to the database firewall. The traffic from the database servers travels back over the bridge to the switch and later directed into the wider network. The database firewall makes an explicit outbound connection to the target database. The database firewall may require static routing to be applied to the bridge so that it can route back the client connection.
• B: The bridge physically separates the network segments between the database firewall traffic source and the switch.
• C: The extracted SQL data from the client traffic is analyzed and sent to Oracle Audit Vault Server based on the database firewall policy.

4.2.3 Proxy

Learn about how to configure Oracle Database Firewall in Proxy mode.

In proxy mode, Oracle Database Firewall can both monitor and block SQL, as well as optionally substitute SQL statements. In scenarios where it is difficult to add a network bridge, or if the database servers are in remote places, Oracle 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. Oracle recommends that you configure the database to reject all connections that do not come from the database firewall.

Note:

To simplify the modification required for applications to connect to the database firewall deployments through proxy, configure local domain name servers (DNS) in a way that the target fully qualified domain name (FQDN) resolves to the IP address of the database firewall.

You can deploy the proxy mode in the following two ways:

1. Without network separation (Proxy Without Network Separation mode)
2. With network separation (Proxy With Network Separation mode)

The Proxy Without Network Separation mode has the client and database on the same sub-network. In this mode, Oracle Database Firewall allows clients to connect through the database firewall. It also allows the clients to connect to the database directly, without a single point of failure.

Figure 4-2 Proxy Without Network Separation

Description of "Figure 4-2 Proxy Without Network Separation"

The image illustrates Oracle Database Firewall deployment in proxy mode without network separation. The callouts or pointers in the image indicate the following:

• A: The clients in the Client Network make an explicit connection to the database firewall directly.
• B: The clients in the Database Network also connect to the database firewall directly.
• C: The extracted SQL data from the client traffic is analyzed and sent to Oracle Audit Vault Server, based on the database firewall policy.

With the Proxy With Network Separation mode, the client and database are on different subnets. Additional network interface cards (NICs) are required for every additional subnet deployed.

Figure 4-3 Proxy With Network Separation

Description of "Figure 4-3 Proxy With Network Separation"

The image illustrates Oracle Database Firewall deployment in proxy mode with network separation. The callouts or pointers in the image indicate the following:

• A: The clients connect to the database firewall traffic proxy through the network router.
• B: The clients in the database network also connect to the database firewall directly.
• C: The extracted SQL data from the client traffic is analyzed and sent to Oracle Audit Vault Server, based on the database firewall policy.
• D: The traffic is forwarded to the target database by the database firewall. The response from target database reaches the originator through the network router. The response from the database is returned to the database firewall.
• E: The management network is separate from the client and database networks.

4.2.4 Out-of-Band

Learn about how to configure Oracle Database Firewall in the Out-of-Band mode.

When you configure database activity monitoring in Out-of-Band mode, the database firewall intercepts 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 copy database traffic to the database firewall. These technologies include (but are not limited to) spanning 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 mode is the simplest deployment mode overall 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. Oracle Audit Vault and Database Firewall supports high availability in this deployment mode.

Figure 4-4 Out-of-Band Mode

Description of "Figure 4-4 Out-of-Band Mode"

The image illustrates deployment of the database firewall component in Out-of-Band mode. The callouts in the image indicate the following:

• A: The Oracle Database Firewall interface is plugged into a span port on the switch.
• B: Oracle Database Firewall monitors the SQL traffic received.
• C: The extracted SQL data from the client traffic is analyzed and sent to Oracle Audit Vault Server, based on database firewall policy.

4.2.5 Host Monitor

Learn about how to configure the Host Monitor mode of Oracle Audit Vault Agent with Oracle Database Firewall.

To use the Host Monitor deployment mode with Oracle Database Firewall, an Oracle Audit Vault Agent must be placed on the host server, and configured to monitor network traffic to and from the database, as this traffic comes across the network interface card. Host Monitor then securely forwards the network traffic to the database firewall.

Oracle Database Firewall supports an Oracle Audit Vault Agent that only monitors and is deployed by the Oracle Audit Vault Server. This deployment option provides more flexibility in terms of monitoring at the network point. Using the Host Monitor mode is helpful in situations where it is not easy to use any of the previously described Oracle Audit Vault and Database Firewall networking options.

Caution:

Host Monitor on Microsoft Windows platforms is not certified in release 12.2.0.11.0. Upgrade or use 12.2.0.11.0 only when you are sure that network trail monitoring functionality on Microsoft Windows platform is not required. This functionality can be certified in a future release. If your installation is pertaining to any of the older releases before 12.2.0.11.0, then Host Monitor functionality on Microsoft Windows platform is certified.

Host Monitor mode performs the following actions:

• Captures the SQL traffic of the target database
• Leaves unmonitored the traffic from local clients on the same host
• Forwards the data securely to Database Firewall

In this deployment mode, Oracle Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements.

Figure 4-5 Host Monitor Mode

Description of "Figure 4-5 Host Monitor Mode"

The image illustrates deployment of Oracle Database Firewall in Host Monitor mode. The callouts or pointers in the image indicate the following:

• A: The Host Monitor agent records the traffic in between the client and the database over a network interface. The data is then forwarded securely to the database firewall for monitoring.
• B: The extracted SQL data from the client traffic is analyzed and sent to Oracle Audit Vault Server, based on the database firewall policy.

4.3 Understanding Oracle Database Firewall Policies

• Introduction to Oracle Database Firewall Policies

• Components of an Oracle Database Firewall Policy

• Flow of SQL Through a Database Firewall Policy

• How Oracle Database Firewall Handles Unauthorized SQL

4.3.1 Introduction to Oracle Database Firewall Policies

Learn how to define the parts of the Oracle Database Firewall policy for Oracle Audit Vault and Database Firewall.

To understand configuring the database firewall policies for Oracle Database Firewall, it is helpful to understand the terms allowlist and blocklist. Though you will not see the terms allowlist or blocklist in the Oracle Audit Vault and Database Firewall user interface when you are creating Oracle Database Firewall policy, these concepts are useful as you define the parts of Oracle Database Firewall policy.

A blocklist policy specifies a set of harmful statements that are disallowed. It also provides information about the various parameters and properties attached to the statements such as the incoming IP address, user name, and so on. Most monitoring solutions on the market today rely on regular expressions within their policies to determine which SQL statements should be blocked from reaching the database. The challenge with these first-generation solutions is that regular expressions do not match the expressive power of the SQL language. Because there are many different ways to write a SQL statement that will have some harmful effect, it is nearly impossible to write a regular expression rule that will detect all such statements. You can benefit from a blocklist by using it to define policies that disallow certain SQL statements based on the type of statement, the database object it acts upon, or session information such as IP addresses, user names, or client application names.

Because the set of harmful statements does not remain constant, instead of blocking a fixed set of “bad" statements, it is much more effective to allow only “good" statements, which are based on the normal activity of the applications, and the users that connect to the database. This set of good statements is a allowlist. To set up a allowlist policy, create a policy that monitors “normal" user behavior.

Oracle Database Firewall policies focus on the positive enforcement model of allowlists. However, a firewall policy can also support blocklists in the sense that you can use various elements of a firewall policy to disallow specific SQL statements.

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide for detailed information on creating Database Firewall policies.

4.3.2 Components of an Oracle Database Firewall Policy

• Exception Rules

• Analyzed SQL

• Session Profiles

• Novelty Policies

• Default Rule

4.3.2.1 Exception Rules

Exception rules (also called preconditions) within a firewall policy evaluate various factors before analyzing SQL statements.

Exceptions evaluate these session factors:

• Database or operating system users
• Application IP addresses
• Application program names

For example, you can use an exception to block a set of client applications from accessing the database, except if the request is from a specific set of users. You can also use an exception to enable a specific remote administrator, coming from a predetermined IP address, to diagnose a particular application performance issue. without being bound by the rules for "normal" SQL set in the firewall policy.

As these examples show, exceptions can be seen either in terms of a allowlist or a blocklist, depending on how you define the exceptions. For blocklists, you also can disallow clusters, based on the user, or on the IP address.

4.3.2.2 Analyzed SQL

Learn about how to apply policies on clusters of analyzed SQL using Oracle Database Firewall.

Oracle Database Firewall automatically analyzes the SQL traffic to a database, and groups the SQL into similar statements, known as clusters. With these clusters of analyzed SQL, you can then use a simple policy manager user interface to quickly set up allowlists of normal behavior for the same type of SQL interaction. To set up these normal behavior allowlists, you set an appropriate action for each cluster. For example, in the Analyzed SQL part of a firewall policy, you can set the actions Warn or Block. In this way, you build a set of rules for different kinds of SQL statements in your firewall policy.

You can also use a blocklist policy for analyzed SQL by disallowing specific clusters of SQL in your policy.

4.3.2.3 Session Profiles

As with exceptions, session profiles in firewall policies evaluate session information before analyzing SQL statements.

You can define session profiles using the following information:

• Application IP addresses
• Application program names
• Database or operating system users

Session profiles differ from exceptions:

• An exception lets you bypass all the rules for analyzed SQL in your normal policy.
• A profile lets you define rules for any cluster of SQL in the analyzed SQL, based on the session factors.

For example: You can have different rules for the same SQL cluster if the cluster originates from a specific set of users, or specific IP addresses.

You can define several session profiles within a single firewall policy. By evaluating session information first, the policy lets you define different rules for the same analyzed SQL, depending on the session information. Session information includes client IP addresses, database user names, operating system user names, or database client names.

As with exceptions, you can define session profiles either in terms of a allowlist or a blocklist, depending on how you decide to define your rules.

4.3.2.4 Novelty Policies

To prevent or allow specific types of SQL statements acting on specific database tables, you can set novelty policies within a firewall policy.

\Novelty rules are often used for controlling behavior of DBAs over the network where it might be necessary to stop them from accessing specific application tables.

A novelty rule can be specified to act on the following categories of SQL:

• Data Manipulation: Statements such as INSERT, UPDATE, DELETE, SELECT INTO, and so on
• Data Manipulation Read-Only: SELECT
• Procedural: Stored procedures, or remote procedure call (RPC) commands
• Data Definition: Statements such as CREATE, DROP, ALTER, and so on
• Data Control Language: Statements such as GRANT, REVOKE, and so on
• Composite: commands that are executed in a transaction
• Transaction Control Language (TCL): COMMIT, ROLLBACK, and so on
• Composite with Transaction: a data manipulation language (DML) statement with a transaction control language (TCL) command, and so on

By combining SQL categories with specific tables, novelty rules enable you to define policy behavior for the entire classes of tables.

The database dictionary tables are not related to the application, and are not part of these rules.

As with other parts of a firewall policy, you can define novelty policies either in terms of a allowlist or a blocklist, depending on how you define the rules for the policies.

4.3.2.5 Default Rule

Learn about the default rule that Oracle Database Firewall can apply in a firewall policy.

The default rule in a firewall policy covers any remaining SQL that does not match any of the other policy rules that you define for a policy, such as rules for SQL statements, database objects, and so on. The default rule specifies the action that the database firewall applies for SQL that is not addressed in the allowlist or blocklist rules that you specify in your policy.

4.3.3 Flow of SQL Through a Database Firewall Policy

There are four categories of SQL analysis that Oracle Audit Vault and Database Firewall performs using the firewall policy.

SQL statements are evaluated in logical groups through Oracle Database Firewall instances using the following rules, in order of their application:

• Exceptions

  Exceptions to the policy are evaluated first. For example, if an exception says "apply the rules for analyzed SQL, except if the request is from this administrator," that rule is considered first.

• Session Profiles

  Session profiles are considered next. Depending on the session information (for example, the request is coming from a specific set of IP addresses), the policy applies the set of rules for analyzed SQL for that session profile.

• Clusters

  Clusters of SQL statements are identified, and matched with the rules defined for Analyzed SQL clusters.

• Novelty Policies

  The rules that you define for database objects are considered next for a possible rule match. These policies look at which database tables are accessed, and what type of SQL statement is used to access them.

• Default Rule

  The default rule is applied to any remaining SQL that does not match any of the above rules, so that you can set a standard policy for SQL.

The diagram below shows the order in which SQL statements are evaluated using the firewall policy. You can configure all rules or a subset of the rules.

Figure 4-6 Flow of SQL Through a Firewall Policy

Description of "Figure 4-6 Flow of SQL Through a Firewall Policy"

Oracle Database Firewall monitors incoming SQL to the database, and applies the firewall policy assigned to the database in the descending order shown in the illustration. When SQL matches a rule in the firewall policy, Oracle Database Firewall takes the action defined in the policy.

4.3.4 How Oracle Database Firewall Handles Unauthorized SQL

You can configure four types of responses when Oracle Database Firewall identifies unauthorized SQL.

When Oracle Database Firewall finds an unauthorized statement, it can handle the statement in one or more of the following ways, based on the firewall policy that you define:

• Alert

  Raise an alert on all out-of-policy SQL statements.

• Block

  Block the SQL statement. When you define a block policy for a SQL statement, this specific statement is stopped from reaching the database server. When a statement is blocked, you can set the following actions in the firewall policy:

  • Do nothing after blocking the statement.

    When you set no response after the block, the client connection appears to hang, and the client has to terminate the session and reconnect to the database to execute more SQL.

  • Substitute (preferred)

    When you set a substitute policy, you provide a substitute statement for the blocked SQL statement: You replace the blocked statement with a new statement that does not return any data. Providing a substitute results in the best end-user experience, and ensures that applications can keep running. The client session is maintained, and the client can execute more SQL if needed without having to reconnect.

  • Drop the Connection

    When you set this response, the blocked SQL statement results in a drop of the client connection to the database. This response blocks all traffic from that specific connection to the database. This response is the most aggressive action. If the application is using connection pooling, then this response affects all of the users using the pool. Because an attacker can reestablish the connection, Oracle recommends that this action is always logged, and that appropriate users are alerted.

4.4 Planning and Rolling Out the Database Firewall

Before you deploy and configure database firewalls with Oracle Audit Vault and Database Firewall, you must review and make decisions about the Database Firewalls that you require, the level of protection you need, and other factors affecting configuration.

To deploy and configure database firewalls using Oracle Audit Vault and Database Firewall (the Database Firewalls), you must consider the following questions as part of your firewall planning:

• Which databases do I need to protect? In which networks are they located?

  Each of the databases that you want to protect will be added as secured targets in Oracle Audit Vault Server. The database location on the network affects how you can place the database firewall to achieve the type of monitoring that you need.

• Do I need to both monitor and block or substitute SQL traffic to my databases, or only monitor and alert?

  The answers you have to these questions can differ, depending on the database that you want to protect. Remember that to block and substitute SQL statements, a database firewall must be in-line between the database and its client applications, or configured as a proxy.

• How many Database Firewalls do I need, and where will they be on the network? Which ones will be in-line (bridge), out-of-band (for example, using a span port), or configured as proxies?

  In-line bridge mode is deprecated in 12.2.0.8.0, and can be desupported in a later release. Oracle recommends that you use proxy mode as an alternative.

  Based on your answer to this question, as well as the previous question, you can have a matrix showing the database secured targets, level of protection, and network mode. For example:

  Table 4-2 Database Secured Target Matrix

  Secured Target	Monitor Only or Block?	Network Mode	Oracle Audit Vault Agent?
  Database 1	Monitor	Out-of-band	Optional
  Database 2	Block	Proxy	Optional
  Database 3	Block	In-line	Optional
  Database 3	Monitor	Host Monitor	Required

• How many enforcement points do I need for my Database Firewall?

  For each database secured target, you must configure one enforcement point in Oracle Audit Vault Server The enforcement point provides the following information to Oracle Audit Vault Server:

  • Which Database Firewall is protecting this database secured target

  • What protection level to use: activity monitoring (DAM) or policy enforcement/blocking (DPE)

  • What are the network traffic sources to this database secured target?

  When configuring your enforcement points, consider compiling a list containing this information so that it is available to you during configuration.

• Do I need to configure database firewalls for high availability?

  To ensure that Oracle Audit Vault and Database Firewall can access security objects in the event of a failure, Oracle recommends that you configure Oracle Audit Vault and Database Firewall for a high availability environment.