This appendix contains:
Oracle recommends that you follow these security recommendations:
If you are using a Database Firewall to block unwanted traffic, ensure that all data flowing from the database clients to the database and back, passes through the Database Firewall. This includes both requests and responses.
Use the appropriate security measures for your site to control access to the computer that contains the Database Firewall, giving access only to specific users (for example, for reporting use).
Ensure that user credentials, such as passwords, conform to best practice.
Configure Administration Console users with a view-only, Logging Administrator or System Administrator role, depending on their duties.
Segregate duties, for example, between administrators, users of the Analyzer software, and those who access the logs
This section contains:
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.
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.
Be aware of how Oracle Database Firewall works with the following types of database access paths:
Non-SQL protocol access. Database platforms support different network protocols beyond the database SQL-based protocols. For example, Oracle Database supports HTTP, FTP, Advanced Queuing, Direct Path, and NFS access to the data stored in the database. Oracle Database Firewall provides policy enforcement only for SQL-based access to the database. The protocols that Database Firewall understands are Oracle TTC/Net and Tabular Data Stream (TDS) for Microsoft SQL Server, Sybase ASE, and IBM Distributed Relational Database Architecture (DRDA)
Local Connections. Oracle Database Firewall provides limited monitoring support for local connections. It does not provide blocking functionality for local connections such as the bequeath protocol or shared memory connections. See Oracle Database Net Services Administrator's Guide for more information about the bequeath protocol, and Oracle Database Administrator's Guide about shared memory management.
IPv6 Connections. Oracle Database Firewall does not support IPv6 deployments. The Database Firewall automatically blocks all traffic coming from an IPv6 connection.
Non-TCP-based Connections. Oracle Database Firewall only supports TCP-based network connections to database servers. It cannot monitor connections made to database servers using non-TCP protocols such as Systems Network Architecture (SNA), Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX).
This section contains:
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.
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.
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.