5 Configuring Database Firewall
Learn about configuring Database Firewall.
You can use Database Firewall to configure traffic sources and proxies.
5.1 About Configuring Database Firewall
Learn how to configure Database Firewall.
The way in which you configure 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 a Firewall instance, you identify the Audit Vault Server that will manage the specific Firewall. Depending on your plan for the overall Oracle Audit Vault and Database Firewall system configuration, you also configure the traffic sources, and determine the deployment types. The following are the Database Firewall deployment types:
- Monitoring (Out-of-Band)
- Monitoring (Host Monitor)
- Monitoring / Blocking (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 100K transactions per second. This is based on internal performance tests.
Basic firewall configuration consists of these four steps:
-
Specifying the Audit Vault Server Certificate and IP Address
-
Managing the Oracle Database Firewall Network and Services Configuration
-
Configuring Database Firewall and Its Traffic Sources on Your Network
After configuring the Database Firewalls, perform the following tasks:
-
Configure Database Firewall monitoring points for each database target.
-
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 Your Oracle Audit Vault and Database Firewall System Configuration for an overview of the planning steps.
-
High Availability in Oracle AVDF to set up resilient pairs of Database Firewalls for a high availability.
5.2 Introduction to Database Firewall Deployment
Depending on your requirements, you can choose from one of three types of deployments available for Database Firewall.
Depending on your operational needs you can monitor SQL traffic only, or monitor and block the SQL traffic reaching the target database. Based on the requirement, you can deploy the Database Firewall in the following modes:
-
Monitoring / Blocking (Proxy) - In this deployment mode the Database Firewall can monitor, alert, block, and substitute SQL statements, based on the defined policy.
-
Monitoring (Out-of-Band) - In this deployment mode, the Database Firewall can monitor SQL traffic, but cannot block or substitute SQL statements.
- Monitoring (Host Monitor) - In this deployment mode, the Database Firewall can monitor SQL traffic, but cannot block or substitute SQL statements.
Table 5-1 Database Firewall Deployment Types
Deployment Type | Supported Modes | Minimum Number of Network Interface Cards (NICs) | Operational Notes |
---|---|---|---|
Proxy |
Monitoring / Blocking (Proxy) |
3 (for deployment with network separation) 1 (for deployment without network separation) |
In proxy mode, the Database Firewall can both monitor and block SQL, as well as optionally substitute SQL statements. |
Out-of-Band |
Monitoring (Out-of-Band) |
2 |
When monitoring database activity in Out-of-Band mode, the Database Firewall intercepts the network traffic, including client requests to the database and the response from the database. |
Host Monitor |
Monitoring (Host Monitor) |
1 |
Host Monitor is part of the Audit Vault Agent. |
The same Database Firewall can monitor traffic from multiple Host Monitors, and at the same time be a proxy for some databases, and out-of-band (span) for other databases.
Note:
- A single network interface card (NIC) is required in the case that client and database are on the same sub-network. There is no network separation.
- Additional NICs are required in the case that client and databases are on different sub-networks.
- In case where there are 3 NICs, the network separation requires you to have a management network interface which is usually attached to the default gateway. The first NIC is placed in the client subnet. The second NIC is placed in the database subnet. There is no additional routing set up required in this configuration. All the addresses for clients and databases are local to the networks that are accessible to the Database Firewall NICs.
5.2.1 Monitoring / Blocking (Proxy)
Learn about how to configure Database Firewall in Monitoring / Blocking (Proxy) mode.
In Monitoring / Blocking (Proxy) mode, the Database Firewall can both monitor and block SQL, as well as optionally substitute SQL statements. Database Firewall is configured as a proxy, so that all the traffic to the database server is routed through the Database Firewall.
Database clients connect to the Database Firewall proxy that in turn connects to the database server, forwarding all data received from the database client. In all cases, the database server identifies the Database Firewall as the client.
The clients must be reconfigured to connect to the Database Firewall instead of the database. Oracle recommends that you configure the database to reject all connections that do not come from the Database Firewall.
Note:
To simplify the modification required for applications to connect to the Database Firewall proxy mode deployments, configure local domain name servers (DNS) to resolve fully qualified domain name (FQDN) of the target database to the IP address of the Database Firewall.You can deploy the Monitoring / Blocking (Proxy) mode in the following ways:
- Proxy without network separation
- Proxy without network separation using a dedicated NIC for the proxy service
- Proxy with network separation
Proxy Without Network Separation
The proxy without network separation has the client and database traffic accessible at all points in the network. The Database Firewall management interface is accessible to both the client and database subnetworks through the network router. In this case, the Database Firewall allows clients to connect to the target database through the Database Firewall.
Figure 5-1 Proxy Without Network Separation
The image illustrates the Database Firewall deployment in proxy without network separation. The callouts or pointers in the image indicate the following:
- A: The clients in the client network make an explicit connection to the Database Firewall directly.
- B: The clients in the database network connect to the Database Firewall directly.
- C: The extracted SQL data from the client traffic is analyzed and sent to the Audit Vault Server, based on the Database Firewall policy.
Proxy Without Network Separation Using a Dedicated NIC for the Proxy Service
The proxy without network separation using a dedicated NIC for the proxy service has the client and database on different subnets. Additional network interface cards (NICs) are required for every additional subnet deployed.
Figure 5-2 Proxy Without Network Separation Using a Dedicated NIC for the Proxy Service
The image illustrates the Database Firewall deployment in proxy without network separation using a dedicated NIC for the proxy service. The callouts or pointers in the image indicate the following:
- A: The clients in the client network connect to the Database Firewall traffic proxy through the network router.
- B: The clients in the database network connect to the Database Firewall traffic proxy directly.
- C: The extracted SQL data from the client traffic is analyzed and sent to the Audit Vault Server, based on the Database Firewall policy.
- D: The traffic is forwarded to the target database by the Database Firewall. The response from the database is returned to the Database Firewall and then forwarded to the originator through the network router.
- E: The management network is separate from the client and database networks.
Proxy With Network Separation
The Database Firewall can monitor and block SQL traffic. The Database Firewall can optionally substitute SQL statements. In cases where database servers are deployed remotely, the Database Firewall can be configured as a proxy so that all the traffic to the database server is routed through the Database Firewall. Database clients connect to the Database Firewall proxy, which in turn connects to the database server, and forwards all data received from the database client. In all cases the database server identifies the Database Firewall as the client. The clients must be reconfigured to connect to the Database Firewall instead of the database. It is advisable to configure the database to reject all connections not coming from the Database Firewall.
To simplify the modification required for applications to connect to the Database Firewall deployments through proxy, configure local DNS in a way that the target FQDN resolves to the IP address of the Database Firewall.
The proxy with network separation has the client and database on different sub network. In this mode, the Database Firewall allows clients to connect through the Database Firewall. It also allows the clients to connect to the database directly, without a single point of failure.
The image illustrates Database Firewall deployment in proxy with network separation. The callouts or pointers in the image indicate the following:
- A: The Database Firewall places a network interface card in each network. The clients must connect directly to the Database Firewall network interface card and should be prevented from connecting to the database through the network router. The clients connecting to the Database Firewall are connected to the database through the network interface card in the database network.
- B: The Database Firewall directly connects to the databases in the database network.
- C: The Database Firewall sends the response from the database directly to the clients. These clients connect to the Database Firewall in the client network.
- D: The client traffic using the proxy is monitored by the Database Firewall and then forwarded to the Audit Vault Server. The Database Firewall connects to the databases in the local network through the network interface card and the switch.
5.2.2 Monitoring (Out-of-Band)
Learn about how to configure Database Firewall in the Monitoring (Out-of-Band) mode.
When you configure database activity monitoring in Out-of-Band mode, the Database Firewall listens to the network traffic, including client requests to the database and the response from the database.
The database activity is monitored as per the defined policy. There are several technologies that can be used to copy database traffic to the database firewall. These technologies include (but are not limited to) spanning ports, network taps, and using packet replicators.
In this mode, the Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements.
The Monitoring (Out-of-Band) mode is the simplest deployment mode overall for a non-blocking policy requirement. There is no additional load on the database or the clients. There is no latency or single point of failure introduced by the Database Firewall. Oracle AVDF supports high availability in this deployment mode.
The image illustrates deployment of the Database Firewall component in Monitoring (Out-of-Band) mode. The callouts in the image indicate the following:
- A: The Database Firewall interface is plugged into a span port on the switch.
- B: Database Firewall monitors the SQL traffic received from the switch.
- C: The extracted SQL data from the client traffic is analyzed and sent to the Audit Vault Server, based on database firewall policy.
5.2.3 Monitoring (Host Monitor)
Learn about how to configure Database Firewall in Monitoring (Host Monitor) mode.
To use Database Firewall in Monitoring (Host Monitor) mode, Audit Vault Agent and Host Monitor Agent are installed on the host machine running the target database. The Host Monitor Agent captures traffic from the network interface card of the host machine running the target database. The captured SQL traffic is then securely forwarded to the Database Firewall.
Note:
In Oracle AVDF release 20.3 and later, any network interface card (with IP address configured) on the Database Firewall can be added to the monitoring point. See section Create a Monitoring Point for the Host Monitor.Monitoring (Host Monitor) mode is helpful if the network topology prevents deployment of other Database Firewall modes. Host monitoring is designed for situations to capture only the relevant traffic when compared to capturing all the network traffic in Monitoring (Out-of-Band) mode. The Monitoring (Host Monitor) mode can monitor SQL traffic using the Host Monitor Agent deployed on the database server in case there are multiple network paths from clients to the database host.
The image illustrates deployment of Database Firewall in Monitoring (Host Monitor) mode. The callouts or pointers in the image indicate the following:
- A: The Host Monitor Agent records the traffic in between the client and the database over a network interface. The data is then forwarded securely to the Database Firewall for monitoring.
- B: The extracted SQL data from the client traffic is analyzed by the Database Firewall and sent to the Audit Vault Server, based on the database firewall policy.
5.3 Specifying the Audit Vault Server Certificate and IP Address
Learn about specifying the Audit Vault Server certificate and IP address.
Prerequisite
Ensure to accomplish all the Database Firewall Post-Install Tasks before proceeding with the procedure listed in this topic.
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, then 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:
5.4 Managing the Oracle Database Firewall Network and Services Configuration
Learn how to manage the Oracle Database Firewall network and services configuration.
5.4.1 Configuring Network Settings for Oracle Database Firewall
Learn how to configure the network settings for Oracle Database Firewall.
The installer configures initial network settings for the Database Firewall during installation. You can change the network settings after installation.
To change the Database Firewall network settings:
5.4.2 Configuring Network Services for Oracle Database Firewall
Learn about configuring network services for Oracle Database Firewall.
The network services configuration determines how administrators can access Oracle Database Firewall. See the guidelines to protect data and ensure that you take the appropriate security measures when configuring network services.
To configure network services for a Database Firewall:
5.4.3 Configuring SNMPv3 Users in Oracle Audit Vault and Database Firewall
Learn how to configure SNMPv3 users.
Simple Network Management Protocol version 3 (SNMPv3) is an interoperable, standards-based protocol. SNMPv3 involves User-based Security Model (USM) for message security and the View-based Access Control Model (VACM) for access control. With USM, messages exchanged between the SNMP Manager and the SNMP Agent can have data integrity checking and data origin authentication. Oracle Audit Vault and Database Firewall 20.1 and later supports SNMPv3 as the default version. This topic contains the steps needed to configure SNMPv3 users for making use of the USM model of SNMPv3.
To create an SNMPv3 user, follow these steps:
5.5 Setting the Date and Time in Database Firewall
Learn how to set the date and time in Database Firewall.
Use this procedure to set the Database Firewall date and time:
5.6 Changing IP Address on a Single Instance of Database Firewall Server
Learn how to change the IP Address on a single instance of Database Firewall Server.
Use this procedure to change the IP address of the Database Firewall Server.
Before you begin
Change the IP address of the Database Firewall Server during a safe period to avoid interrupting the log collection processing.
To change the IP address of the Database Firewall Server:
Note:
Once the Database Firewall Server is back online it begins to download any monitoring point log data that is not downloaded while it was offline.
5.7 Changing the Database Firewall Host Name
Learn how to change the Database Firewall host name.
To change the Database Firewall host name using the Audit Vault Server console:
- Log in to the Audit Vault Server console as administrator.
- Click Database Firewalls tab in the Audit Vault Server console main page. The Database Firewalls tab in the left navigation menu is selected by default.
- Locate and click the name of the specific Database Firewall instance for which the host name needs changing. The Firewall Details page is displayed.
- Change the Host Name in the main page. This is the name of the host machine on which the Database Firewall is installed.
- Click Save button in the top right corner.
5.8 Configuring Database Firewall and Its Traffic Sources on Your Network
Learn about configuring Oracle Database Firewall and its traffic sources on your network.
Note:
A single proxy port is required for every target. A single proxy port cannot service multiple target databases. Add more traffic proxy ports as required.5.8.1 About Configuring Oracle Database Firewall and Traffic Sources On Your Network
Learn about configuring Oracle Database Firewall and its traffic sources on the network.
During your planning of the network configuration, you must decide the Database Firewall deployment type. The following are the Database Firewall deployment types:
- Monitoring (Out-of-Band)
- Monitoring (Host Monitor)
- Monitoring / Blocking (Proxy)
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 monitoring only or will include blocking mode as well.
You will use traffic and proxy sources of a Firewall to configure monitoring points for each target database you are monitoring with that firewall.
5.8.2 Configuring Traffic Sources
Learn about configuring traffic sources.
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.
To change the configuration of traffic sources:
5.8.3 Configuring Database Firewall As A Traffic Proxy
Learn about configuring a Firewall as a traffic proxy.
You can specify multiple ports for a proxy in order to use them for different monitoring 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:
5.9 Viewing the Status and Diagnostics Report for Database Firewall
Learn how to view Database Firewall status and diagnostics reports.
To view the status or diagnostic reports for Database Firewall:
5.10 Configure and Download the Diagnostics Report File
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.
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 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
SOS_REPORT
Note:
SOS_REPORT
can be included starting with Oracle AVDF release 20.7.
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
5.11 Configuring Encapsulated Remote Switched Port Analyzer with Database Firewall
Learn how to configure Database Firewall when the SQL traffic is mirrored using Encapsulated Remote Switched Port Analyzer.
Encapsulated Remote Switched Port Analyzer (ERSPAN) mirrors the traffic from one or more source ports and delivers the mirrored traffic to one or more destination ports on another device.
This functionality enables the Database Firewall to interpret the SQL traffic received. This functionality is available only in Monitoring (Out of Band) deployment mode of Database Firewall.
Configuring ERSPAN with Database Firewall includes the following steps on a high level:
- Configuring the ERSPAN source or the switch.
- Configuring the Database Firewall.
Configuring the ERSPAN source or the switch includes the following steps:
-
The network device must be configured to span the SQL traffic to the target databases being monitored.
-
Consider the following aspects during ERSPAN configuration:
- Avoid spanning the database response traffic unless it requires to be analyzed.
- Avoid spanning empty TCP packets. For example, empty ACK packets.
-
Ensure the ERSPAN traffic is directed to the appropriate network interface card (NIC) configured on the Database Firewall.
Configuring the Database Firewall for this functionality includes the following steps:
-
Configure the Database Firewall monitoring point only in Monitoring (Out of Band) mode.
-
List all the IP addresses and ports of the SQL traffic expected from the target databases.
Note:
For Oracle Real Application Cluster databases, this is not just the scan IP addresses. It also includes all the relevant Oracle RAC nodes. -
Configure the Database Firewall monitoring point. During configuration, select the NIC to which the ERSPAN traffic is forwarded.
-
The Database Firewall does not process the ERSPAN traffic by default. It has to be enabled on the Database Firewall monitoring points. Follow these steps to enable:
- Log in to the Database Firewall as support user.
- Switch to root user.
- Every Database Firewall monitoring point has a number
(
N
) assigned. Identify the number assigned to this Database Firewall monitoring point being configured. Run the following command:grep <Target_Name> /var/dbfw/va/*/etc/appliance.conf /dev/null
- It displays output similar to the following:
/var/dbfw/va/1/etc/appliance.conf:<Target_Name>="ora-TGT"
- Identify the target database name and the relevant
va
number associated with that. The number (N
) assigned to the Database Firewall monitoring point is listed next tova
in the above path. -
Enable ERSPAN in the Database Firewall monitoring point by editing the file:
/usr/local/dbfw/va/<N>/etc/appliance.conf
. - In the file, edit the setting:
DAM_TRAFFIC_IS_ERSPAN="0" to DAM_TRAFFIC_IS_ERSPAN="1"
. - Save the changes.
- Restart the Database Firewall processes so that the new configuration comes
into effect. Run the command to restart:
/usr/local/dbfw/bin/dbfwctl restart
-
Verify the ERSPAN traffic received. Access the
/var/log/messages
file in the Database Firewall. Navigate and locate the stringODF-10524: Encapsulated protocol detected
. This string is logged when the ERSPAN traffic is first received.