Topics
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.
Related Topics
Learn about the types of deployments available for Oracle Database Firewall.
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:
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:
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:
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.
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:
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:
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
The image illustrates Oracle Database Firewall deployment in proxy mode without network separation. The callouts or pointers in the image indicate the following:
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.
The image illustrates Oracle Database Firewall deployment in proxy mode with network separation. The callouts or pointers in the image indicate the following:
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.
The image illustrates deployment of the database firewall component in Out-of-Band mode. The callouts in the image indicate the following:
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:
In this deployment mode, Oracle Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements.
The image illustrates deployment of Oracle Database Firewall in Host Monitor mode. The callouts or pointers in the image indicate the following:
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.Exception rules (also called preconditions) within a firewall policy evaluate various factors before analyzing SQL statements.
Exceptions evaluate these session factors:
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.
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.
As with exceptions, session profiles in firewall policies evaluate session information before analyzing SQL statements.
You can define session profiles using the following information:
Session profiles differ from exceptions:
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.
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:
INSERT
, UPDATE
, DELETE
, SELECT
INTO
, and so onSELECT
CREATE
, DROP
, ALTER
, and so onGRANT
, REVOKE
, and so onCOMMIT
, ROLLBACK
, and so onBy 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.
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.
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
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.
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.
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.