Skip Headers
Oracle® Database Firewall Administration Guide
Release 5.0

Part Number E18695-08
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

A Oracle Database Firewall Security Guidelines

This appendix contains:

General Security Recommendations

Oracle recommends that you follow these security recommendations:

Considerations for Deploying Network-Based Solutions

This section contains:

Handling Network Encryption

You deploy Oracle Database Firewall between the database tier and application tier. If SQL traffic between the database tier and application tier is encrypted, then the Database Firewall cannot understand or enforce protection policies on this SQL traffic.

To remedy this problem, configure your database servers to reject or prevent encrypted traffic. For Oracle databases, in the sqlnet.ora file, set the SQLNET.ENCRYPTION_SERVER parameter in the sqlnet.ora file to REJECTED. (See Oracle Database Net Services Reference for more information about this setting.) For all Database Firewall-supported database products, including Oracle Database, you can use SSL termination solutions to terminate the SQL traffic just before it reaches the Database Firewall. This prevents clear text traffic from passing through the Database Firewall.

Handling Server-Side SQL and Context Configurations

The Oracle Database Firewall policy enforcement relies on capturing and understanding SQL traffic between the database client and server. Because the Database Firewall only analyzes network traffic between the application tier and the database server, be aware that it cannot see SQL that is directly invoked from the database server itself. Some of the common types of SQL statements that the Database Firewall cannot see are system-provided and user-defined SQL executed from stored procedures and callouts, SQL executed from background jobs such as those that were created by the DBMS_JOB or DBMS_SCHEDULER PL/SQL packages in Oracle databases, or SQL that is indirectly executed from DDLs or other SQL statements.

Oracle Database Firewall builds its execution context entirely from the information that it captures from the network traffic. However, enforcement may depend on context information on the server. The lack of this context affects how an identifier used in novelty policies is resolved.

How Oracle Database Firewall Works with Various Database Access Paths

Be aware of how Oracle Database Firewall works with the following types of database access paths:

Security Considerations for Special Configurations

This section contains:

Handling an Oracle Shared Server Configuration and Dispatchers

A shared server architecture enables a database server to permit many user processes to share few server processes. The dispatcher process directs multiple incoming network session requests to a common queue, and then redirects these session requests to the next available process of the shared server. By default, Oracle Database creates one dispatcher service for the TCP protocol. In the init.ora file, this setting is controlled by the DISPATCHERS parameter, as follows:

dispatchers="(PROTOCOL=tcp)"

In the default configuration, a dynamic port listens to the incoming connection using the TCP protocol. With a shared server configuration, many user processes connect to a dispatcher on this dynamic port. If the Database Firewall is not configured to monitor the connections on this port, then the policy cannot be enforced on these connections. To facilitate the Database Firewall connection configuration, you should explicitly include the port number in the DISPATCHERS parameter. For example:

dispatchers="(PROTOCOL=tcp)(PORT=nnnn)"

Choose a value for nnnn, and configure the Database Firewall to protect that address, alongside the usual listener address.

See also Oracle Database Administrator's Guide for more information about managing shared servers. For more information about the DISPATCHERS parameter, see Oracle Database Reference.

How TCP Invited Nodes Are Affected by Client IP Addresses

When Oracle Database Firewall is in Database Policy Enforcement (blocking) mode, the protected database only recognizes the Database Firewall's IP address, which is the IP address assigned to the Database Firewall bridge (as described in "Step 7: Configure the Standalone Database Firewall Bridge IP Address". It will no longer recognize the IP addresses of the protected database's clients, and as a result, users will be unable to connect to this database.

You can remedy this problem by including the Database Firewall Bridge IP address in the TTC/Net parameter TCP.INVITED_NODES setting in the sqlnet.ora file. The TCP.INVITED_NODES parameter specifies the nodes from which clients are allowed access to the database. When you deploy a Database Firewall, you should use the policy profiles feature to implement network access restrictions similar to those provided by TCP.INVITED_NODES. The policy profiles feature in the Database Firewall supports additional factors such as IP address sets, time of day, users, and so on. See Oracle Database Firewall Security Management Guide for more information about profiles.

As described in this section, the client IP address seen by the database server is the address assigned to the bridge in the Database Firewall. This feature can affect functionality on the database server that depends on the original client IP address. Some of this functionality that can depend on the client IP address includes logon triggers, analysis of audit data, and Oracle Database Vault factors.

Additional Behavior to be Aware Of

  • Client-side context. Oracle Database Firewall policies can be configured to use client-side context information such as client program name, client OS username, etc. After the client transmits this information to the database server, the Database Firewall captures it from the network. Oracle Database Firewall does not control or enforce the integrity of the client side or network; the integrity of this information must be considered before using it to define a security policy.

  • Multiple databases and services on a shared listener. Oracle Database Firewall enforces policies that are based on the IP address and port number. In a configuration where a single listener endpoint (IP_address:port) is shared among multiple databases, the Database Firewall cannot differentiate traffic directed to each individual database.