Configuring Database Firewall

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:

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.
Configuring Database Firewall Monitoring Points
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.

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

Description of "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

Description of "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.

Figure 5-3 Proxy With Network Separation

Description of "Figure 5-3 Proxy With Network Separation"

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.

Figure 5-4 Monitoring (Out-of-Band)

Description of "Figure 5-4 Monitoring (Out-of-Band)"

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.

Figure 5-5 Monitoring (Host Monitor)

Description of "Figure 5-5 Monitoring (Host Monitor)"

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:

Log in to the Audit Vault Server console as an adminstrator.
Click Settings tab.
Click on Security tab in the left navigation menu.
Click on Certificate tab in the main page, and then click on Server Certificate sub tab.

The server's certificate is displayed.
Copy the server's certificate.
Connect to the Database Firewall server through SSH.

Note:
The support user has to be set up post installation of Database Firewall for SSH access.
Switch the user to be the root user.
```
su - root
```
Copy the server certificate of the Audit Vault Server into a file on the Database Firewall server.

Run these commands to associate the primary or secondary Audit Vault Server for the Database Firewall:

Task Command

Task	Command
To display the Audit Vault Servers paired with the Database Firewall	`/opt/avdf/config-utils/bin/config-avs show`
To add or update the primary Audit Vault Server for the Database Firewall	`/opt/avdf/config-utils/bin/config-avs set avs=primary address=<Ip address of the primary AVS> certificate=<Path of the certificate>`
To add or update the secondary Audit Vault Server for the Database Firewall	`/opt/avdf/config-utils/bin/config-avs set avs=secondary address=<Ip address of the secondary AVS> certificate=<Path of the certificate>`

To display the Audit Vault Servers paired with the Database Firewall

/opt/avdf/config-utils/bin/config-avs show

To add or update the primary Audit Vault Server for the Database Firewall

/opt/avdf/config-utils/bin/config-avs set avs=primary address=<Ip address of the primary AVS> certificate=<Path of the certificate>

To add or update the secondary Audit Vault Server for the Database Firewall

/opt/avdf/config-utils/bin/config-avs set avs=secondary address=<Ip address of the secondary AVS> certificate=<Path of the certificate>

Run these commands to remove the primary or secondary Audit Vault Server for the Database Firewall:

Task	Command
To remove the primary Audit Vault Server for the Database Firewall	`/opt/avdf/config-utils/bin/config-avs delete avs=primary`
To remove the secondary Audit Vault Server for the Database Firewall	`/opt/avdf/config-utils/bin/config-avs delete avs=secondary`

Run the following command to synchronize the system clocks of Database Firewall Server with the Audit Vault Server:
```
/opt/avdf/config-utils/bin/config-ntp set servers=<Comma separated IP addresses or hostnames of NTP servers> sync_on_save=true enabled=true
```
Note:
To perform the same procedure in the Audit Vault Server console, refer to Setting the Date and Time in Database Firewall.

See Also:

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:

Log in to the Audit Vault Server console as administrator.
Click the Database Firewalls tab.
Click the specific Database Firewall instance for which the network settings needs to be configured or changed.
Click Network Settings link under the Configuration section in the main page.
In the Network Settings dialog, click the specific network interface.
In the Network Interface Settings dialog, complete the following fields as necessary:
- IP Address: The IP address of the network interface. If you want to use a different address, then you can change it here. The IP address is static and must be obtained from the network administrator.
  
  The network interface which has the same IP address as that of Database Firewall is the Management Interface. If the IP address of the Management Interface is changed, then the IP address of the Database Firewall is also changed. After changing the IP address of the Management Interface, in the Network Interface Settings dialog, then change the IP address on the Database Firewall details page.
- Network Mask: The subnet mask of the Database Firewall. If you want to use a different network mask, then you can change it here.
- Gateway: The IP address of the default gateway (for example, for internet access). The default gateway must be on the same subnet as the host. This is optional.
Click Save.

Note:

The following error may be encountered while changing the IP address of the Management Interface. This can be ignored and no action required.

Operation failed OAV-46981: Unable to connect to Database Firewall with IP

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:

Click Database Firewalls tab in the Audit Vault Server console.
In the left navigation menu, click Database Firewalls.
Click on the specific Database Firewall instance.
Under Configuration tab, click on System Services.

In the System Services dialog, the following options are available:

DNS: If you require host names to be translated, then enter the IP address of at least one DNS server on the network. Turn on the button and enter IP addresses for up to three DNS servers (DNS Server 1, DNS Server 2, and DNS Server 3). Keep the button turned off if there is no DNS server. Otherwise, your system's performance may be impaired.

If you want to use DNS, then ensure that the servers are reliable. If the DNS servers are unavailable, then many services on the Database Firewall do not work. For example, the Database Firewall may pass traffic that it would otherwise block.

SSH/SNMP: If you want to allow selected computers to have secure shell access to the Database Firewall, then turn on the button for SSH Access. You can select All to allow unrestricted access or click on IP Addresses and enter their IP addresses separated by space or comma.

SSH setting can also be configured using command line interface. Use these commands for the same.

Task	Command
To display the current settings of SSH	`/opt/avdf/config-utils/bin/config-ssh show`
To allow unrestricted access from all systems	`/opt/avdf/config-utils/bin/config-ssh set access=all`
To block SSH access from all systems	`/opt/avdf/config-utils/bin/config-ssh set access=disabled`
To allow a selected computer to have secure shell access to the Database Firewall	`/opt/avdf/config-utils/bin/config-ssh set access=192.0.2.11`
To allow a multiple computers to have secure shell access to the Database Firewall	`/opt/avdf/config-utils/bin/config-ssh set access='192.0.2.11 192.0.2.12'`

SNMP Access: If you want to enable access to the network configuration of the Database Firewall through SNMP, then turn on the button for SNMP Access. You can select All to allow unrestricted access or click on IP Addresses and enter their IP addresses separated by space or comma.

Click Save.

See Also:

Protecting Your Data

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:

Log in to the Audit Vault Server or Database Firewall instance as root user.
Run the following command to turn off the snmpd service:
```
systemctl stop snmpd
```
Run the following command to create a new SNMP user:
```
net-snmp-create-v3-user
```
Enter the user name and password (or passphrase) following the prompt.
Enter the encryption passphrase following the prompt. If you want to use the same passphrase for encryption, then press the Enter key to continue.
The following output confirms the user creation.
adding the following line to /var/lib/net-snmp/snmpd.conf:

createUser <user name> SHA <password> AES <encryption password>

adding the following line to /etc/snmp/snmpd.conf:

rwuser <user name>
Note:

The new user created has read and write access by default. This can be modified to read only privileges. This can be done by modifying the file available at /etc/snmp/snmpd.conf:
```
rouser <user name>
```
In the configuration file, find the line or entry where rwuser <user name> is mentioned. Change the entry to rouser <user name> for read only access.
After the user is created, you can assign the user to an existing group. Or you can create a new group and assign the user.
1. Follow this step to assign the newly created user to an existing group. In Oracle Audit Vault and Database Firewall, the default group name is notConfigGroup. Edit the /etc/snmp/snmpd.conf file and include the following line in the group creation table. Ensure the user name of the new user is under the UserName column.
```
#      groupName     securityModel  userName
group notConfigGroup     usm         <user name>
```
  Example of adding the user to a predefined group:
```
#      groupName     securityModel  userName
group notConfigGroup     usm         myUser
```
2. Follow this step to assign the newly created user to a new group.
```
#      groupName     securityModel  userName
group <new group name>     usm         <user name>
```
  Example of adding the user to a new group:
```
#      groupName     securityModel  userName
group newGroup     usm         myUser
```
Run the following command to start the snmpd service:
```
systemctl start snmpd
```
Run the following command to test and confirm that the SNMPv3 user is created and assigned to the group:
Note:

Install the net-snmp-utils package to run the following snmpwalk command. It is not installed as part of Audit Vault Server or Database Firewall installation by default. Other standard SNMP querying tools can also be used.
```
snmpwalk -v3 -u <user name> -a SHA -A "<authentication password>" -x AES -X "<privacy password>" -l authPriv <IP address of the system> <standard SNMP MIB>
```
For example:
```
snmpwalk -v3 -u myUser -a SHA -A "myAuthPassword" -x AES -X "myPrivacyPassword" -l authPriv 192.0.2.24 system
```

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:

Log in to the Audit Vault Server console as administrator.
Click Database Firewalls tab in the Audit Vault Server console main page.
In the left navigation menu, click Database Firewalls.
Click on the specific Database Firewall instance.
Under Configuration tab, click System Services.
Click Date and Time tab.
In the System Time field, select the date and time in Coordinated Universal Time (UTC).
Optionally you can enable NTP synchronization. You can turn on the button against NTP Server1 and enter the NTP server address in the field. You can add 1 and upto 3 NTP server addresses.

It keeps the time synchronized with the average of the time recovered from the time servers specified in the NTP Server1, NTP Server2, and NTP Server3 fields, which contain an IP address or a name. If you specify a name, then the DNS server specified in the DNS tab is used for name resolution.

To enable time synchronization, you also must specify the IP address of the default gateway and a DNS server.

WARNING:

In Monitoring / Blocking mode, changing the time causes all monitoring points to restart, dropping existing connections to protected databases. This causes a temporary disruption to traffic, and will happen when you choose to enter the time directly.
Click Save.

See Also:

Managing the Oracle Database Firewall Network and Services Configuration to specify the IP address of the default gateway and DNS server.

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:

