2 General Security Guidelines

Learn about general security guidelines.

2.1 Installing Securely and Protecting Your Data

Topics

2.1.1 Installing Oracle Audit Vault and Database Firewall Securely

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.

2.1.2 Protecting Your Data

Learn how to use 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: Create password policies to force users to use 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.

  • Remote Access: The Settings tab of the services page of Oracle Audit Vault Server console controls access to:
    • web console
    • shell (ssh)
    • SNMP

    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.

2.2 General Security Recommendations

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.

2.3 External Network Dependencies

Learn about external network dependencies.

When you add an external network service to Oracle Audit Vault Server or Oracle 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 host names that you look up. If someone were to compromise the DNS server, then they can control the network endpoints accessed by Oracle Audit Vault Server or Oracle 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 Oracle Audit Vault Server or Database Firewall only when the following are adequately secure:

  • the service
  • the host server
  • the intermediate network

2.4 Considerations for Deploying Network-Based Solutions

Topics

2.4.1 Managing Oracle Database Firewall Network Encryption

Learn about handling Oracle Database Firewall network encryption.

You deploy Oracle Database Firewall between the database tier and application tier. Oracle 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 Oracle 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 Oracle Database Firewall.

2.4.2 Handling Server-Side SQL and Context Configurations

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.

2.5 How Oracle AVDF Works with Various Database Access Paths

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).

2.6 Security Considerations for Special Configurations

Learn about security considerations for special configurations.

2.6.1 Managing Oracle Database Firewall Shared Server Configurations and Dispatchers

Learn about managing Oracle Database Firewall shared server configurations and dispatchers.

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:

2.6.2 How TCP Invited Nodes Are Affected by Client IP Addresses

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:

2.6.3 Additional Behavior to be Aware Of

  • 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.

2.6.4 Custom Collector Development

Learn about custom collector development.

Note the following if you develop custom collectors:

  • Prevent resource leaks. Ensure that JDBC resources are closed appropriately. These resources include the connections, result sets, and statements.
  • Prevent data loss. Ensure that your audit data is purged from the target system only after it has been successfully collected by the custom collector.
  • Avoid frequent queries to the target system.
  • Ensure that the custom collector does not consume a lot of system resources such as CPU and memory on the target host.
  • Avoid logging audit data because the audit records contain sensitive information.
  • Grant only the required privileges on the target system to users who have access to the Agent.
  • Ensure that only necessary files are added to custom collector .jar file.
  • Ensure that your custom collector code collects the audit data from your target system securely.

    Note:

    The collection framework ensures that audit data is transferred from the collector to Oracle Audit Vault Server securely.

2.7 About Setting Transport Layer Security Levels

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
TLSv1.1

This level supports everything that Level-4 does, and adds TLSv1.1.

Level-2

(Default on upgrade)

TLSv1.2
TLSv1.1

This level adds support for legacy and deprecated ciphers.

Note:

  • It is recommended to upgrade the TLS level to Level-4 instead of the default.

  • The upgrade process does not change the TLS level to default in case the user has changed or set the value of TLS level manually in previous releases.

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 1, 2, 3, or 4.

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 1, 2, 3, or 4.

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 1, 2, 3, or 4.

Note:

Perform the following steps to upgrade all Agents to the specified TLS levels after executing the configure-networking command:

1. Log in to the Audit Vault Server console as root user.

2. Change the directory by using the command:

cd /usr/local/dbfw/bin/priv

3. Execute the script using the command:

./send_agent_update_signal.sh

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 /var/log/messages to confirm that there are no errors in the file.

To edit the custom level configuration file.

/usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

/usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

/usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_ssl_services.xml

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 12.2.0.9.0, it is set to Level–4. Change the TLS level to Level-3 if any of the Audit Vault Agents are deployed on IBM AIX.

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.

  1. The customizable set of TLS levels are defined in the following files:
    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_agent.xml

    • /usr/local/dbfw/etc/platform-configuration/tls_configuration_custom_group_ssl_services.xml

  2. The tls_configuration_custom_group.xml file can be modified as desired to include available ciphers on the product.
  3. Execute the following command to display the complete list of available ciphers:
    openssl ciphers –v
    
  4. Open the tls_configuration_custom_group.xml file and verify the format of the file. The format must be similar to the following:
    <?xml version="1.0" encoding='UTF-8' standalone='yes'?>
    
    <tls_configuration_groups xmlns='http://www.oracle.com/avdf'>
    
    <tls_configuration level="1">
    
    <ssl_protocols>
    
    <ssl_protocol>...</ssl_protocol>
    
    </ssl_protocols>
    
    <ssl_cipher_suite>
    
    <ssl_cipher>...</ssl_cipher>
    
    </ssl_cipher_suite>
    
    </tls_configuration>
    
    </tls_configuration_groups>
    
  5. In the customizable tls_configuration_custom_group.xml file, only the following tags can be added or removed as required:
    <ssl_protocol>...</ssl_protocol>
    
  6. Multiple tags can be applied in a sequence as follows:
    <ssl_cipher>...</ssl_cipher>
    
  7. The values must be any of the following Apache protocol values:
    1. TLSv1.2
      
    2. TLSv1.1
      
    3. TLSv1 (Deprecated)
      
  8. Execute the following command to apply the custom set.
    /usr/local/dbfw/bin/priv/configure-networking --wui-tls-cipher-level 1 --internal-tls-cipher-level 1 --agent-tls-cipher-level 1