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 Discovering and Registering Targets and Creating Groups
Learn about discovering and registering targets and creating groups.
7.2.1 Discovering Databases for Target Registration
Starting in Oracle AVDF 20.12, super administrators
can
import XML files resulting from the Nmap scan command of specified IP address and port
ranges to determine which Oracle, Microsoft SQL, MySQL, DB2, PostgreSQL, or Sybase databases
in your database fleet are yet to be registered with AVDF.
7.2.1.1 About Discovering Databases for Target Registration
Starting in Oracle AVDF 20.12, super administrators
can
import the XML file resulting from the Nmap scan command of specified IP address and port
ranges to identify databases available for registration with AVDF. Discovered databases can
then be assigned to administrators
for registration with AVDF.
If you have many databases in your fleet, it may be difficult to determine which ones are not yet registered with Oracle AVDF. The Database Discovery feature introduced in Oracle AVDF 20.12 allows you to scan specified IP address and port ranges using Nmap commands to determine which databases haven't been registered with AVDF. The results of the Nmap scan will inform you which Oracle, Microsoft SQL, MySQL, DB2, PostgreSQL or Sybase databases have not been registered as targets.
The XML file that is the output of the Nmap scan command is the list of
un-registered databases. This file can be imported to the Audit Vault Server console by
a super administrator
and each database can be either hidden from
future scans or assigned to an administrator
for target registration.
7.2.1.2 Executing Nmap Scan Commands
In order to use the Database Discovery feature available in Oracle AVDF
starting in 20.12, you need to execute the Nmap scan command to discover un-registered
databases in your database fleet. A super administrator
will need to upload
the results of the Nmap scan command to the Audit Vault Server.
Prerequisites
- Contact your network administrator or check your organization's policies before executing Nmap scan command.
- Download the Nmap command tool.
Note:
Only Nmap version 7.92 and 7.94 are supported.
Procedure
- While on a Windows or Linux platform, run the following command on
a host in your
network:
nmap -sV -n -p T:<p1-p2> <ip range> --host-timeout <time in minutes> -oX <xml filepath>
Attributes:- sV - Optional, Probes open ports to determine service/version information.
- n - Optional, No DNS resolution. This option slashes scanning time
- p T:<p1 to p2> - This option scans TCP
protocol for port range p1 to p2.
If you do not know the port range, it is recommended to scan the complete port range of 0 - 65536.
- IP Range - IP range that need to scanned. One example is given above, but for more type of ranges refer to the Nmap command documentation
- host-timeout - Enter a time in minutes after which the scan on the host will stop. Some hosts simply take a long time to scan. This may be due to poorly performing or unreliable networking hardware or software, packet rate limiting, or a restrictive firewall.
- oX - XML output file location
For example:nmap -sV -n -p T:1430-6607 10.89.89.0-10.89.89.255 --host-timeout 2m -oX /tmp/tmp.xml
- Ensure that the XML file is accessible by a
super administrator
.
Related Topics
7.2.1.3 Importing the XML File for Database Discovery
as a Super Administrator
After successfully running the Nmap scan command, the XML file needs to be
imported to the Audit Vault Server Console by a super administrator
.
Databases can then be assigned to administrators
for
registration.
-
Log in to the Audit Vault Server Console as a
super administrator
. - Click the Targets tab.
- In the left menu, click Database Discovery.
- Click Import Nmap XML.
- Click Choose File.
- Navigate to location of the Nmap output file.
- Click Save to import the XML file.
- After the XML has been successfully imported, delete the XML file from your local system.
A super administrator
will be able to see the list of
databases discovered in the Nmap scan and their registration status with AVDF in
Database Discovery in the Audit Vault Server Console.
Related Topics
7.2.1.4 Assigning Databases for Registration in
Database Discovery as a Super Administrator
After importing the XML file, a super administrator
can see
the list of discovered databases and their registration status with AVDF. A super
administrator
can then assign the unregistered databases to other
administrator
users for target registration.
-
Log in to the Audit Vault Server Console as a
super administrator
. - Click the Targets tab.
- In the left menu, click Database Discovery.
- Select the database(s) you want to assign to an
administrator
for registration. - Click Assign admin.
- Select the
administrator
user to assign the database(s) to.Select Select in the drop down of users if you'd like to unassign the database(s).
- Click Save.
7.2.1.5 Registering Assigned Databases in Database Discovery
If you are an administrator
with assigned databases or a
super administrator
you can register discovered databases with AVDF
directly from Database Discovery.
- Log in to the Audit Vault Server
Console as a
super administrator
or anadministrator
. - Click the Targets tab.
- In the left menu, click Database Discovery.
- Select a database you want to register with AVDF.
You can only select one database at a time.
- Click Register.
- Complete registration of the selected database.
For more information see Registering or Removing Targets in Audit Vault Server.
7.2.1.6 Managing Discovered Databases as a
Super Administrator
Super administrators
can manage the table of discovered
databases by either hiding, showing, or deleting databases.
Show/Hide a Database
A hidden databases won't be listed when the default filters are applied to the table of discovered databases, but can later be shown again.
-
Log in to the Audit Vault Server Console as a
super administrator
. - Click the Targets tab.
- In the left menu, click Database Discovery.
- Optional, apply or remove filters to the table.
- Select the database(s) you want to either show or hide. All
selected databases must all be in the same shown or hidden state.
Note:
Registered databases can't be hidden. - Click Show/Hide.
All selected databases will change to the opposite of their current shown or hidden state.
- Optional, leave a comment as to why the database(s) is to be shown or hidden.
- Click Save.
Delete a Database
A deleted database is removed from the table of discovered databases. However, if an XML file from the Nmap scan is imported again, any removed databases will once again show up in the table.
-
Log in to the Audit Vault Server Console as a
super administrator
. - Click the Targets tab.
- In the left menu, click Database Discovery.
- Optional, apply or remove filters to the table.
- Select the database(s) you want to delete.
- Click Delete.
7.2.1.7 Viewing the Status of the XML Import Job
Once the XML file has been imported, administrators
can
view the details and status of the Database Discovery job.
-
Log in to the Audit Vault Server Console as an
administrator
. - Click the Settings tab.
- Click System in the left navigation menu.
- In the Monitoring section, click Jobs.
- Find a Database discovery job to view the details.
- Click the job details icon to see more details about the job including:
- The user that performed the import
- The time it took for the import to complete
- The number of databases discovered on how many IP addresses
7.2.2 Registering or Removing Targets in Audit Vault Server
Learn about registering and removing targets in Audit Vault Server.
7.2.2.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.2.2 Registering Targets
Before you can begin audit collection and Database Firewall monitoring, you need to register the targets that you want to audit or monitor.
Target Information
- Log in to the Audit Vault Server console as an administrator.
-
Click the Targets tab.
Targets is selected in the left navigation menu by default. This page contains a list of configured targets. You can sort or filter the list of targets.
-
Click Register in the top, right corner.
The following page appears:
- Enter the name and optionally the description for the new target.
- Select the target type from the Type drop-down list. For example, Oracle Database.
-
Starting with Oracle AVDF 20.7, select a policy from the Retention Policy drop-down list.
This list displays all the pre-configured policies and user-defined policies from the Archiving tab. If the super administrator has set a user-defined policy as the default, then that policy is selected by default. Otherwise the default value is 3 month(s) online, 6 month(s) in archive.
Audit Connection Details Tab
Enter the details to connect to the target.
The fields in this section change, depending on the target type. The following list describes all the possible fields and options that may appear.
- Active Data Guard: For Oracle Database targets, select this check box if the target is an Active Data Guard database. For details, see Additional Information for Audit Collection from Oracle Active Data Guard.
- Core (previously Basic) or Advanced: For database targets, select Advanced if you know the connection string. Otherwise, select Core.
- Host Name / IP Address: You can use a
virtual IP address.
Tip:
To improve the accuracy of using Database Discovery (available Oracle AVD 20.12 and later) to discover unregistered databases, host name/IP address should be provided. This will prevent a database from being falsely labeled as unregistered. - Port
Tip:
To improve the accuracy of using Database Discovery (available Oracle AVD 20.12 and later) to discover unregistered databases, port information should be provided. This will prevent a database from being falsely labeled as unregistered. - Service Name: If the target is an Oracle Database, enter the Oracle Database service name or SID.
- Protocol: Select TCP or TCPS.
-
Connection String (previously Target Location): If you selected the Advanced option for a database target, enter the connection string or connection URL for the database. This connection string is required for the Audit Vault Agent to collect audit data, but it's not required to deploy the Database Firewall only.
Note:
- For Oracle Database, the string may look like the
following:
jdbc:oracle:thin:@//<IP address of the Database server host>:<port number>/hrdb
- When you configure Oracle Real Application Clusters (Oracle RAC) as a target for Audit Vault Agent data collection, enter the SCAN listener host name.
- If the target is a Microsoft SQL Server Cluster, you need to set a mandatory collection attribute. See Microsoft SQL Server Plug-in for Oracle Audit Vault and Database Firewall for details.
- For Oracle Database, the string may look like the
following:
- Database User Name (previously
User Name): Enter the name of an existing database
user that has access to the audit data that's generated on the target.
Note:
Only case insensitive database user names are supported for Oracle Database. - Password: Enter the password for the database user.
-
Test Connection: Starting with Oracle AVDF 20.10, for Oracle Database and Microsoft SQL Server targets, click this button to test the connection details that you just entered.
If Oracle AVDF is unable to connect to the host or database, or if there are other issues, an error message displays more details so you can resolve the issue before continuing.
Audit Collection Attributes Tab
Enter audit collection attributes for the target.
-
Click Add to enter the attribute details in the Name and Value columns.
The Audit Vault Agent may require collection attributes for some target types. The following table lists the mandatory collection attributes to enter for different target types.
Target Type Mandatory Collection Attributes Microsoft SQL Server Cluster av.collector.clusterEnabled
PostgreSQL av.collector.securedTargetVersion
Oracle Database for Transaction Log Audit Collection AV.COLLECTOR.TIMEZONEOFFSET
Note: This is the timezone offset of the Oracle Database.
Microsoft SQL Server for Transaction Log Audit Collection AV.COLLECTOR.TIMEZONEOFFSET
Note: This is the timezone offset of the SQL Server database.
MySQL for Transaction Log Audit Collection AV.COLLECTOR.TIMEZONEOFFSET
Note: This is the timezone offset of the MySQL database.
Note:
For PostgreSQL, enable thepgaudit
extension. If this extension is disabled, the audit collection is incomplete and reports will be missing operational details. -
Optionally use the following information to improve the audit collection rate or effectively utilize the resources of the Audit Vault Agent and Audit Vault Server.
Note:
This functionality is not applicable to the Host Monitor Agent or network trails.-
Starting in Oracle AVDF 20.4, you can improve audit collection performance and increase the audit collection rate by setting the
av.collfwk.MULTI_THREADED
attribute totrue
.This applies to all audit trails belonging to the target. While this configuration improves the audit collection rate, the resource (CPU and memory) requirements on the Audit Vault Agent machine also increase. There may also be an increase in resource utilization on the Audit Vault Server. Oracle recommends that you use this configuration if the target audit record generation rate is between 86 and 172 million records per day (or between 1000 to 2000 records per second).
-
Starting In Oracle AVDF 20.5, the Audit Vault Agents automatically choose the best possible configuration for improving audit collection rate. This dynamic multithreaded collector functionality effectively utilizes the resources of the Audit Vault Server and Audit Vault Agent.
This functionality is the default behavior and increases the throughput of the audit trail by increasing the number of threads when the target audit generation rate is high. It also reduces the number of threads when the target audit generation rate is low. This functionality improves the audit collection rate and can support targets generating records up to 2000 per second or 172 million per day. When the target audit generation rate is very high, the resource (CPU and memory) requirements on the Audit Vault Agent machine also increase. There may also be an increase in resource utilization on the Audit Vault Server.
Oracle recommends that you avoid setting the
av.collfwk.MULTI_THREADED
attribute and rely on the dynamic multithreaded collector functionality.If high throughput is not required due to Audit Vault Agent machine resource constraints, then use the single-threaded collector by setting the
av.collfwk.MULTI_THREADED
attribute tofalse
. This is the default behavior in Oracle AVDF 20.5 and earlier.If high throughput is always required due to an audit data generation rate of 86 to 172 million records per day, then use the static multithreaded collector (always uses maximum threads) by setting the
av.collfwk.MULTI_THREADED
attribute totrue
.
-
-
If you're configuring audit collection, click Save to complete the target registration.
To configure Database Firewall monitoring, continue with the remaining steps.
Database Firewall Monitoring Tab
Enter Database Firewall monitoring details.
Note:
- Audit policy retrieval job
- User entitlement retrieval job
- Security assessment
- Sensitive objects retrieval job
- Stored procedure auditing
See Also:
-
Plug-ins That are Shipped with Oracle Audit Vault and Database Firewall
-
Audit Collection Attributes to look up requirements for a specific target type.
-
Using Oracle Database Firewall with Oracle RAC to configure Oracle Database Firewall in an Oracle RAC environment.
-
Working with Lists of Objects in the Audit Vault Server Console to sort or filter the list of targets.
- Monitoring Jobs
- Assessment Reports
7.2.2.3 Modifying Targets
You can modify a target after it's been registered.
Note:
If you change the name of a target, it will have the following affects:- The new name won't appear in Oracle Audit Vault and Database Firewall reports until you restart the Audit Vault Agent.
- There will not be duplicates enteries for the modified target because the
secured_target_id
will remain the same. Additionally, there will be no impact to the audit trails or retention policies for the target. - In the Event log and Alerts table, the target name will not get changed for
old events, but new events will get logged with new target name. So it
recommended that if you are querying the Event log or Reports for any
targets, that you use
secured_target_id
to get all the entries for the target, instead of the target name.
7.2.2.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.3 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.4 Modifying a Target Group
You can modify the contents of a target group or change the target group name and description.
7.2.5 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.6 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 desupported in Oracle AVDF release 20.8
Sybase SQL Anywhere was desupported in Oracle AVDF release 20.8
Microsoft SQL Server 2012 was deprecated in Oracle AVDF 20.12, and it will be desupported in one of the future releases.
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 with Agent-Based Collection |
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
Some target types require credentials for Oracle Audit Vault and Database Firewall (Oracle AVDF) to access them.
If you plan to collect audit data from a target, perform stored procedure auditing (SPA) or 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 AVDF to access the required data.
For database targets, Oracle AVDF provides scripts to configure user account privileges for database target types. For Oracle Database targets, you can download the setup scripts from the Audit Vault Server console by clicking the Target Setup Script button on the Targets tab.
For non-database targets, create a user that has the appropriate privileges to access the audit trail. For example, for a Windows target, this user must have administrative permissions to read the security log.
Note:
Oracle AVDF does not accept user names with quotation marks. For example, "J'Smith" is not a valid user name for an Oracle AVDF user account on targets.
See Scripts for Oracle AVDF Account Privileges on Targets for information on the scripts to configure user account privileges for database target types.
7.4 Preparing Targets for Use With Global Sets (Previously Called Data Discovery)
Starting with Oracle AVDF 20.9, you can create global sets of privileged users and sensitive objects on your Oracle Databases as part of Data Discovery (Oracle AVDF 20.9) or Global Sets (Oracle AVDF 20.10 and later).
In order to create these global sets, privileged users and sensitive objects need to be discovered on your Oracle Database by adding privileges to the database user and gathering statistics, respectively.
Related Topics
7.4.1 Prerequisites for Enabling Global Sets or Data Discovery
Complete these prerequisites before enabling Global Sets or Data Discovery in Oracle Audit Vault and Database Firewall.
- Update Oracle AVDF to release 20.10 or later for Global Sets. Update to Oracle AVDF to release 20.9 for Data Discovery. See Patching Oracle Audit Vault and Database Firewall Release 20 or Upgrading Oracle Audit Vault and Database Firewall from Release 12.2 to Release 20.
-
If you don't have an existing user for auditing, create a user account for Oracle Audit Vault and Database Firewall on the Oracle Database. For example:
SQL> CREATE USER username IDENTIFIED BY password
You will use this user name and password when registering this Oracle Database as a target in the Audit Vault Server.
- Add the Oracle Database as a target in the Audit Vault Server. See Registering or Removing Targets in Audit Vault Server
7.4.2 Managing Privileges for Discovering Privileged Users
Before global Privileged User Sets can be used, download and run the target setup script on the Oracle Database to add privileges to the user as follows.
Downloading Oracle Database Setup Scripts
To download the scripts from the Audit Vault Server console:
- Log in to the Audit Vault Server console as an administrator.
- Click the Targets tab.
- Click the Target Setup Script button.
Download and run the target setup script on the Target Oracle database to add privileges to the user.
You can also access the scripts in the following directory (Linux example):
/opt/avdf/defaultagent/av/plugins/com.oracle.av.plugin.oracle/config/
Enabling User Privileges for Oracle Database for Discovering Privileged Users
Note:
The downloaded zip file contains SQL scripts for several functions, this workflow is only to enable the discovery of privileged user.-
Connect as the
SYS
user with theSYSDBA
privilege. For example:SQL> CONNECT SYS / AS SYSDBA
- Run the following
script:
SQL> @oracle_user_setup.sql username DBSAT_DISCOVERY
Revoking User Privileges for Oracle Database for Discovering Privileged Users
To disable discovery of privileged users for the target, revoke the privileges of the user:
- Connect to the database as the
SYS
user with theSYSDBA
privilege. - Run the following
script:
SQL> @oracle_drop_db_permissions.sql username DBSAT_DISCOVERY
7.4.3 Managing Statistics Gathering for Discovering Sensitive Objects
Before global Sensitive Object Sets can be used, statistics need to be gathered on the Oracle Database.
- Connect as the
SYS
user with theSYSDBA
privilege. For example:SQL> CONNECT SYS / AS SYSDBA
- Run this
command:
exec DBMS_STATS.GATHER_DATABASE_STATS
Alternatively, you can run the
DBMS_STATS
procedure for all objects in a particular schema:exec DBMS_STATS.GATHER_SCHEMA_STATS(schema_name);
Note:
To invoke this procedure you must be the owner of the table, or you need theANALYZE ANY
privilege. For objects owned bySYS
, you must be either the owner of the table, or you need theANALYZE ANY DICTIONARY
privilege or theSYSDBA
privilege.
7.5 Using SQL Firewall with AVDF
Starting with Oracle AVDF 20.13, you can use AVDF to collect SQL Firewall violation logs on Oracle Database 23ai targets.
SQL Firewall is part of the Oracle Database kernel, see Using Oracle SQL Firewall in the Oracle Database Security Guide for detailed information about the capabilities and configuration of SQL Firewall.
Prerequisites
Complete these prerequisites before using SQL Firewall in Oracle Audit Vault and Database Firewall.
- Update Oracle AVDF to release 20.13 or later for SQL Firewall. See Patching Oracle Audit Vault and Database Firewall Release 20 or Upgrading Oracle Audit Vault and Database Firewall from Release 12.2 to Release 20.
-
If you don't have an existing user for auditing, create a user account for Oracle Audit Vault and Database Firewall on the Oracle Database. For example:
SQL> CREATE USER username IDENTIFIED BY password
You will use this user name and password when registering this Oracle Database as a target in the Audit Vault Server.
- Add the Oracle Database 23ai as a target in the Audit Vault Server. See Registering or Removing Targets in Audit Vault Server
Grant Privileges to the AVDF User
Before SQL Firewall can be used with AVDF, download and run the target setup script on the Oracle Database to add privileges to the user as follows.
- Download the Oracle Database setup script:
- Log in to the Audit Vault Server console as an administrator.
- Click the Targets tab.
- Click the Target Setup Script button.
- Run the setup script:
Note:
The downloaded zip file contains SQL scripts for several functions, this workflow is only to provide privileges for SQL Firewall.-
Connect as the
SYS
user with theSYSDBA
privilege. For example:SQL> CONNECT SYS / AS SYSDBA
- Run the following
script:
SQL> @oracle_user_setup.sql username SQL_FIREWALL
Note:
TheSQL_FIREWALL
privilege provides administrator access for all SQL Firewall actions on the Oracle Database. AVDF will use this privilege only for collecting and, if enabled, purging of SQL Firewall violation logs.
-
Start the SQL Firewall Violations Audit Trail
Use the procedure documented in Configuring and Managing Audit Trail Collection to start the SYS.DBA_SQL_FIREWALL_VIOLATIONS
audit trail.
Enable Automated Cleanup of the SQL Firewall Violation Logs
If the av.collector.enable_trail_cleanup
audit collection attribute
is set to yes
, then SQL Firewall violation logs that are over one
week old with be purged from the database automatically. This purge job will run
once every 24 hours, running for the first time after the
SYS.DBA_SQL_FIREWALL_VIOLATIONS
audit trail has been running
continuously for 24 hours.
See Modifying Targets and Audit Trail Cleanup for more information on how to set the audit collection attribute.
Related Topics
7.6 Configuring and Managing Audit Trail Collection
Learn about configuring and managing audit trail collection.
7.6.1 Prerequisites for Adding Audit Trails in Oracle Audit Vault Server
Complete these prerequisites before adding audit trails in Oracle Audit Vault Server.
-
To configure transaction log audit trails for Oracle Database, Microsoft SQL Server, or MySQL install Oracle GoldenGate. See the Transaction Log Audit Data Collection for Oracle Database, Microsoft SQL Server, and MySQL for more information.
-
Add the target in the Audit Vault Server. See Registering or Removing Targets in Audit Vault Server.
-
Register the host machine. This machine is where the Audit Vault Agent is deployed and the target resides for directory trails. See Registering Hosts and Deploying the Agent.
-
If you're deploying the Audit Vault Agent, deploy and start the Audit Vault Agent on the host machine. See Deploying the Audit Vault Agent on Host Computers.
Note:
Starting in Oracle AVDF 20.9, you can use agentless collection instead of the Audit Vault Agent for up to 20 Oracle Database table audit trails. Starting in Oracle AVDF 20.10, you can also use agentless collection for Microsoft SQL Server directory audit trails for.sqlaudit
and.xel
(extended events). The total number of audit trails for agentless collection should not exceed 20. See Adding Audit Trails with Agentless Collection. -
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.6.2 Adding Audit Trails with Agentless Collection
Starting in
Oracle AVDF 20.9, you can use agentless collection instead of the Audit Vault Agent for up
to 20 Oracle Database table audit trails. Starting in Oracle AVDF 20.10, you can also use
agentless collection for Microsoft SQL Server directory audit trails for
.sqlaudit
and .xel
(extended events). The
total number of audit trails for agentless collection should not exceed 20.
With agentless collection, you use the agentless collection service that comes with the Audit Vault Server instead of deploying the Audit Vault Agent on the target host machines. The agentless collection service is automatically installed when you install the Audit Vault Server or when you update Oracle AVDF to release 20.9 or later.
Note:
- From Oracle AVDF 20.9 to 20.12, agentless collection was supported only on a standalone, unpaired Audit Vault Server (AVS). If the Audit Vault Server was paired for high availability, the agentless collection service would stop running. Starting in Oracle AVDF 20.13, agentless collection is supported on both standalone and high availability AVS
Prerequisites
-
Update Oracle AVDF to the latest release update based on the following requirements:
- For Oracle Database table audit trails, update to Oracle AVDF 20.9 or later.
- For Microsoft SQL Server directory audit trails for
.sqlaudit
and.xel
(extended events) targets, update to Oracle AVDF 20.10 or later.
For update instructions, see one of the following chapters:
- To update Oracle AVDF 20 to the latest release update, see Patching Oracle Audit Vault and Database Firewall Release 20.
- To upgrade from Oracle AVDF 12 to Oracle AVDF 20, see Upgrading Oracle Audit Vault and Database Firewall from Release 12.2 to Release 20.
- Ensure that the Audit Vault Server is not paired for high availability. To unpair the Audit Vault server, see Unpair Primary and Standby Audit Vault Servers.
- Register the Oracle Database or Microsoft SQL Server target. See Registering Targets.
- Prepare the target. See Preparing Targets for Audit Data Collection.
Agentless Collection Support for Microsoft SQL Server
Starting with Oracle AVDF 20.10, ensure that Microsoft SQL Server targets meet the following conditions for agentless collection support:
-
Agentless and remote collection are supported for the following versions of Microsoft SQL Server:
.sqlaudit
audit events: All supported versions of Microsoft SQL Server..xel
audit events: Microsoft SQL Server 2017 and later.
-
Agentless and remote collection are not supported in Microsoft SQL Server clustered environments.
- Agentless and remote collection may be slow when there's a large number of files. In this case, Oracle recommends that you use local, agent-based collection.
-
Audit trail cleanup (ATC) is not supported for agentless and remote collection.
You need to set up the file rollover count properly so that the audit file is purged automatically and doesn't lose audit data. See the Microsoft SQL Server documentation for more information about the file rollover count.
Procedure
- Click the Targets tab.
- Click the link for the Oracle Database or Microsoft SQL Server target for which you want to add the audit trail.
- Under Audit Data Collection, click Add.
-
For Audit Trail Type, select one of the following values:
- For Oracle Database, select TABLE.
- For Microsoft SQL Server, select DIRECTORY.
For details on these audit trail types, see the plug-in reference:
-
In the Trail Location field, enter or select the location of the audit trail on the target computer.
For example:
- Oracle Database example:
UNIFIED_AUDIT_TRAIL
- Microsoft SQL Server examples:
directory_path\*.sqlaudit
ordirectory_path\*.xel
- Oracle Database example:
- Select Agentless Collection. This option is only visible for Oracle Database TABLE trails and Microsoft SQL Server DIRECTORY trails.
- Click Save.
The agent name for the audit trail appears as Agentless Collection on the Audit Trails and Targets pages.
7.6.3 Adding Audit Trails with Agent-Based Collection
To begin collecting audit data with the Audit Vault Agent, configure an audit trail for each target that's registered on the Audit Vault Server and then start the audit trail collection.
Note:
When using the Audit Vault Agent to collect directory trails, the agent must be installed on the same host that contains the directory.
- Create a new target.
- Click the Targets tab.
- Click the link for the target for which you want to add the audit trail.
- Under Audit Data Collection, click Add.
- For Audit Trail Type, select one of the
following trail types:.
- CUSTOM
- DIRECTORY
- EVENT LOG
- NETWORK
For monitoring multiple nodes of an Exadata or RAC database using network trail, create a separate target for each node.
-
SYSLOG
This trail type can collect from
syslog
orrsyslog
files. If both are present, you must provide the exact trail location in the next step if you want to collect audit data fromrsyslog
files.Note:
Ensure that records generated by rsyslog have the same time zone information as the Audit Vault Agent that's running on the collection host. - TABLE
- TRANSACTION LOG
Note:
For details on which types of audit trails can be collected for each target type, see Table C-22.
For complete details on all audit trail types, see Plug-ins That are Shipped with Oracle Audit Vault and Database Firewall.
-
In Trail Location, enter the location of the audit trail on the target computer. The trail location depends on the type of target.
For example, for Oracle Database, the trail location might be
unified_audit_trail
.For supported trail locations, see Audit Trail Locations.
Note:
If you selectDIRECTORY
orTRANSACTION LOG
for Audit Trail Type, then the trail location must be a directory mask. - Select Agent-based Collection if it's visible. If it's not visible, then agent-based collection is used by default for the audit trail.
- For Agent Host, select the host computer where the Audit Vault Agent is deployed.
-
Click Save.
The audit trail should now appear on the Audit Trails tab. The collection status is stopped (a red circle) initially. The audit trail starts automatically shortly after you add it.
See Also:
About Plug-ins7.6.4 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.
Starting with AVDF 20.10, audit trails are monitored daily. Alerts are generated and
email notifications are sent if audit trail is in STOPPED_ERROR
state even after 20 retries.
Starting with AVDF 20.10, network trails are monitored hourly. Alerts are generated
and email notifications are sent out if network trail is in
STOPPED_ERROR
state.
To start or stop audit trail collection for a target:
7.6.5 Checking the Status of Trail Collection on the Audit Vault Server
Learn about checking the status trail collection in Audit Vault Server.
-
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.
Check the Audit Trail Status with SQL*Plus
To check the audit trail status with SQL*Plus, query
avsys.audit_trail_view
.
For example:
SQL> SELECT location, host_name, status FROM audit_trail_view
LOCATION HOST_NAME STATUS
--------------------------------------------------------------- -------------------- -----------
unified_audit_trail xxxxxxxx IDLE
sys.unified_audit_trail_DELETED_2016-06-28 11:56:25.203 +00:00 xxxx STOPPED
/var/log/audit/audit.log_DELETED_2016-06-29 08:49:04.446 +00:00 xxxx STOPPED
/var/log/audit_DELETED_2016-06-29 08:53:00.906 +00:00 xxxx STOPPED
dvsys.audit_trail$ xxxx IDLE
Note:
If theAVSYS
account is locked or the password is unknown, see
Unlocking and Locking the AVSYS User.
Check the Audit Trail Status with AVCLI
To check the audit trail status with AVCLI, use the LIST TRAIL FOR SECURED
TARGET
command.
For example:
AVCLI> LIST TRAIL FOR SECURED TARGET TARGET_NAME;
-----------------------------------------------------------------------------------------------------------------------------------------|
AUDIT_TRAIL_TYPE | HOST | LOCATION | STATUS | REQUEST_STATUS | AUTO_START_STATUS | AUTOSTART_ATTEMPTS | LAST_START_TIME | ERROR_MESSAGE |
=========================================================================================================================================|
TABLE | xxx.xxx.com | UNIFIED_AUDIT_TRAIL | STARTING | | ENABLED | 3 | 2016-07-28 | 20:06:42.802312 GMT ||
------------------------------------------------------------------------------------------------------------------------------------------
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.6.6 Audit Collection Best Practices
Follow these best practices for audit collection.
-
Periodically purge the records that have already been read by the audit trail.
For some targets, the Audit Vault Agent contains scripts for cleanup. See Audit Trail Cleanup for more information. If there are remaining targets where the records have already been read by the audit trail, you can manually clean up the audit trail.
If you don't purge the records, the following issues might occur:
- There may be too many records (more than a million) in a table audit trail. This can slow down audit data collection and reduce the throughput of the table audit trail.
- For directory trails, there may be too many files (more than a thousand) with a size of more than 1 GB. This can slow down audit data collection and reduce throughput of the directory trail.
- Ensure that the directories of transaction log audit trails, directory audit trails, and Oracle GoldenGate are access controlled.
-
For directory and transaction log audit trails, if the
agent
user does not have read permission on audit files, then provide theagent
user with read permission on the audit files by running the following commands.Operating System Command Linux setfacl -Rm u:<agent user name>:r-x <audit data directory>
setfacl -Rdm u:<agent user name>:r-- <audit data directory>
Solaris chmod A+user:<agent user name>:rx:fd:allow <audit data directory>
chmod A+user:<agent user name>:r:allow <audit data directory>/*
AIX/HP-UX Add the agent
user to the group that has read permission on the audit data.
7.6.7 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.6.8 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.6.9 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.6.9.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.6.9.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.6.9.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.
In case of multiple instances, if the instances are not owned by the same user, it is recommended to extract audit data corresponding to each instance in a separate location. To collect the audit data, use one agent per instance. Ensure that the agent user is same as the instance user.
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.6.10 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 with Agent-Based Collection to configure an audit trail.
7.6.11 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 with Agent-Based Collection to configure an audit trail.
7.6.12 Migrating Audit Trails from Agentless Collection to Agent-Based Collection
In Oracle AVDF 20.9 and 20.10, use this procedure to migrate audit trails from agentless collection to agent-based collection (for example, if you decide to pair the Audit Vault Server for high availability).
- Log in to the Audit Vault Console as an administrator.
-
Stop the audit trail that you need to migrate.
See Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server.
-
On the Audit Trails page, record the time in the Data Collected Until column for the audit trail.
This indicates the time and date until which audit records have been collected.
-
On the target database or machine, purge the audit records that have already been collected.
See Audit Trail Cleanup.
-
Delete the audit trail that you need to migrate.
-
Create a new audit trail for the target and select Agent-based Collection when adding the audit trail.
Note:
If records that have already been collected by the agentless collection service are not deleted from the target, then the newly created agent-based audit trail will collect duplicate records.
Even after following the preceding steps, there's a possibility that a small set of duplicate data will be collected.
7.6.13 Migrating Audit Trails to Another Audit Vault Agent
Starting in Oracle AVDF 20.11, you can use the UI console or AVCLI commands to migrate an audit trail from one Audit Vault Agent to another. The same process can also be used to migrate trails from agent-based collection to agentless collection and vice versa. This can be beneficial if an Audit Vault Agent is facing CPU or memory shortages due to a large number of audit trails.
-
Log in to the Audit Vault Server Console as an
administrator
. - Click the Targets tab.
- Click on Audit Trails in the left navigation menu.
- Select which audit trail(s) you'd like to move.
- Click Move.
- Select Agent-based Collection to move the audit trails to another Audit Vault Agent or select Agentless Collection.
- If you selected to move the audit trails to another Audit Vault Agent in the previous step, select the Audit Vault Agent.
- Click Move.
- Login to AVCLI with
administrator
privileges. - Use the
LIST COLLECTION
command to see a list of available Audit Vault Agents. - Use the
MOVE COLLECTION FOR SECURED TARGETS
command to move the audit trails.
Related Topics
7.6.14 Audit Collection Downtime Alerts
Starting in Oracle AVDF 20.10, audit and network trails are monitored
frequently and a system alert is generated if the trails are in the
STOPPED_ERROR
state.
Starting with AVDF 20.10, audit trails are monitored daily. Alerts are
generated and email notifications are sent if audit trail is in
STOPPED_ERROR
state even after 20 retries.
Starting with AVDF 20.10, network trails are monitored hourly. Alerts are
generated and email notifications are sent out if network trail is in
STOPPED_ERROR
state.
7.7 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.7.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.7.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.7.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.7.4 Starting, Stopping, or Deleting Database Firewall Monitoring Points
Learn about starting, stopping, and deleting Database Firewall monitoring points.
7.7.5 Viewing the Status of Database Firewall Monitoring Points
Learn about viewing Database Firewall monitoring point status.
7.7.6 Finding the Port Number Used by a Database Firewall Monitoring Point
Learn about finding Database Firewall monitoring point port numbers.
7.7.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.8 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.9 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.9.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.9.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.9.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. - It is not mandatory for the
SQLNET.ENCRYPTION_SERVER
parameter to be set asREQUIRED
. Native Network Encryption (NNE) can be enabled from the client side as well. But if you want to monitor NNE traffic,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.9.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.10 Configuring Advanced Settings for Database Firewall
Learn about configuring database connection details under advanced options.
7.10.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).
Note:
When dealing with encrypted connections from tools like Microsoft OSTRESS, it is advised to use the-T146
flag to prevent the interference of Microsoft's encryption with the Audit Vault Database Firewall's examination of the data traffic. Additionally, it is suggested to use database interrogation to extract information such as the name of the database user, operating system, and client program that initiated a SQL statement from monitored Microsoft SQL Server and Sybase SQL Anywhere databases.
7.10.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.10.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.10.4 Retrieve Session Information for Microsoft SQL Server and Sybase SQL Anywhere Databases
Learn how to obtain session information for non Oracle databases.
You can retrieve session information for Sybase SQL Anywhere (Oracle AVDF 20.1 - 20.6 only) and Microsoft SQL Server databases 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.10.4.1 Setting Permissions to Retrieve Session Information in Microsoft SQL Server
Learn about retrieving session information in Microsoft SQL Server.
Microsoft SQL Server 2012 was deprecated in Oracle AVDF 20.12, and it will be desupported in one of the future releases.
- Create a user account for Oracle AVDF for querying session
information on the database. This database should be registered as a target
in the Audit Vault Server console.
Make a note of the user name and password for this account.
- Download the necessary
mssql_ddi_script.sql
script from the utilitiesV<part_number>.zip
file available as part of the Oracle AVDF install files from Oracle Software Delivery Cloud.Starting in Oracle AVDF 20.13, you can alternatively download the script from the Audit Vault Server console:-
Log in to the Audit Vault Server Console as an
administrator
. - Click the Targets tab.
- Click the Target Setup Script button to download the integration script.
- The
mssql_ddi_script.sql
script is located in themssql_user_privilege_scripts
directory.
-
- Execute the following command as a user with privileges to
create schemas, logon triggers and jobs, and grant privileges:
Caution:
The script will create a logon trigger on the database and a few tables to be used by the Database Firewall.sqlcmd -S tcp:<IP>,<PORT> -U sa -P <Password> -i mssql_ddi_script.sql -v AVDF_DDI_USER="<username>"
The password is the password for the
sa
user and the username is the same as from step one. - Enable retrieving session information for the Database Firewall
monitoring point that is associated with this target database, using the
credentials created in the earlier step. Ensure the following steps are
accurate while registering Microsoft SQL Server as a target.
-
Log in to the Audit Vault Server Console as an
administrator
. - Click on the Targets tab.
- Select the Microsoft SQL Server database from the list.
- Select the monitoring point from the Database Firewall Monitoring section.
- Click the Advanced tab.
- Select Retrieve session information from target DB.
- In the User Name field, enter the user name of the user created in the earlier step.
- In the Password field, enter the password of the user.
- In the Host Name / IP Address field, enter the IP address of the SQL Server.
- In the Port field, enter the port of the SQL server listening port.
- In the Database Name field, enter a valid database service name on SQL Server. In case the database service name is not correct, then SQL server DDI requests fail on the SQL Server with invalid request error.
-
Note:
It is possible for direct database interrogation (DDI) to fail to fetch information for shorter sessions using this method. Follow the alternate steps that involve running a script to avoid this.- Create a user account for Oracle AVDF for querying session
information on the database. This database should be registered as a target
in the Audit Vault Server console.
Make a note of the user name and password for this account.
- Grant the following permissions to the user account you
created in the previous step:
-
VIEW ANY DEFINITION
andVIEW SERVER STATE
for SQL Server -
SELECT
on themaster.dbo.sysdatabases
table
-
- Enable retrieving session information for the Database Firewall
monitoring point that is associated with this target database, using the
credentials created in the earlier step. Ensure the following steps are
accurate while registering Microsoft SQL Server as a target.
-
Log in to the Audit Vault Server Console as an
administrator
. - Click on the Targets tab.
- Select the Microsoft SQL Server database from the list.
- Select the monitoring point from the Database Firewall Monitoring section.
- Click the Advanced tab.
- Select Retrieve session information from target DB.
- In the User Name field, enter the user name of the user created in the earlier step.
- In the Password field, enter the password of the user.
- In the Host Name / IP Address field, enter the IP address of the SQL Server.
- In the Port field, enter the port of the SQL server listening port.
- In the Database Name field, enter a valid database service name on SQL Server. In case the database service name is not correct, then SQL server DDI requests fail on the SQL Server with invalid request error.
-
7.10.4.2 Disable Retrieving Session Information in Microsoft SQL Server
After using the mssql_ddi_script.sql
script which
created a logon trigger and a few tables on the database to configure direct database
interrogation (DDI), you can use the mssql_ddi_removal.sql
script to
disable DDI.
- Execute the following command as a user with privileges to drop
schemas, logon triggers and jobs, and revoke
privileges:
sqlcmd -S tcp:<IP>,<PORT> -U sa -P<Password> -i mssql_ddi_removal.sql -v AVDF_DDI_USER="<username>"
The password is the password for the
sa
user and the username is that of the user account on the database for Oracle AVDF. - On the Audit Vault Server console, disable DDI for the Microsoft SQL
Server:
-
Log in to the Audit Vault Server Console as an
administrator
. - Click on the Targets tab.
- Select the Microsoft SQL Server database from the list.
- Select the monitoring point from the Database Firewall Monitoring section.
- Click the Advanced tab.
- Deselect Retrieve session information from target DB.
-
7.10.4.3 Setting Permissions to Retrieve Session Information in Sybase SQL Anywhere Database
Learn about retrieving session information in Sybase SQL Anywhere databases.
Note:
- Sybase SQL Anywhere was deprecated in Oracle AVDF release 20.7 and is desupported in 20.8.
- Before you can use Sybase SQL Anywhere, you must download and install the SQL Anywhere ODBC driver for Linux.
7.11 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.11.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.11.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.11.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.11.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/N/etc/appliance.conf
. In this case
N
is the Database Firewall monitoring point number. The
database client always authenticates the associated Database Firewall it is
connecting to.
-
Log in to the Database Firewall through SSH and switch to the
root
user. - Change to
/var/dbfw/va
directory. - Identify the Database Firewall monitoring point by
searching for the target name configured in the Audit Vault Server. Run the
following
command:
grep -lr <TARGET NAME> *
- Find the monitoring point number from the output
which contains the name and path of the configuration file. For example:
1/etc/appliance.conf
. In this example,1
is the monitoring point number.
Follow these steps to disable mutual authentication for inbound TLS communication:
-
Modify the following value in the configuration file
/var/dbfw/va/N/etc/appliance.conf
:TLS_CLIENT_AUTH="0"
-
Import the Database Firewall monitoring point inbound certificate (
/usr/local/dbfw/va/N/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.11.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.11.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.12 Configuring and Using Database Response Monitoring
Learn about configuring and using database response monitoring.
7.12.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.13 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.14 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.