This chapter contains:
Consider the precautions outlined below to install securely and protect your data.
The Oracle Database Firewall installs in a secure state by default. Therefore, it is important to be careful if changing default settings, as this will result in a less secure state. For details of the installation, see the Oracle Database Firewall Installation Guide.
During the installation process, consider the following guidelines:
Where possible, install the Database Firewall Management Server and Analyzer on separate servers.
Change the admin passwords on each Database Firewall and Management Server server immediately after the installation is complete.
Make sure the log partition is large enough for your needs. Review the size regularly. If the log runs out of space records can be lost.
Consider the following guidelines to protect your data:
Account Names and Passwords: Use secure passwords for the Administration Console UI, root, support, and sys accounts and keep these passwords safe. Only give them to highly trusted administrators and change them regularly. Unauthorized access to these accounts can compromise your system. If you suspect that these credentials have been given to unauthorized people, change them immediately.
Separate Administrator Accounts: Reserve the admin user account as a back-up user account, and then create a separate administrative account for each existing user for day-to-day operations. These accounts should never be shared. This allows better auditing of administrator activity.
Examine Administrator Activity: Review the Administration Changes log on a regular basis to check for suspicious activity. This includes, for example, multiple failed logins or repeated denial of access if logged in. See the Oracle Database Firewall Administration Guide for information on how to view this log.
Strong Password Policies: Create password policies to force users to use strong passwords. See the Oracle Database Firewall Administration Guide for details.
Installed Accounts: Database Firewall is installed with existing terminal (shell) access and embedded database accounts. You should avoid adding new accounts of this type or unlocking the existing ones, since these accounts can be used to tamper with the data or operation of the Database Firewall system.
Secure Archiving: The account you set up for archiving should serve this purpose only, and should not be used for general purposes. Grant this account the minimum privileges needed for archiving. Additionally, since archive data is transferred over the network, ensure that the archive destination and network infrastructure are secure.
Remote Access: Database Firewall allows you to set remote access permissions in the System Services page of the Administration Console. Remote access can be granted for Web access to the Administration Console, Terminal (shell), SNMP, Secure Log, and Traffic Log. Follow these guidelines when granting remote access:
Grant access only if you need it for a specific task, and consider turning access off when that task is completed.
Restrict access by IP address. Do this immediately after installing the system.
Grant terminal (shell) access only when doing an RPM upgrade or when requested to do so by system support.
Restrict Traffic Log access to the Database Firewall Analyzer IP address.
Enable secure log access only if you are using an external reporting tool in addition to the Database Firewall built-in reports. Also, restrict secure log access to IP addresses that will be running external reports.
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. The Database Firewall can decrypt traffic to and from an Oracle database. For non-Oracle databases, 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 non-Oracle database servers to reject or prevent encrypted traffic. 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 Guidefor 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 Oracle Database Firewall Administration Guide). 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 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.