This chapter explains how to configure the Database Firewall on the network and how to configure traffic sources, bridges, and proxies.
Topics
Changing the UI (Console) Certificate for the Database Firewall
Managing the Database Firewall's Network and Services Configuration
Specifying the Audit Vault Server Certificate and IP Address
Configuring Database Firewall and its Traffic Sources on Your Network
Configuring an Interface Masters Niagara Server Adapter Card
Viewing the Status and Diagnostics Report for a Database Firewall
Configuring the system and firewall settings for each Database Firewall depends on your overall plan for deploying Oracle Audit Vault and Database Firewall.
When you configure each firewall, you identify the Audit Vault Server that will manage that firewall. Depending on your plan for the overall Oracle Audit Vault and Database Firewall system configuration, you also configure the firewall's traffic sources, and determine whether it will be inline or out of band with network traffic, and whether you will use it as a proxy.
Note:
The Audit Vault Server and the Database Firewall server are software appliances. You must not make any changes to the Linux operating system through the command line on these servers unless following official Oracle documentation or under guidance from Oracle Support.
Database Firewall introduces very minimal latency overhead of less than 100 microseconds per SQL statement with 4000 transactions per second. This is based on internal performance tests.
Basic firewall configuration consists of these four steps:
Managing the Database Firewall's Network and Services Configuration
Specifying the Audit Vault Server Certificate and IP Address
Configuring Database Firewall and its Traffic Sources on Your Network
After configuring the Database Firewalls, perform the following tasks:
Configure enforcement points for each database secured target that the firewall is protecting.
You can optionally set up resilient pairs of Database Firewalls for a high availability environment.
See Also:
Summary of Configuration Steps to understand the high level workflow for configuring the Oracle Audit Vault and Database Firewall system.
Planning the System Configuration for an overview of the planning steps.
Configuring Enforcement Points to configure enforcement points.
Configuring High Availability to set up resilient pairs of Database Firewalls for a high availability.
When you first access the Database Firewall administration console, you see a certificate warning or message. To avoid this type of message in the future, you can upload a new UI certificate signed by a relevant certificate authority.
Prerequisite
Log in to the Database Firewall administration console as an administrator. See Logging in to the Database Firewall Console UI for more information.
To change the UI certificate for the Database Firewall:
Note:
You may need to install the public certificate of the Certificate Authority in your browser, particularly if you are using your own public key infrastructure.
Topics
The installer configures initial network settings for the Database Firewall during installation. You can change the network settings after installation.
Prerequisite
Log in to the Database Firewall administration console. See Logging in to the Database Firewall Console UI for more information.
To change the Database Firewall network settings:
The network services configuration determines how administrators can access the Database Firewall. See the guidelines to protect data and ensure that you take the appropriate security measures when configuring network services.
Prerequisite
Log in to the Database Firewall administration console. See Logging in to the Database Firewall Console UI for more information.
To configure network services for a Database Firewall:
Prerequisite
Log in to the Database Firewall administration console. See Logging in to the Database Firewall Console UI for more information.
To set the Date and Time in the Database Firewall:
You must associate each Database Firewall with an Audit Vault Server by specifying the server's certificate and IP address, so that the Audit Vault Server can manage the firewall. If you are using a resilient pair of Audit Vault Servers for high availability, you must associate the firewall to both servers.
Note: You must specify the Audit Vault Server certificate and IP address to the Database Firewall (by following the procedure below) before you register the firewall in the Audit Vault Server.
To specify the Audit Vault Server certificate and IP address:
Before you begin
Change the IP address of the Database Firewall Server during a safe period as it avoids interruption to collection of logs.
To change the IP address of the Database Firewall Server:
Note:
Once the Database Firewall Server is back online it begins to download any Enforcement Point log data that is not downloaded while it was offline.
Topics
During your planning of the network configuration, you must decide whether to place Database Firewall inline with traffic to your secured target databases, or out of band (for example, using a spanning or mirror port). You may also decide to use a firewall as a traffic proxy. The network configuration is impacted by whether the Database Firewall will operate in DAM (monitoring only) or DPE (blocking) mode.
Using the Database Firewall administration console, you configure traffic sources for each firewall, specifying whether the sources are inline with network traffic, and whether the firewall can act as a proxy.
You will use traffic and proxy sources of a firewall to configure enforcement points for each secured target database you are monitoring with that firewall.
See Also:
Introduction to Database Firewall Deployment for more information on Database Firewall modes.
Traffic sources specify the IP address and network interface details for the traffic going through a Database Firewall. Traffic sources are automatically configured during the installation process, and you can change their configuration details later.
Prerequisite
Log in to the Database Firewall administration console. See Logging in to the Database Firewall Console UI for more information.
To change the configuration of traffic sources:
Before you configure a bridge in the Database Firewall, ensure that the following is in place:
Ensure that the Database Firewall is inline with network traffic (or configured as a proxy) if it is to be used in blocking mode (DPE) to block potential SQL attacks.
If the Database Firewall is not in proxy mode, then allocate an additional IP address that is unique to the database network, to enable a bridge.
Oracle Audit Vault and Database Firewall uses the bridge IP address to redirect traffic within the Database Firewall. When the Database Firewall is used as a proxy, you do not need to allocate this additional IP address.
To enable a traffic source as a bridge, ensure that this traffic source has two network interfaces. These network interface ports must connect the Database Firewall in-line between the database and its clients (whether Database Policy Enforcement or Database Activity Monitoring mode is used).
Note:
The IP address of the bridge must be on the same subnet as all secured target databases when the Database Firewall is in DPE mode using that bridge. This restriction does not apply when the Database Firewall is deployed in DAM mode.
If the Database Firewall's management interface (specified in the console's Network page) and the bridge are connected to physically separate networks that are on the same subnet, the Database Firewall may route responses out of the wrong interface. If physically separate networks are required, use different subnets.
In-line bridge mode is deprecated in 12.2.0.8.0
, and will be desupported in 19.1.0.0.0
. It is advisable to use proxy mode as an alternative.
To configure the Database Firewall bridge IP address:
Log in to the Database Firewall administration console.
In the System menu, click Network.
In the Management Interface page, click the Change button.
In the Traffic Sources section, find the traffic source that you want to configure as a bridge.
This traffic source must have two network interfaces, which are listed in the Devices table. You can add an interface if necessary from the Unallocated Network Interfaces section of the page.
Select Bridge Enabled for this traffic source.
If necessary, edit the IP Address or Network Mask settings.
The bridge IP address is used to redirect traffic within the Database Firewall.
Click Save.
Learn about configuring a firewall as a traffic proxy.
Depending on your network configuration, you may prefer to configure a traffic proxy in the Database Firewall instead of a bridge inline with network traffic. You can then associate the proxy with an enforcement point. You can also specify multiple ports for a proxy in order to use them for different enforcement points.
Once you set up the Database Firewall as a traffic proxy, your database clients connect to the database using the Database Firewall proxy IP and port.
To configure a traffic proxy:
Learn how to configure an Interface Masters Niagara Server adapter card
Caution:
Oracle Audit Vault and Database Firewall release 12.2.0.11.0 does not support Niagara cards. Do not upgrade to this release if you use Niagara cards.
Use this procedure to configure an Interface Masters Niagara Server Adapter Card. The drivers are available when you install Oracle Audit Vault and Database Firewall.
Log in to the Database Firewall command shell as the root user.
Edit the /etc/init.d/dbfw.niagara
file as follows:
Find the line INSTALLED_NIAGARA_CARDS=0
.
Change the 0
to match the number of installed Niagara cards for this Database Firewall.
Restart the Database Firewall.
See Also:
Oracle Audit Vault and Database Firewall Installation Guide for a complete list of supported Network Interface Cards.
To view the status and/or diagnostic report for a Database Firewall:
Learn about configuring and downloading the diagnostics report file.
This section contains information about enabling, configuring, and modifying the way diagnostic reports are generated using CLI.
Note:
You need root user privileges to perform these tasks.
Starting with release 12.2.0.6.0, the diagnostic report is not enabled by default. You must enable the feature to capture the diagnostic report. Once enabled, you must configure the information that is to be captured in the diagnostic report. You can customize and package the diagnostics report with flexibility.
The following file contains instructions about how to install, enable, and run the diagnostic utility:
diagnostics-not-enabled.readme
See Also:
This file is generated only if you follow the instructions for downloading the diagnostics report. See Viewing the Status and Diagnostics Report for a Database Firewall for more information.
Use the following commands to accomplish certain tasks related to diagnostics.
Command | Action |
---|---|
|
To capture the enabled diagnostic information for the appliance. The location of the saved zip file is displayed at the end of the command execution. Note: This command must be run from |
|
To enable the system to capture diagnostics report. |
|
To enable capturing the complete diagnostics report. |
|
To enable individual elements in the diagnostics report. |
The following elements can be included while customizing the diagnostics report:
SYSTEM LOG DATABASE AVS_ARCHIVE DBFW_ARCHIVE PLATFORM_COMMANDS AVS_HA_COMMANDS AVS_COMMANDS DBFW_COMMANDS
The content of the diagnostics report is controlled by the file /usr/local/dbfw/etc/dbfw-diagnostics-package.yml
. The user can modify this file to include and exclude a combination of files in multiple categories. Each section of this file has an option to enable and disable the specific category by setting the value to true
or false
.
For example, to add an item to one of the log file collections simply add the file path or glob to the list under the :files:
element.
:log_files: :comment: Log files generated by the system runtime, install and upgrade. :enabled: false :platform: - AVS - DBFW :files: - /root/apply.out - /root/install.log - /root/install.log.syslog - /root/install_database_api.log - /root/migration-stats-*.yml - /root/once.log - /root/pre_firstboot_logs/partition-include - /root/pre_firstboot_logs/partitions_error - /root/pre_firstboot_logs/syslog - /var/lib/avdf/system_history.yaml - /var/log - /path/to/new/file - /path/to/new/*glob
To add a new command output to the log, add the command to the correct group:
:all_commands: :comment: Command output to include in the diagnostics package. :enabled: false :platform: - AVS - DBFW :commands: :cpuinfo: :enabled: true :command: - :cat - /proc/cpuinfo :logfile: /proc-cpuinfo.log :diskuse: :enabled: true :command: - :df - -kP :logfile: /disk-usage.log :new_command :enabled: true :command: - :new_command - -arg1 - -arg2 :logfile: /new-command.log
Note:
To remove the diagnostic package when it is not in use, run the following command:
/usr/local/dbfw/bin/priv/dbfw-diagnostics-package.rb --remove