Topics
Learn to securely install Oracle Audit Vault and Database Firewall.
Oracle Audit Vault Server installs in a secure state by default. Therefore, it is important to be careful if you change any of the default settings because your changes may compromise the security of your setup.
See Also:
Oracle Audit Vault and Database Firewall Installation Guide for details of the installation.
Consider account naming, password use, and other guidelines to better enable Oracle AVDF to protect your data.
Consider following these guidelines to protect your data:
Account Names and Passwords: Use secure passwords for the Oracle Audit Vault Server console UI, as well as for the root, support, and sys accounts and keep these passwords safe.
Administrator Accounts: Do not share Oracle Audit Vault and Database Firewall Administrator accounts.
Strong Password Policies: Encourage users to adopt strong passwords.
Installed Accounts: Oracle Audit Vault and Database Firewall embeds operating system and database accounts. Do not add new accounts of this type. Do not unlock the existing accounts. Doing so may compromise the security of the Oracle Audit Vault and Database Firewall system.
Secure Archiving: Oracle Audit Vault and Database Firewall sends archive data over the network. Secure both the archive destination and intermediate network infrastructure.
Follow these guidelines when granting remote access:
Grant access only if you need it for a specific task and then revoke access when that task is completed.
Restrict access by IP address. Do this immediately after installing the system.
Grant terminal (shell) access only when doing a patch update or when requested to do so by the documentation or by Oracle support.
Oracle recommends that you follow these security recommendations:
If you are using the 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 Audit Vault Server and the Database Firewall appliances. Give access only to specific users.
Ensure that passwords conform to best practice.
Separate the duties of administrators and auditors by assigning these roles to different people.
Assign users of the Audit Vault Server the appropriate administrator, super administrator, auditor, and super auditor roles.
By default, the following accounts that are related to Oracle AVDF are locked: the Oracle OS user account, Oracle Grid accounts, any Oracle Database Vault accounts (for example, users who have been granted the DV_OWNER and DV_ACCTMGR roles). Ensure that these accounts remain locked.
Ensure the security of your Oracle AVDF configuration by considering important external network dependencies.
When you add an external network service to Audit Vault Server or Database Firewall, you include these services to the trust model of your deployment.
For example, when you add a DNS server to an appliance, you trust the DNS server to provide the correct information about the host names that you look up. If someone compromises the DNS server, then they can control the network endpoints that are accessed by Audit Vault Server or Database Firewall using the host name.
There are analogous trust relationships in other services too, for example, NFS or NTP.
For this reason, add network services to Audit Vault Server or Database Firewall only when the following are adequately secure:
Topics
Learn about handling Database Firewall network encryption.
You deploy Database Firewall between the database tier and application tier. Database Firewall can decrypt traffic to and from an Oracle Database when you use Oracle Native Network Encryption. For non-Oracle databases, and for Oracle Databases that use TLS network encryption, if SQL traffic between the database tier and application tier is encrypted, then Database Firewall cannot interpret or enforce protection policies on this SQL traffic.
You can use SSL or TLS termination solutions to terminate the SQL traffic just before it reaches Database Firewall.
This section is relevant to the Database Firewall.
The 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. You can use the auditing features in Oracle AVDF to capture these types of SQL statements.
The 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 AVDF 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. The Database Firewall provides policy enforcement only for SQL-based access to the database. The protocols that the 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)
IPv6 Connections. Oracle AVDF does not support IPv6 deployments. The Database Firewall automatically blocks all traffic coming from an IPv6 connection.
Non-TCP-based Connections. The 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).
Topics
Learn about managing Database Firewall shared server configuration.
Shared server architectures enable databases to permit user processes to share server processes. A 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
Oracle Database Reference for more information about the DISPATCHERS parameter
When the Database Firewall is in Database Policy Enforcement (DPE) mode, the secured target database only recognizes the Database Firewall's IP address, which is the IP address assigned to the Database Firewall bridge. 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 the 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.
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.
See Also:
Configuring a Bridge in the Database Firewall for more information on Database Firewall's IP address.
Oracle Audit Vault and Database Firewall Auditor's Guide for more information about profiles.
Client-side context. 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. The 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. The Database Firewall supports policies based on Oracle Database service names. For non-Oracle databases, the 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.
Learn about custom collector development.
Note the following if you develop custom collectors:
.jar file.Note:
The collection framework ensures that audit data is transferred from the collector to Oracle Audit Vault Server securely.Learn about setting Transport Layer Security (TLS) levels.
This topic describes the different levels of connection encryption deployed on Oracle Audit Vault and Database Firewall appliances. Oracle Audit Vault and Database Firewall uses TLS for inter-component communication.
You can change the TLS levels and cipher suites for the following:
Connection between Oracle Audit Vault Server and the Agent or Host Monitor (from release 12.2.0.9.0)
Connection between Host Monitor and Oracle Database Firewall (from release 12.2.0.9.0)
Connection between Oracle Audit Vault Server and Database Firewall
Oracle Audit Vault Server and Database Firewall GUI
Note:
Ensure that the host machine has OpenSSL 1.0.1 (or later) installed for Oracle Audit Vault Agent or Host Monitor.
If any agent is using Java 1.6, then upgrade the Java version to 1.8.
Connection Encryption Strength Used On Oracle Audit Vault and Database Firewall Appliances
| TLS Level | TLS Version | Description |
|---|---|---|
|
Level-4 (Default on new installation) |
TLSv1.2 |
This level is the strongest, restricting TLS to version 1.2 for inter communication between all the components in Oracle Audit Vault and Database Firewall. Note: If any Audit Vault Agent has to be deployed on IBM AIX, then set the TLS level to Level-3 or below. |
|
Level-3 |
TLSv1.2 |
This level supports everything that Level-4 does. |
|
Level-2 (Default on upgrade) |
TLSv1.2 TLSv1.1 |
This level adds support for legacy and deprecated ciphers. Note:
|
|
Level-1 (Custom) |
TLSv1.2 |
This is a customizable cipher set that is configured with Level-4 strength by default. |
How To Change TLS Levels and Other Tasks
| Task | Command | Detailed Information |
|---|---|---|
|
To check the existing TLS levels for Audit Vault Server and Database Firewall. |
cat /usr/local/dbfw/etc/dbfw.conf | grep CIPHER_LEVEL |
Use this command to check the actual configuration of the Audit Vault Server and Database Firewall. |
|
To set the TLS level and to find more options. |
/usr/local/dbfw/bin/priv/configure-networking --help |
By default, on a new installation the TLS level is set to Level-4. On upgrade it is set to Level-2 by default. This is appropriate to most of the situations. It is possible to change the level set. Use this command to find the options available. |
|
To set TLS level for the AVS GUI. |
/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level [LEVEL] |
This command sets the TLS level for web browser connections to the AVS GUI. The levels can be set to |
|
To set TLS level for communication between Audit Vault Server and Database Firewall. |
/usr/local/dbfw/bin/priv/configure-networking --internal-tls-cipher-level [LEVEL] |
This command sets the desired TLS level and restarts the internal services. The levels can be set to |
|
To set the TLS level for Audit Vault Agent to Audit Vault Server, and Host Monitor to Database Firewall communication. |
/usr/local/dbfw/bin/priv/configure-networking --agent-tls-cipher-level [LEVEL] |
This command sets the TLS level for communication between the Audit Vault Agent to Audit Vault Server, and Host Monitor to Database Firewall. The levels can be set to Note: Perform the following steps to upgrade all Agents to the specified TLS levels after executing the 1. Log in to the Audit Vault Server console as root user. 2. Change the directory by using the command:
3. Execute the script using the command:
This command must not be executed more than once in a period of one hour. |
|
To apply customized cipher set. |
/usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1 --internal-tls-cipher-level 1 --agent-tls-cipher-level 1 |
By default, on a new installation the product is set to Level-4. On upgrade it is set to Level-2. This is appropriate to most of the situations. It is possible to customize. Use this command to apply the custom defined level from the file created. These commands set the TLS level for web browser connections and restart the internal services and Audit Vault Server. Note: Before executing this command verify the error output in the system log file available at |
|
To edit the custom level configuration file. |
|
The customizable set of cipher suites is defined in this file. By default, on a new installation the product is set to Level4. This file can be modified to further restrict the cipher suite and include ciphers available on the product. |
|
To display the complete list of available cipher suites. |
openssl ciphers -v |
Use this command to display the current set of available cipher suites. |
When To Change TLS Levels
Oracle recommends leaving the internal TLS level at Level-4. Here is some more information on when to change the TLS levels:
| Component | Situation |
|---|---|
|
Internal communication |
Oracle recommends to set at Level–4 for increased security. |
|
Audit Vault Server GUI |
To support old browsers, set the TLS level to match the browser. |
|
Audit Vault Agent / Host Monitor / Audit Vault Server |
Oracle recommends to set at Level–4 for increased security. |
|
Audit Vault Agent deployed with IBM AIX |
On a fresh installation of release |
Setting Custom Cipher Sets
Use this procedure to set the custom cipher set. Do this by creating a custom file that defines the TLS levels and later applying the file.
Learn about different certificates in Oracle AVDF.
Learn how to renew or rotate Audit Vault Server certificates.
Audit Vault Server uses certificates for internal communication with various components and services. Oracle AVDF provides the ability to renew Audit Vault Server certificates before they expire.
Follow these steps to renew or rotate the Audit Vault Server certificates:
Learn how to renew or rotate Database Firewall certificates.
Database Firewall uses certificates for internal communication with various components and services. Oracle AVDF provides the ability to renew Database Firewall certificates before they expire.
Note:
Renew or rotate certificates for each Database Firewall instance including those paired for high availability.Follow these steps to renew or rotate the Database Firewall certificates: