7 Configuring Targets, Audit Trails, and Database Firewall Monitoring Points
Learn about configuring targets, audit trails, and Database Firewall monitoring points.
7.1 About Configuring Targets
Learn about configuring targets.
Targets can be supported databases or operating systems that Audit Vault and Database Firewall monitors. You must register all of the targets in the Audit Vault Server, regardless of whether you are deploying the Audit Vault Agent, the Database Firewall, or both.
If you want to collect audit trails from your targets, you must configure an audit trail for each target and start collection manually.
If you want to monitor a target with the Database Firewall, you must create a monitoring point for that target.
For Oracle Database targets that you monitor with the Database Firewall, you can configure Oracle Audit Vault and Database Firewall to monitor the native network encrypted traffic. To do so, you must run scripts on the target computers to configure the necessary privileges.
If you are using the Database Firewall, you can also monitor the target database's responses to incoming SQL traffic. The following sections contain the high-level workflow for configuring the Oracle Audit Vault and Database Firewall system.
7.2 Registering Targets and Creating Groups
Learn about registering targets and creating groups.
7.2.1 Registering or Removing Targets in Audit Vault Server
Learn about registering and removing targets in Audit Vault Server.
7.2.1.1 About Targets in the Audit Vault Server
Oracle Audit Vault and Database Firewall (Oracle AVDF) super administrators can create targets and grant other administrators access on those targets.
Administrators can also create targets, but the targets that they create are accessible only to the creator and to the super administrator who created the administrator.
The following guidelines apply when creating and accessing targets:
- Both super administrators and administrators can create targets.
- Super administrators can grant access on targets or target groups to specific administrators.
- Super administrators have access to all targets, and administrators have access only to those targets on which they have been granted access.
In Oracle Database 12c, if you are not using a multitenant container database (CDB), then register a target for your database as you would for previous versions of Oracle Database. If you use a CDB, then you must register a target for the CDB, as well as for each pluggable database (PDB).
7.2.1.2 Registering Targets
Learn about registering targets for audit collection and Database Firewall monitoring.
This section explains how to register targets in Oracle Audit Vault Server:
7.2.1.3 Modifying Targets
Learn about modifying targets.
To modify a target:
Note:
If you change the name of a target, then the new name does not appear in Oracle Audit Vault and Database Firewall reports until you restart the Audit Vault Agent.
See Also:
-
Registering Targets for description of the fields in the Modify Target page.
-
Working with Lists of Objects in the Audit Vault Server Console to sort or filter the list of targets.
7.2.1.4 Removing Targets
Learn about removing targets.
If you no longer need to have a target registered with Oracle Audit Vault and Database Firewall, then you can use either the console or the command-line utility to remove the target. After you have removed the target, the audit data pertaining to the target still resides in the data warehouse within its retention period (according to the archiving policy).
After you have removed a target, its identity data remains so that there will be a record of targets that have been dropped. Remove the target only if you no longer want to collect its data or if it has moved to a new host computer.
To remove a target:
7.2.2 Creating a Target Group
Learn how to create target groups.
As a super administrator you can create target groups to grant other administrators access to targets as a group rather than individually.
-
Log in to the Audit Vault Server console as a super administrator.
-
Click the Targets tab.
-
In the left navigation menu, click Target Groups.
-
Click Create button in the top right corner.
-
In the Create Target Group dialog, do the following:
Release Oracle AVDF 20.1 and 20.2 Release Oracle AVDF 20.3 and later - Name field: Enter a name for the target group.
- Description: Optionally, enter a description for this target group.
- Under Members section, select one or more members by clicking the check box against the member name.
-
Click the Add button.
- Group Name field: Enter a name for the target group.
- Description: Optionally, enter a description for this target group.
- Under Members section, select one or more members by moving them from the Available column to Selected column. You can also search for the targets in the field below the Members section using the target name.
- To remove the targets, select one or more members and move them back to the Available column from the Selected column.
-
Click Save.
7.2.3 Modifying a Target Group
You can modify the contents of a target group or change the target group name and description.
7.2.4 Controlling Access to Targets and Target Groups
Learn about controlling access to targets and target groups.
Oracle Audit Vault and Database Firewall super administrators can control which administrators have access to targets or target groups. You can control access for an individual user or for an individual target or group.
7.2.5 Moving a Target from One Host Machine to Another
Learn how to handle when a target is moved from one host machine to another.
There are a few changes to be made in Audit Vault Server console when a target is moved from one host machine to another. This depends on the type of the Audit Vault Agent.
An Audit Vault Agent can be of two types:
- When the Audit Vault Agent is installed on the target host machine, it is called as a local Agent.
- When the Audit Vault Agent is not installed on the target host machine and is installed remotely, it is called as a remote Agent.
The following table contains the configuration and the steps to be followed in the Audit Vault Server console when the target is moved from one host machine to another.
Note:
Oracle Automatic Storage Management Cluster File System (Oracle ACFS) or Oracle Advanced Cluster File System was deprecated in Oracle AVDF release 20.7 and is desupported in 20.8.
Sybase SQL Anywhere was deprecated in Oracle AVDF release 20.7 and is desupported in 20.8.
Agent Type | Trail Type | Target Type | Steps in Audit Vault Server Console |
---|---|---|---|
Local |
|
Oracle Database Oracle Key Vault Sybase ASE |
Step 1: Update the target Connection Details by following these steps:
Step 2: Delete existing trail by following these steps:
Step 3: Create a new trail and configure the Audit Vault Agent installed on the new host machine. Refer to Adding Audit Trails in Audit Vault Server |
Local |
|
Oracle Database |
Step 1: Update the target Connection Details. Step 2: Delete the existing trail. Step 3: Create a new trail by configuring the Audit Vault Agent installed on the new host machine and using the new trail location of the new host machine. |
Local |
|
MySQL Microsoft SQL Server PostgreSQL IBM DB2 Quick JSON Oracle Solaris Linux IBM AIX Microsoft Windows Microsoft Active Directory Oracle ACFS |
Step 1: Delete the existing trail. Step 2: Create a new trail by configuring the Audit Vault Agent installed on the new host machine and using the new trail location of the new host machine. |
Local |
|
Oracle Database MySQL Microsoft SQL Server IBM DB2 Sybase ASE Sybase SQL Anywhere |
Step 1: Delete the existing trail. Step 2: Create a new trail by configuring the Audit Vault Agent installed on the new host machine. |
Remote |
|
Oracle Database Oracle Key Vault Sybase ASE |
Step 1: Update the target Connection Details. Step 2: There is no need to delete and recreate the trails. Stop the existing trail. Step 3: Start the trail. |
Remote |
|
Oracle Database |
Step 1: Update the target Connection Details. Step 2: In case the trail location has changed, then delete the existing trail. Step 3: Create a new trail and specify the new trail location. |
Remote |
|
MySQL Microsoft SQL Server PostgreSQL IBM DB2 Quick JSON Oracle Solaris Linux IBM AIX Microsoft Windows Microsoft Active Directory Oracle ACFS |
Step 1: In case the trail location has changed, then delete the existing trail. Step 2: Create a new trail and specify the new trail location. |
7.3 Preparing Targets for Audit Data Collection
Learn about preparing targets for audit data collection.
7.3.1 Using an NTP Service to Set Time on Targets
Learn how to use NTP Service to configure time settings on targets.
Oracle recommends that you use an It is recommended that you also use a Network Time Protocol (NTP) service on both your targets and the Audit Vault server. This will help to avoid confusion on timestamps on the alerts raised by the Audit Vault Server.
See Also:
Specifying the Server Date, Time, and Keyboard Settings for instructions on using an NTP server to set time for the Audit Vault Server.
7.3.2 Ensuring that Auditing is Enabled on the Target
Learn how to enable auditing.
To collect audit data from a target, you must ensure that auditing is enabled on that target and, where applicable, note the type of auditing that the target is using. Check the product documentation for your target type for details.
To check if auditing is enabled on an Oracle Database target:
7.3.3 Setting User Account Privileges on Targets
Learn about setting account privileges on targets.
Some target types require credentials in order for Oracle Audit Vault and Database Firewall to access them. If you plan to collect audit data from a target, perform stored procedure auditing (SPA), entitlements auditing, or monitor native network encrypted traffic for Oracle Database, then you must create a user account on the target with the appropriate privileges to enable Oracle Audit Vault and Database Firewall to access the required data.
Setup scripts for database targets: Oracle Audit Vault and Database Firewall provides scripts to configure user account privileges for database target types.
Non-database targets: You must create a user that has the appropriate privileges to access the audit trail required. For example, for a Windows target, this user must have administrative permissions in order to read the security log.
Note:
Oracle Audit Vault and Database Firewall does not accept user names with quotation marks. For example, "J'Smith" would not be a valid user name for an Audit Vault and Database Firewall user account on targets.
See Also:
Scripts for Oracle AVDF Account Privileges on Targets for information on scripts to configure user account privileges for database target types.
7.4 Configuring and Managing Audit Trail Collection
Learn about configuring and managing audit trail collection.
7.4.1 Prerequisites for Adding Audit Trails in Oracle Audit Vault Server
Learn about the prerequisites for adding audit trails in Oracle Audit Vault Server.
Before configuring an audit trail for any target, you must:
-
Oracle Golden Gate version 19.1 or later must be installed to configure Transaction Log audit trail on Oracle Database.
-
Add the target in the Audit Vault Server. See Registering or Removing Targets in Audit Vault Server for details.
-
Register the host machine. This machine is where the Audit Vault Agent is deployed and the target resides in case of directory trails. See Registering Hosts and Deploying the Agent.
-
Deploy and start the Audit Vault Agent on the host machine. See Deploying the Audit Vault Agent on Host Computers.
-
For IBM DB2 targets, ensure that the binary audit file has been converted to ASCII format before starting an audit trail.
-
For MySQL targets, run the XML transformation utility. See Running the XML Transformation Utility for MySQL Audit Formats.
7.4.2 Adding Audit Trails in Audit Vault Server
Learn about adding audit trails in Audit Vault Server.
To begin collecting audit data, configure an audit trail for each target in Audit Vault Server and then start the audit trail collection manually.
Note:
The Audit Vault Agent must be installed on the same host containing the audit directory in case of directory trails.
To configure an audit trail for a target:
-
Create a new target.
-
Click the Targets tab. The Targets tab in the left navigation menu is selected by default.
-
Click on the name of the target for which the audit trail needs to be added.
- Under Audit Data Collection, select
Add.
The Add Audit Trail dialog appears.
-
Select the value in the Audit Trail Type menu based on the target.
Note:
For complete details on the audit trail types, see Plug-ins That are Shipped with Oracle Audit Vault and Database Firewall.
There are different audit trail types available in the drop down list. Select one of the following:
-
CUSTOM
-
DIRECTORY
-
EVENT LOG
-
NETWORK
-
SYSLOG
This trail type can collect from either
syslog
orrsyslog
files. If both are present, you must give the exact Trail Location in the following step ahead, if you want to collect audit data fromrsyslog
files. See Table C-25 for details.Note:
Ensure that records generated by rsyslog have the same time zone information as the Audit Vault Agent running on the collection host. -
TABLE
-
TRANSACTION LOG
See Table C-19 for details on which types of audit trails can be collected for a specific target type.
-
-
In the Trail Location field, enter the location of the audit trail on the target computer. The trail location depends on the type of target.
For example,
unified_audit_trail
.For complete details on the target type and trail location, see Plug-ins That are Shipped with Oracle Audit Vault and Database Firewall.
Note:
If you selectDIRECTORY
orTRANSACTION LOG
as Audit Trail Type, then the trail location must be a directory mask. See Table C-25 for important details. -
In the Agent Host field, select the host computer where the Audit Vault Agent is deployed.
-
The Agent Plug-in field automatically contains the appropriate plug-in name.
-
Click Save.
The audit trail is added to the list on the Audit Trails tab. The collection status displays a red circle initially. This indicates the status of the trail as stopped. The audit trail starts automatically shortly after it is added.
See Also:
-
Summary of Data Collected for Each Audit Trail Type for descriptions of data collected.
-
Audit Trail Locations for supported trail locations.
7.4.3 Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server
Lean about stopping, starting, and setting up autostart of audit trails in Oracle Audit Vault Server.
An audit trail starts automatically shortly after you add it. To start an audit trail, the Audit Vault Agent must be running on a host computer.
Audit trails that are started will automatically restart if the Audit Vault Agent is restarted, or updated due to an Audit Vault Server update.
An audit trail can go down at times such as when the target goes down temporarily. With Autostart, the system automatically attempts to restart an audit trail if it goes down. Autostart is normally enabled unless you have manually stopped the trail. You can set parameters on when and how many times the system attempts Autostart using the AVCLI utility.
To start or stop audit trail collection for a target:
7.4.4 Checking the Status of Trail Collection in Audit Vault Server
Learn about checking the status trail collection in Audit Vault Server.
To check the status of audit trails:
-
Log in to the Audit Vault Server console as an administrator.
-
Click the Targets tab. The Targets tab in the left navigation menu is selected by default.
-
Click Audit Trails tab in the left navigation menu.
It lists targets that have audit trails configured. Check the Collection Status column. The status can be one of the following:
-
Idle - Trail is up and running, no new audit data to collect. In this state, the trail is waiting for the target to generate new audit data.
-
Starting - Collection process is starting.
-
Collecting - Trail is currently actively collecting audit data.
-
Stopping - Collection process is stopping.
-
Stopped - Trail is currently stopped.
-
Recovering - Trail is recovering after it has been stopped previously. The trail was stopped before updating the checkpoint for the records collected. In the recovery state, the trail reads records starting from the current checkpoint and filter out the duplicate records which were already read. The recovery state can take a while depending on the server load.
-
Unreachable - A heartbeat timeout has occurred, indicating that a heartbeat message has not been received from the trail in the last 30 minutes. This status is temporary unless the trail has crashed. The Audit Vault Server checks the status of the audit trail. It attempts to check the status 5 times (by default) in Oracle AVDF releases 20.1 to 20.6. In Oracle AVDF release 20.7 and onwards, the Audit Vault Server attempts 20 times (by default) to reach the audit trail before concluding it is
Unreachable
. -
Archive data files are required (link) - If you see this link, it means a new audit trail contains expired audit records that must be archived, and that the required archive data files are not available.
The Trail Autostart Details column indicates whether autostart is enabled for a trail, and whether there have been attempts to restart a failed audit trail (for example, if a target goes down temporarily).
-
Tip: You can sort and filter the audit trail list.
Note:
- To view audit trails status for a specific agent host, click the name of the trail.
- If an audit trail fails to start, then you can get more information by looking at the Error Message column.
Checking Downtime History of the Trail
Audit Vault Server console displays the current status of the trail. Starting Oracle AVDF 20.6, the Audit Vault Server console maintains record of the trail downtime. It also displays the reason for the downtime. This information is available in the Downtime Report. This report contains downtime information of every trail and a cumulative downtime report of all the trails in the Audit Vault Server. It captures the intervals during which the specific trail may have gone down either due to an error, or if it was manually stopped through the Audit Vault Server console, or it had changed status to one of the following:
Status | Description |
|
If this status is seen, then the trail has gone down due to an error. In this case there is an additional column Error Message that specifies the reason the trail was stopped. |
|
This status is dynamically calculated and is seen when the trail is unable to connect to the Audit Vault Server for more than 30 minutes. |
|
If this status is seen, then the trail downtime data has been purged as the trail is down for more than the specified retention period. |
|
The trail has stopped and is not collecting data. |
|
The trail is about to start with collection. |
|
The trail is about to stop collecting data. |
|
The trail is active and collecting data. |
|
The trail is idle and not collecting data. |
|
The trail is in recovering mode. |
Note:
Not all the status information is available in the reports.To capture downtime report for the trail and to view the history of the trail, follow these steps:
- Log in to the Audit Vault Server console as an administrator.
- Click the Targets tab.
- Click Audit Trails in the left navigation menu.
- Select the trails for which the downtime report needs to be generated.
- Click Downtime button. The downtime report for the selected trails is displayed. Use the filter option, download the report, or click the back button to navigate to the Audit Trails tab.
The downtime of the Audit Vault Agent, the specific time as to when the Agent went down, the duration for which the data has not been captured, and the reason for the Agent going down is also made available in the reports.
Note:
- This downtime data is available, archived, and purged like any other data managed by Oracle AVDF. By default in release 20.6, the downtime data is available for a period of one month and is purged after that.
- The history of trails configured prior to upgrade to Oracle AVDF 20.6 is not captured or available.
- The report for new trails configured after upgrade to Oracle AVDF 20.6 is available.
- Data for the trails configured after upgrade to Oracle AVDF 20.6 is available from the time the trail was started.
7.4.5 Audit Collection Best Practices
Learn about best practices for audit collection.
- There may be too many records (more than a million) in a table audit trail. This can slow down audit data collection. This in turn results in reduced throughput of the table audit trail.
- In case of directory trail, there may be too many files (more than a thousand) with a size of more than 1GB. This can slow down audit data collection. This in turn results in reduced throughput of the directory trail.
- It is advised to periodically purge the records which have been already read by the audit trail. For some targets, Audit Vault Agent contains scripts for cleanup. Refer to Audit Trail Cleanup for more information. In case of remaining targets where the records have already been read by the audit trail, it can be manually cleaned up.
For directory audit trail and transaction log audit trail, if the agent user does not have read permission on audit files, then provide agent user read permission on the audit files by running the following commands.
Operating System | Command |
---|---|
Linux |
|
Solaris |
|
AIX/HP-UX | Add the agent user to the group which has read permission on the audit data. |
7.4.6 Handling New Audit Trails with Expired Audit Records
Learn about handling new audit trails with expired audit records.
With established audit trail collection, audit data is retained in Oracle Audit Vault Server for the Months Online period of a retention (or archiving) policy. After this period, the data files are made available for archiving. The data is then kept in archives for the Months Archived period of the retention policy, and is available to retrieve to the Audit Vault Server during that period.
However, when you add a new audit trail to an existing target, the audit data collected may contain records that fall into the Months Archived period in the retention policy assigned to this target. That is, the online period for these audit records has expired and they should be archived according to the retention policy.
In this case, Oracle Audit Vault and Database Firewall attempts to automatically archive these expired records during the new audit trail collection. In some cases, you may need to make the archive data files available in order for the audit trail to complete collection.
When collecting a new audit trail for an existing target, follow these instruction if you see an Archive data files are required link in the Collection Status of the audit trail.
To make archive data files accessible:
See Also:
- Defining Archive Locations to check the required data files are available in the archive location and the connection to the location is established.
- About Archiving and Retrieving Data in Oracle Audit Vault and Database Firewall
- Using Audit Vault Server Console
7.4.7 Deleting an Audit Trail
Learn how to delete an audit trail.
- Log in to the Audit Vault Server console as an administrator.
- Click the Targets tab.
- In the left navigational menu, click Audit Trails.
- Select the audit trails that you want to delete and then, if necessary, click Stop to stop the audit trail.
- Select the audit trails that you want to delete, and then click Delete.
7.4.8 Converting Audit Record Formats for Collection
You can use special tools to convert audit record formats so that Audit Vault and Database Firewall can collect these records.
7.4.8.1 Prerequisites for Converting Oracle Audit Vault Record MySQL Formats
Learn about the prerequsites for converting Oracle Audit Vault record MySQL formats.
Before you begin the format conversion process, ensure that you have completed the following tasks.
-
Register the MySQL target in the Audit Vault Server. See Registering or Removing Targets in Audit Vault Server.
-
Deploy the Audit Vault Agent on the MySQL host machine. See Deploying the Audit Vault Agent.
7.4.8.2 Running the XML Transformation Utility for MySQL Audit Formats
Learn how to run the XML transformation utility for MySQL audit formats.
Note:
This procedure is only applicable for the old audit format. The default audit format of MySQL 5.5 and 5.6 is old. The default audit format of MySQL 5.7 is new. The audit format can be changed by modifying the configuration on MySQL Server.
To run the XML Transformation Utility:
7.4.8.3 Converting Binary Audit Files to ASCII Format for IBM DB2
Learn about converting binary audit files to ASCII format for IBM DB2.
Note:
It is recommended that you extract audit log files for each database and each instance in a separate directory. You must configure separate audit trails for each database and each instance in Oracle AVDF.
To schedule the script to run automatically, follow these guidelines:
-
UNIX: Use the
crontab
UNIX utility. Provide the same information that you would provide using the parameters described previously when you normally run the script. -
Microsoft Windows: Use the Windows Scheduler. Provide the archive directory path (for release 9.5 databases only), extraction path, and target database name in the scheduled task.
7.4.9 Configuring Audit Trail Collection for Oracle Real Application Clusters
You can configure audit trail collection for Oracle Real Application Clusters (Oracle RAC).
Configure a SCAN listener for the RAC and use the SCAN listener IP as the single IP during target registration.
To configure Audit Trail collection for Oracle Real Application Clusters (RAC), follow these guidelines.
Audit Trail Type | Number of Audit Trails |
---|---|
|
To configure table trail audit data collection from Oracle RAC environment, 1 audit trail is sufficient. |
|
To configure directory audit data collection from Oracle RAC environment, separate audit trails are required. The trail location must be different directories in the shared storage of the Oracle RAC environment. |
|
To configure Transaction Log audit data collection from Oracle RAC environment, 1 audit trail is sufficient. |
See Also:
Adding Audit Trails in Audit Vault Server to configure an audit trail.
7.4.10 Configuring Audit Trail Collection for CDBs and PDBs
Learn about configuring audit trail collection for CDBs and PDBs.
Oracle Database can work as Container Database (CDB) or Pluggable Databases (PDB). A PDB is a portable collection of schemas, schema objects, and nonschema objects that appears to an Oracle Net client as a non-CDB. All Oracle databases before Oracle Database 12c are non-CDB.
The PDB and CDB can be registered as targets. Oracle Audit Vault and Database Firewall supports CDB and PDB level audit collection. To collect audit data from multiple PDB instances within a CDB, adopt either one of the following approaches:
Approach 1: Create a separate target for each PDB instance and create audit trail
for each PDB target, which collects data from UNIFIED_AUDIT_TRAIL
table.
Approach 2: Create one target for the CDB and create audit trail which collects
data from CDB_UNIFIED_AUDIT_TRAIL
table.
Note:
- In Oracle AVDF 20 data will be collected from
CDB_UNIFIED_AUDIT_TRAIL
, only if all the PDBs are up and running. CDB_UNIFIED_AUDIT_TRAIL
provides audit records from all PDB instances in a multitenant environment. The performance of audit collection fromCDB_UNIFIED_AUDIT_TRAIL
is lower than audit collection fromUNIFIED_AUDIT_TRAIL
of every PDB instance. If the number of audit records generated per day inCDB_UNIFIED_AUDIT_TRAIL
is higher than 8 million, then configure audit collection fromUNIFIED_AUDIT_TRAIL
of every PDB instance.
To configure Audit Trail collection for CDB or PDB, follow these guidelines:
Audit Trail Type | Guidelines |
---|---|
|
Note: Audit collection from
|
|
Note: If you are using a multitenant container database (CDB) in Oracle Database 12c, then for a CDB you must register a target for the CDB as well as for every PDB. |
CDB Trail Enhancement in Oracle AVDF 20.2
In Oracle AVDF 20.2.0.0.0 (or 20 RU2), audit data is collected from
CDB_UNIFIED_AUDIT_TRAIL
for PDBs that are up and running, even if
some of the PDBs are down. When a PDB is down, the data corresponding to the PDB with
status down is not visible in CDB_UNIFIED_AUDIT_TRAIL
. When the PDB
which was earlier down comes up, then the data corresponding to the specific PDB is
collected from CDB_UNIFIED_AUDIT_TRAIL
.
If any PDB is down, then the last archive timestamp is not set on the
CDB_UNIFIED_AUDIT_TRAIL
, even if other PDBs are up and running.
Hence those records that have already been read by the audit trail are not purged from
the CDB_UNIFIED_AUDIT_TRAIL
and this can lead to severe performance
degradation of the audit trail.
If there are any PDBs that are permanently taken down or taken down for few days, then
they must be specified in the AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST
target attribute. The value of the AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST
target attribute is a list of PDBs separated by a colon. For example,
PDB1:PDB2:PDB5
.
If a PDB is down, but is present in the
AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST
, then the audit trail ignores
the specific PDB if it is down and sets the last archive timestamp on the
CDB_UNIFIED_AUDIT_TRAIL
if all the other PDBs are up and
running.
Audit data collection from PDBs which are mentioned in the
AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST
is not completely accurate.
Some of the audit records for these PDBs may be missed. It is also possible that the
data is purged from these PDBs, depending on when the last archive timestamp was
set.
If there is a PDB with status down, that was present in the
AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST
, and has to brought up, then
first remove it from AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST
. Wait for 10
minutes so that the audit trail reads and processes the updated
AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST
attribute. After approximately
10 minutes, bring up the PDB. This ensures that all future records are successfully
collected from this PDB without any data loss.
See Also:
Adding Audit Trails in Audit Vault Server to configure an audit trail.
7.5 Configuring Database Firewall Monitoring Points
Learn about configuring Database Firewall monitoring points.
Note:
If you are using Transparent Application Failover (TAF), Fast Application Notification (FAN), or the Oracle Notification Service (ONS), then SQL commands are not sent through this channel. There is no need to route them through Oracle Database Firewall. ONS communications bypass the Database Firewall and connect directly to the ONS listener. ONS communications, including destination host and port, are configured in the ons.config properties file located on the ONS server.
7.5.1 About Configuring Database Firewall Monitoring Points for Targets
Learn about configuring Database Firewall monitoring points for the target.
If you are monitoring databases with a Database Firewall, you must configure one monitoring point for every target database that you want to monitor with the firewall. The monitoring point configuration allows you to specify:
- Firewall monitoring mode
- Database Firewall used for the monitoring point
- Identify the target database being monitored
- Network traffic sources to the database
Oracle Database Firewall can be deployed in the following modes:
-
Monitoring (Out-of-Band) - In this deployment mode, Oracle Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements.
- Monitoring (Host Monitor) - In this deployment mode, Oracle Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements.
-
Monitoring / Blocking (Proxy) - In this deployment mode the Database Firewall can monitor, alert, block, and substitute SQL statements.
Before configuring monitoring points, configure network traffic sources as part of database firewall configuration.
7.5.2 Creating and Configuring a Database Firewall Monitoring Point
Learn about creating and configuring Database Firewall monitoring points.
Configure Database Firewall monitoring points using the Audit Vault Server console. If you have configured a resilient pair of Audit Vault Servers, configure the monitoring points on the primary server.
Prerequisites
- The Database Firewall instances must be paired before configuring the monitoring points, targets, and policies.
- Ensure that you have configured traffic sources on the Database Firewall you plan to use for this monitoring point. See Configuring the Database Firewall and Its Traffic Sources on Your Network for more information.
Note:
When you use the Monitoring / Blocking (Proxy) mode, you must configure any external devices that use IP or MAC address spoofing detection rules such that they ignore database IP or MAC address changes made by the Database Firewall.
See Also:
-
High Availability in Oracle AVDF for details on configuring a resilient pair of servers.
-
Oracle Audit Vault and Database Firewall Concepts Guide for more information on different modes.
-
Configuring Network Settings for more information on traffic sources.
7.5.3 Modifying a Database Firewall Monitoring Point
After you create a Database Firewall monitoring point, you can modify the settings, enable database response monitoring, monitor native network encrypted traffic for Oracle Database, and host monitoring.
7.5.4 Starting, Stopping, or Deleting Database Firewall Monitoring Points
Learn about starting, stopping, and deleting Database Firewall monitoring points.
7.5.5 Viewing the Status of Database Firewall Monitoring Points
Learn about viewing Database Firewall monitoring point status.
7.5.6 Finding the Port Number Used by a Database Firewall Monitoring Point
Learn about finding Database Firewall monitoring point port numbers.
7.5.7 Configuring a Database Firewall to Connect to an Oracle Autonomous Database
Learn how to configure a Database Firewall to connect to an Oracle Autonomous Database.
7.6 Configuring Stored Procedure Auditing (SPA)
Learn about configuring stored procedure auditing (SPA).
Stored procedure auditing (SPA) enables Oracle Audit Vault and Database Firewall auditors to audit changes to stored procedures on target databases. Oracle Audit Vault and Database Firewall connects to the database server at scheduled intervals and discovers any changes or additions that have been made to stored procedures.
To enable SPA, you simply configure the user account privileges necessary for Oracle Audit Vault and Database Firewall to do stored procedure auditing on a target. Oracle Audit Vault and Database Firewall provides scripts for setting up these privileges. Run the scripts specific to the target type.
An Oracle Audit Vault and Database Firewall auditor can view changes to stored procedures in reports if the auditor enables Stored Procedure Auditing in the target configuration.
7.7 Configuring Database Firewall for Databases That Use Native Network Encryption
Learn about monitoring native network encrypted traffic for Oracle Database.
You can monitor native network encrypted traffic for Oracle Database to obtain the name of the database user, operating system, and client program that originated a SQL statement, if this information is not available from the network traffic. This information is then made available in the reports.
Note:
In order to fetch the session information successfully, the target database should have configuration to do a reverse DNS lookup under certain cases where client machine is a Windows instance or uses network host names.To configure monitoring of native network encrypted traffic for Oracle Database, follow the steps in this section.
7.7.1 Step 1: Apply the Specified Patch to the Oracle Database
Learn how to apply the specified patch to Oracle Database.
Note:
This step is not required for Oracle Database versions 11.2.0.4 or later. For all versions prior to 11.2.0.4, apply the patch specified in this section on the Oracle Database that is using Network Encryption.To apply the patch:
7.7.2 Step 2: Run the Oracle Advance Security Integration Script
Learn how to run the Oracle Advance Security integration script.
To run the Network Encryption integration script:
7.7.3 Step 3: Provide the Database Firewall Public Key to Oracle Database
Learn how to provide Database Firewall public keys to Oracle Database.
In order to decrypt traffic using native network encrypted traffic for Oracle Database, you must provide the Database Firewall public key.
To provide the public key to the Oracle Database:
- Log in to the Audit Vault Server console as administrator.
- Click Database Firewall tab.
- Click the specific Database Firewall instance from the list.
- Click Oracle Native Encryption under Configuration section.
-
Click Copy Key to copy the public key and paste it into a text file. For example,
dbfw_public_key.txt
.Each Database Firewall has its own public key. In a case where you have Database Firewall high availability or monitoring point resiliency, when you have more than one Database Firewall monitoring this target, each Database Firewall public key must be copied and appended to the
dbfw_public_key.txt
file.Note: For security purposes the
dbfw_public_key.txt
file must have the same access permissions as thesqlnet.ora
file on the Oracle Database server. -
Modify the
sqlnet.ora
file in the Oracle Database to include the public key and to require native network traffic encryption:-
Put the file you created in the earlier step on the Oracle Database server, preferably in the same directory as the
sqlnet.ora
file. -
Open the
sqlnet.ora
file and append the following parameters (in this example the public key file isdbfw_public_key.txt
):SQLNET.ENCRYPTION_TYPES_SERVER=AES256
SQLNET.DBFW_PUBLIC_KEY="/
path_to_file
/dbfw_public_key.txt"
SQLNET.ENCRYPTION_SERVER=REQUIREDNote:
- If the
sqlnet.ora
file contains the optional parameterSQLNET.ENCRYPTION_CLIENT
, its value must not beREJECTED
. Otherwise, an error will occur. - The parameter
SQLNET.ENCRYPTION_SERVER
must never have the valueREJECTED
.
- If the
-
Save and close the
sqlnet.ora
file.
-
See Also:
Oracle Database Security Guide for more information on network encryption.
7.7.4 Step 4: Enable Native Network Encrypted Traffic Monitoring for Oracle Database
You can enable native network encrypted traffic monitoring for Oracle Database.
Follow the procedure in Monitor Native Network Encrypted Traffic Through Database Firewall for Oracle Databases to complete the configuration for Oracle Databases that use network encryption.
7.8 Configuring Advanced Settings for Database Firewall
Learn about configuring database connection details under advanced options.
7.8.1 About Native Network Encryption for Oracle Databases
Learn about using native network encryption for Oracle Databases.
If you are using the Database Firewall to monitor an Oracle Database target that uses network encryption, then you must use native network encryption monitoring in order to decrypt statements sent to, and responses received from, that database so they can be analyzed.
Limitations on Decryption of Oracle Database Statements
Configuring Audit Vault and Database Firewall to decrypt traffic with Network Encryption has the following limitations:
- There is no statement substitution in Audit Vault and Database Firewall when Network Encryption checksum is used.
- There is no support for Network Encryption RC4 cipher.
- Supported versions of Oracle Database.
- Database Firewall doesn't support running the Oracle Advance Security Integration Script on root container databases (CDB$ROOT). It also doesn't monitor and apply policies on traffic with native network encryption for root container databases (CDB$ROOT).
7.8.2 Monitor Native Network Encrypted Traffic Through Database Firewall for Oracle Databases
Learn how to enable monitoring of native network encrypted traffic through Database Firewall for Oracle Databases.
This functionality enables Database Firewall to monitor native network encrypted traffic for supported Oracle Database targets.
Note:
Native Network Encrypted traffic monitoring was earlier known as Database Interrogation.Prerequisite
Log in to the Audit Vault Server console as administrator. See Using Audit Vault Server Console for more information.
To enable this functionality for a Database Firewall monitoring point:
7.8.3 Disabling Encrypted Traffic Monitoring for Oracle Databases
Learn about disabling encrypted traffic monitoring for Oracle Databases.
You can temporarily disable encrypted traffic monitoring. Oracle AVDF saves the configuration information that you have created for the next time that you want to enable it.
To disable encrypted traffic monitoring:
7.8.4 Retrieve Session Information for Non Oracle Databases
Learn how to obtain session information for non Oracle databases.
You can retrieve session information for non Oracle databases like Microsoft SQL Server and Sybase SQL Anywhere database to obtain the name of the database user, operating system, and client program that originated a SQL statement. Enable this functionality only if this information is not available from the network traffic. This information is then made available in the reports.
While configuring this functionality choose the field Retrieve session information from target DB in the Advanced tab.
7.8.4.1 Setting Permissions to Retrieve Session Information in Microsoft SQL Server
Learn about retrieving session information in Microsoft SQL Server.
7.9 Monitoring TLS Encrypted SQL Traffic
Learn how to enable monitoring of TLS encrypted SQL traffic between the database clients and Oracle Database.
Note:
- This functionality does not support database clients using PKI authentication.
- This functionality is not supported for Oracle Real Application Cluster (RAC) as a target in Oracle AVDF release 20.7.
- This functionality is supported for Oracle Real Application Cluster (RAC) as a target starting with Oracle AVDF release 20.8.
- The Database Firewall acts as a proxy and terminates TLS session from the database clients. In all cases, Database Firewall becomes the client for the database server.
- Native Network Encryption is disabled in case this functionality is enabled.
7.9.1 Using Default Self Signed Certificates Created During Monitoring Point Creation
Learn how to use self signed certificates created by default when creating a Database Firewall monitoring point.
Starting with Oracle AVDF release 20.7, Database Firewall supports monitoring of TLS encrypted SQL traffic between the database client and Oracle Database. Database Firewall acts a TLS proxy terminating the session from the database client and creating a new TLS outbound session to the database server. Different TLS levels can be set for:
- Inbound connection from the database client to Database Firewall
- Outbound connection from Database Firewall to Oracle Database
TLS Level-4 is the strictest and set by default. Mutual authentication is enabled by default for both inbound and outbound connections.
Database Firewall decrypts the network traffic from the database clients, extracts SQL traffic, and acts on the SQL statements based on the configured policies. It creates a new TLS session to the database server if the traffic needs to be passed on.
Note:
For production instances it is recommended to use third party CA signed certificates than self signed certificates as per your organizational policy.Follow these steps to enable TLS encrypted traffic monitoring capability for a target database:
7.9.2 Configuring Mutual Authentication for Inbound or Outbound TLS Communication
Learn how to configure mutual authentication for inbound or outbound TLS communication between the database clients and Oracle Database.
You can configure mutual authentication for TLS communication between:
- Database client to Database Firewall (inbound connection)
- Database Firewall to Oracle Database (outbound connection)
The configuration file for the Database Firewall monitoring point is
/var/dbfw/va/x/etc/appliance.conf
. In this case
x
is the Database Firewall monitoring point identifier. The
database client always authenticates the associated Database Firewall it is
connecting to.
Follow these steps:
7.9.3 Using External Certificates Signed by Certificate Authority
Learn how to use certificates signed by an external CA in Database Firewall.
You can use a certificate signed by an external Certification Authority (CA) based
on your organization policy. Starting with Oracle AVDF release 20.7, Database
Firewall supports external CA signed certificates for inbound and outbound TLS
connections. Database Firewall provides a utility
(config-pki_identity
) to generate a CSR (Certificate
Signing Request) which can be signed externally.
Follow these steps to use one pair of externally signed certificates for all Database Firewall monitoring points:
7.9.4 Disabling Mutual Authentication for Inbound or Outbound TLS Communication
Learn how to disable mutual authentication for inbound or outbound TLS communication between the database clients and Oracle Database.
You can disable mutual authentication for TLS communication between:
- Database client to Database Firewall (inbound connection)
- Database Firewall to Oracle Database (outbound connection)
Mutual authentication can be optionally disabled for inbound or outbound
TLS communication. The configuration file for the Database Firewall monitoring point
is /var/dbfw/va/x/etc/appliance.conf
. In this case
x
is the Database Firewall monitoring point identifier. The
database client always authenticates the associated Database Firewall it is
connecting to.
Follow these steps to disable mutual authentication for inbound TLS communication:
-
Modify the following value in the configuration file
/var/dbfw/va/x/etc/appliance.conf
:TLS_CLIENT_AUTH="0"
-
Import the Database Firewall monitoring point inbound certificate (
/usr/local/dbfw/va/xx/pki/in/in.crt
or/usr/local/dbfw/va/in.crt
) into the SQL client's key store as a trusted CA certificate.Note: For Oracle SQL clients this involves importing the Database Firewall monitoring point CA certificate into the SQL client's wallet. Refer to the SQLNET Administrator Guide for complete information. For other (non Oracle) SQL clients, refer to the respective database documentation.
Database Firewall authenticates the database it is connecting to. Follow these steps to disable mutual authentication for outbound TLS communication:
7.9.5 Configuring a TLS Proxy for an Oracle Real Application Clusters Database
Learn about additional steps that are required to configure a TLS proxy for Oracle Real Application Clusters (Oracle RAC).
Oracle AVDF release 20.7 supports monitoring TLS encrypted SQL traffic between the database clients and Oracle Database. Starting with Oracle AVDF release 20.8, this functionality is supported for Oracle RAC.
Prerequisites
- The database client must have a wallet that is configured with credentials to communicate with the Oracle RAC database instance.
- The Oracle RAC database instance must have a wallet that is configured to communicate with the client.
- The client and the Oracle RAC database instance must be able to connect by using TCPS.
- You must have an externally created Oracle wallet for the Database Firewall to use, and it must be configured with credentials to communicate with the Oracle RAC database instance. See Managing Oracle Wallets with the orapki Utility for creating and managing oracle wallets.
7.9.6 (Optional) Enabling Common Name Verification for the Database Server
In addition to verifying that the target database's certificate is valid, you can verify the database server's common name from the database certificate. This verification matches the server's common name against a set of allowed common names that you configure.
To enable this additional check of the database certificate's common name, follow these steps:
7.10 Configuring and Using Database Response Monitoring
Learn about configuring and using database response monitoring.
7.10.1 About Database Response Monitoring
Learn about database response monitoring.
Enabling the Database Response Monitoring feature enables Oracle Database Firewall to record responses that the target database makes to login requests, logout requests and SQL statements sent from database clients, as shown in Figure 7-1. This feature allows you to determine whether the database executed logins, logouts and statements successfully, and can provide useful information for audit and forensic purposes.
Figure 7-1 illustrates the process flow of database response monitoring.
The Oracle Audit Vault and Database Firewall auditor can view database responses in audit reports.
Database Response Monitoring records database responses for all SQL statements, logins, and logouts that are logged by the Database Firewall policy.
The information recorded includes the response interpreted by Oracle Audit Vault and Database Firewall (such as "statement fail"), the detailed status information from the database, and the database response text (which may be displayed in the database client).
Note:
The Event Status value in the reports is displayed only if Database Response Monitoring is enabled for the respective monitoring point.7.11 Securing the Agent and Oracle Database Target Connection
Learn how secure the Agent and Oracle Database target connection.
If the target has been setup to accept TCPS/SSL connections, then follow these steps to configure the Agent:
-
Ensure that in the target's
sqlnet.ora
file, the following parameters are set:-
SQLNET.ENCRYPTION_SERVER
=REQUESTED
,REJECTED
, or the default,ACCEPTED
. -
SQLNET.CRYPTO_CHECKSUM_SERVER
=REJECTED
or the default,ACCEPTED
-
-
Log in to the Audit Vault Server console as an administrator.
-
Click the Targets tab.
-
In the left navigation menu, select Targets.
-
Select the name of the target that you want to modify.
-
In the target page, do the following:
-
In the Audit Data Collection section, enter the details in Host Name/IP Address, choose TCPS protocol, Server DN, and upload the wallet file.
-
Or alternately, select the Advanced option, choose TCPS protocol, upload the wallet file, and then in the Target Location field, provide the TCPS connection string.
For example:
jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=host_ip)(PORT=port_number))(CONNECT_DATA=(SERVICE_NAME=service_name)(SERVER=DEDICATED))(SECURITY= (SSL_SERVER_CERT_DN="dn")))
-
Click Save.
-
See Also:
-
Oracle Database Net Services Reference for more information about the parameters.
7.12 Upgrading the Target Database
If you're upgrading the target database, perform the following tasks to ensure that Oracle Audit Vault and Database Firewall (Oracle AVDF) continues to function properly.
-
If the Database Firewall is deployed in Monitoring/Blocking (Proxy) mode, then stop the monitoring point of the target.
See Starting, Stopping, or Deleting Database Firewall Monitoring Points.
-
Ensure that there are no changes to the database listener ports.
If the database listener ports have changed, then make the corresponding change to the monitoring point and restart the network trail.
-
If the target database details like the IP address and host name haven't changed, then after the target database upgrade is complete, enable the monitoring point. The traffic should flow through the monitoring point as before.
See Starting, Stopping, or Deleting Database Firewall Monitoring Points.
-
Run the script on the target database to grant privileges after the database upgrade is complete.