Log in to the Audit Vault Server console as an administrator.
Click Database Firewalls tab. The Database Firewalls tab in the left navigation menu is selected by default.
Click on a specific Database Firewall instance. The details of the Firewall instance are displayed on the main page.

Note:
In Oracle AVDF 20.1, the IP address can be changed on the main page. Do not change the IP address in the IP Address field here. Follow the remaining steps in this topic.
Click Network Settings under the Configuration section.
Click the specific network interface, under the column Network Interface Card.
In the Network Interface Settings dialog, edit the IP address, Gateway, or the Network Mask fields as necessary.
Click Save and Close buttons to exit the dialog. Do not click on the cross (X) mark in the top right corner of the dialog.

Note:

In Oracle AVDF 20.1, the following error may be encountered while attempting to change the IP address of the Management Interface:

Operation failed OAV-46981: Unable to connect to Database Firewall with IP <ipaddress>

Ignore the error and close the window. The IP address is changed successfully. This error is fixed in Oracle AVDF 20.2.

This change is effective immediately on Database Firewall. However, it may take a few seconds for the network update on the Database Firewall and for the system to settle.

Continue with the remaining steps only if the IP address to be changed belongs to the Management Interface if your current installation is Oracle AVDF 20.1. These steps are not required for Oracle AVDF 20.2 and later. The Management Interface IP address is the IP address of the Database Firewall which was used to register the Database Firewall in the Audit Vault Server console.
In the Database Firewall details page, the IP Address of the Database Firewall Server is displayed next to the Firewall Name field. Change the IP address.
Click Save. The Firewall updated successfully message is displayed on the screen.
After the changes are saved, the certificate validation may fail. Click the name of the Database Firewall and then click Update Certificate.
After the certificate is updated, the Database Firewalls tab is displayed. The Database Firewall Server is online.
Change the IP address on the /etc/hosts of the Audit Vault Server appliance to the new one as root user.

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:

Click the Targets tab.
The Targets tab in the left navigation menu is selected by default.
Select the specific target from the list.
In the Database Firewall Monitoring section, click the specific target.

The Database Firewall Monitor dialog lists all the details like the current network settings, proxy ports, and traffic sources (Network Interface Cards) of the specific Database Firewall instance.
To make changes to the IP address or the network mask, navigate to the Database Firewall tab.
Click the specific Database Firewall instance. The details are displayed on the page.
Under the Configuration section, click Network Settings.
In the Network Settings dialog, click the specific network interface card under the Network Interface Card column.
In the Network Interface Settings dialog, edit the IP address or Network Mask fields as necessary.
Click Save.

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:

Log in to the Audit Vault Server console as an administrator.
Click on Database Firewalls tab. The Database Firewalls tab in the left navigation menu is selected by default.
Click on the Database Firewall instance that you want to configure as a proxy. The details of the specific Database Firewall is displayed on the main page.
In the Configuration section, click on Network Settings.
In the Network Settings dialog, click the specific network interface card under the Network Interface Card column.

The Network Interface Settings dialog is displayed.
Click the Add button under Proxy Ports section.
Enter the Name for the port.
Enter the Port number.
You can specify more than one proxy port by entering another port number and clicking Add.
Click Save. The traffic proxy is now available to use in the monitoring point.

See Also:

Configuring Database Firewall Monitoring Points

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:

Log in to the Audit Vault Server console.
Click the Database Firewalls tab.
Click the name of a specific Database Firewall instance for which the diagnostics needs to be viewed.
In the Diagnostics section on the main page, click Download Diagnostics.

The Download Diagnostics dialog is displayed.
Select one of the following buttons on the dialog:
- Run Diagnostics to run diagnostics.
- Download to download all diagnostics files.
- Delete to clear the diagnostic logs.

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
`/usr/local/dbfw/bin/priv/dbfw-diagnostics-package.rb`	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 `/usr/local/dbfw/tmp` when collecting diagnostics information.
`/usr/local/dbfw/bin/priv/dbfw-diagnostics-package.rb --install`	To enable the system to capture diagnostics report.
`/usr/local/dbfw/bin/priv/dbfw-diagnostics-package.rb --enable ALL`	To enable capturing the complete diagnostics report.
`/usr/local/dbfw/bin/priv/dbfw-diagnostics-package.rb –enable <Element>`	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:
1. Log in to the Database Firewall as support user.
2. Switch to root user.
3. 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
4. It displays output similar to the following: /var/dbfw/va/1/etc/appliance.conf:<Target_Name>="ora-TGT"
5. 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 to va in the above path.
6. Enable ERSPAN in the Database Firewall monitoring point by editing the file: /usr/local/dbfw/va/<N>/etc/appliance.conf.
7. In the file, edit the setting: DAM_TRAFFIC_IS_ERSPAN="0" to DAM_TRAFFIC_IS_ERSPAN="1".
8. Save the changes.
9. 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 string ODF-10524: Encapsulated protocol detected. This string is logged when the ERSPAN traffic is first received.