1. Administrator's Guide
  2. Getting Started with Oracle Audit Vault and Database Firewall
  3. Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

7 Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

Learn about configuring targets, audit trails, and Database Firewall monitoring points.

Parent topic: Getting Started with Oracle Audit Vault and Database Firewall

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 some database targets that you monitor with the Database Firewall, you can configure Oracle Audit Vault and Database Firewall to interrogate the database to collect certain data. To do so, you must run scripts on the target computers to configure the necessary privileges for database interrogation.

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.

See Also:

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

7.2 Registering Targets and Creating Groups

Learn about registering targets and creating groups.

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

7.2.1 Registering or Removing Targets in Audit Vault Server

Learn about registering and removing targets in Audit Vault Server.

Parent topic: Registering Targets and Creating Groups

7.2.1.1 About Targets in the Audit Vault Server

Learn about Oracle Audit Vault Server targets.

Oracle Audit Vault and Database Firewall super administrators can create targets and grant access to them to other administrators. Administrators can also create targets, but the target that they create are only accessible to that administrator and the super administrator who created them.

Note:

In the following procedure, if you specify service names and/or SIDs, then Oracle Database Firewall only captures traffic to the service names and/or SIDs listed. In this case, if a database client connects using a different service name or SID than those listed, Oracle Database Firewall does not monitor that traffic. As a best practice to avoid this problem, follow these guidelines:

  • Define the configuration and policies that use Oracle service names for every service that runs on a protected Oracle target. This ensures that the configuration enables each policy to be applied to the correct Oracle service name.

  • Always define a catch-all target (and associated monitoring point) to process the database traffic that does not match the Oracle service names that were explicitly configured in the previous targets. This new target should have the same IP address and TCP port number, but the Oracle service name should be left blank, and should have a "log-all" policy applied. This way, any traffic that the targets with explicitly defined Oracle service names do not capture is logged and can be examined. Based on your findings, you then can tighten the configuration and policies so all traffic that reaches an Oracle service name is captured in an explicit fashion.

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 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:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab.

    The Targets tab in the left navigation is selected by default. The main page contains a list of configured targets. You can sort or filter the list of targets.

  3. Click Register in the top right corner.
  4. Enter the Name and optionally the Description for the new target.
  5. From the Type menu, select from the list of available options.
  6. Enter the Audit Connection Details. If you know the connection string, then select Advanced. If you do not know the connect string, then choose the Basic option.
  7. If you select the Basic option, then enter the following details:
    1. Host Name / IP Address (IP address can be a virtual IP address).
    2. Enter the Port number.
    3. In the Service Name field, if the target is an Oracle database, then enter the Oracle database service name or SID.
    4. Select the Protocol from drop down menu.
    5. In the User Name field, enter the name of the existing database user on the target.
    6. In the Password field, enter the database user's password.
  8. If you select the Advanced option, then enter the following details:
    1. Select the Protocol from drop down menu.
    2. In the Target Location field, enter the connection string or connection URL. This connection string is required for the Agent to collect audit data, but is not required to deploy Database Firewall only.

      Note:

      • For Oracle Database, the string may look like: jdbc:oracle:thin:@//<IP address of the Database server host>:<port number>/hrdb
      • For Oracle Big Data Appliance, enter the connection details of the Oracle Database that has the audit events.
      • When you configure an Oracle RAC (Real Application Clusters) as a target for Agent data collection, enter the SCAN host name. Oracle RAC can be secured using Oracle Database Firewall by configuring as a target.
      • In case the target is Microsoft SQL Server Cluster, a mandatory collection attribute needs to be set. See section Microsoft SQL Server Plug-in for Oracle Audit Vault and Database Firewall for complete information.
    3. In the User Name field, optionally enter the name of the existing database user on the target. This user should have access to the audit data generated by the target.
    4. In the Password field, enter the database user's password.
  9. Click the Audit Collection Attributes tab.
  10. Enter details of the collection attributes in the Name and Value fields. Click the Add icon to add more entries.

    Note:

    Collection attributes may be required by the Audit Vault Agent depending on the target type. Refer to the following table for the mandatory collection attributes to be entered in the Name fields 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 attribute is a timezone offset of Oracle Database.

    For PostgreSQL, ensure to enable pgaudit extension. The audit collection is incomplete and operational details are missed out from the reports in case this extension is not enabled.

  11. Optionally, you can increase the processing resource for this target by adding the following collection attribute:

    Name: MAXIMUM_ENFORCEMENT_POINT_THREADS

    Value: A number between 1 - 16 (default is 1)

    This attribute defines the maximum number of Database Firewall processes (1 - 16) that may be used for the monitoring point associated with this target. Define this attribute if the number of targets you are monitoring is less than the number of processing cores available on the system running the Database Firewall. Setting a value when it is not appropriate results in resource wastage.

  12. Click Save to complete the target registration for audit collection. Continue with the remaining steps to configure the target for Database Firewall monitoring.
  13. Click the Database Firewall Monitoring tab.
  14. Click Add. The Database Firewall Monitor dialog is displayed.
  15. In the Basic tab, select from the list in the Database Firewall field.
  16. Select a Mode from the following:

    • 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 block or substitute SQL statements.

    Note:

    Ensure you select the right mode in accordance with Firewall policy defined for the target. If the Firewall policy specified contains SQL blocking rules, but you select for monitoring only, SQL statements are not blocked. Therefore, if you want to block SQL statements according to policy rules, you should use monitoring and blocking mode.
  17. In the Network Interface Card field, select one from the list.
  18. Select the Proxy Ports from the list.

    Note:

    For a RAC instance, select the Network Interface Card and Proxy Ports for Monitoring / Blocking (Proxy) mode. The proxy port is not mandatory for Monitoring only modes.
  19. Select the check box against RAC Instance field if the target is Oracle Real Application Cluster.
  20. In the Connection Details section, add one or more targets. You can add or delete targets from the list. Enter the following information for each available connection of the database. Click the Add button to add more targets and enter the following fields:

    • Host Name / IP Address

    • Port

    • Service Name (Optional, for Oracle Database only)

      You can also use an SID in this field. To enter multiple service names and/or SIDs, enter a new line here for each of them, and then click Add.

      If you want to enforce different Database Firewall policies for different service names or SIDs on the same database, then you must create a separate target for each service name or SID.

  21. In the Advanced tab, select the number of Database Firewall Monitor Threads.
  22. Select the check box for Capture Database Response field. Select Full Error Message check box if required.
  23. Select the check box for Decrypt With Network Native Encryption Key field. Upon selection there are many fields that appear. Fill in these fields as applicable.
  24. Click Save at the bottom of the dialog.
  25. Click Save at the top right corner of the main page.

    Note:

    TCPS must be configured for registering Hybrid Cloud Oracle Databases. See Securing the Agent and Oracle Database Target Connection.

    See Also:

7.2.1.3 Modifying Targets

Learn about modifying targets.

To modify a target:

  1. Log in to Oracle Audit Vault Server console as an administrator.
  2. Click the Targets tab.

    The Targets tab in the left navigation menu is selected by default. It lists the configured targets to which you have access. You can sort or filter the list of targets.

  3. Click the name of the target that you want to modify.
    A page showing details about the target appears.
  4. Make your changes and then click Save.

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:

Parent topic: Registering or Removing Targets in Audit Vault Server

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:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab.
  3. The Targets tab in the left navigation menu is selected by default. Select the check boxes against the targets that you want to remove.
  4. Click Delete button in the top right corner of the page.

    See Also:

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.

  1. Log in to the Audit Vault Server console as a super administrator.

  2. Click the Targets tab.

  3. In the left navigation menu, click Target Groups.

  4. Click Create button in the top right corner.

  5. In the Create Target Group dialog, do the following:

  6. Click Save.

Parent topic: Registering Targets and Creating Groups

7.2.3 Modifying a Target Group

You can modify the contents of a target group or change the target group name and description.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Targets tab.
  3. In the left navigation menu, click Target Groups.
  4. Click the name of the target group that you want to modify.
  5. In the Modify Target Group dialog, perform any of the following modifications:
  6. Click Save.

Parent topic: Registering Targets and Creating Groups

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.

See Also:

Managing User Access Rights to Targets and Groups

Parent topic: Registering Targets and Creating Groups

7.3 Preparing Targets for Audit Data Collection

Learn about preparing targets for audit data collection.

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

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.

Parent topic: Preparing Targets for Audit Data Collection

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:

  1. Log in to the Oracle database as a user with administrative privileges. For example:
    sqlplus trbokuksa
Enter password: password
Connected.
  2. Run the following command: 
    SHOW PARAMETER AUDIT_TRAIL

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------
audit_trail                          string      DB
  3. If the output of the SHOW PARAMETER command is NONE or if it is an auditing value that you want to change, then you can change the setting as follows.

    For example, if you want to change to XML, and if you are using a server parameter file, you would enter the following: 

    CONNECT SYS/AS SYSDBA
Enter password: password

ALTER SYSTEM SET AUDIT_TRAIL=XML SCOPE=SPFILE;
System altered.

SHUTDOWN
Database closed.
Database dismounted.
ORACLE instance shut down.

STARTUP
ORACLE instance started.
  4. Make a note of the audit trail setting.

    You will need this information when you configure the audit trail in Oracle Audit Vault and Database Firewall.

Parent topic: Preparing Targets for Audit Data Collection

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 enable database interrogation, 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.

Parent topic: Preparing Targets for Audit Data Collection

7.3.4 Scheduling Audit Trail Cleanup

Learn about scheduling audit trail cleanup.

Oracle Audit Vault and Database Firewall supports audit trail cleanup for Oracle Database, Microsoft SQL Server, and MySQL.

See Also:

Audit Trail Cleanup

Parent topic: Preparing Targets for Audit Data Collection

7.4 Configuring and Managing Audit Trail Collection

Learn about configuring and managing audit trail collection.

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

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:

Parent topic: Configuring and Managing Audit Trail Collection

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:

  1. Create a new target.

  2. Click the Targets tab. The Targets tab in the left navigation menu is selected by default.

  3. Click on the name of the target for which the audit trail needs to be added.

  4. Under Audit Data Collection, select Add.

    The Add Audit Trail dialog appears.

  5. 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 or rsyslog files. If both are present, you must give the exact Trail Location in the following step ahead, if you want to collect audit data from rsyslog files. See Table C-26 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-20 for details on which types of audit trails can be collected for a specific target type.

  6. 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 select DIRECTORY or TRANSACTION LOG as Audit Trail Type, then the trail location must be a directory mask. See Table C-26 for important details.

  7. In the Agent Host field, select the host computer where the Audit Vault Agent is deployed.

  8. The Agent Plug-in field automatically contains the appropriate plug-in name.

  9. Click Save.

    The audit trail is added to the list on the Audit Trails tab. The collection status displays a red down-arrow initially. This indicates the status of the trail as stopped. The audit trail starts automatically shortly after it is added.

See Also:

Parent topic: Configuring and Managing Audit Trail Collection

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:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab. The Targets tab in the left navigation menu is selected by default.
  3. Select the specific target by clicking on the name.
  4. Under the Audit Data Collection section, select the targets that have the audit trails that you want to start or stop.
  5. Click Stop or Start accordingly.

    Note:

    • You cannot start an audit trail while the Audit Vault Agent is updating.
    • If your environment has a large number of audit files to collect, for example one million or more, then the audit trail may take a few minutes to start.

    See Also:

Parent topic: Configuring and Managing Audit Trail Collection

7.4.4 Checking the Status of Audit Trails in the Audit Vault Server

Learn about checking the status of audit trails in Oracle Audit Vault Server.

To check the status of audit trails:

  1. Log in to the Audit Vault Server console as an administrator.

  2. Click the Targets tab. The Targets tab in the left navigation menu is selected by default.

  3. 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 has collected a batch of audit data and is setting a checkpoint on the Audit Vault Server. This 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 two minutes. This status is temporary unless the trail has crashed.

    • 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.

See Also:

Parent topic: Configuring and Managing Audit Trail Collection

7.4.5 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:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab, and then click Audit Trails.
  3. In the Collection Status column, if applicable, click the Archive data files are required link.

    The required archive data files are listed.

  4. Check that required data files are available in the archive location, and that the connection to the location is set up correctly.
  5. After you make the required data files available, restart this audit trail.

See Also:

Parent topic: Configuring and Managing Audit Trail Collection

7.4.6 Deleting an Audit Trail

Learn how to delete an audit trail.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab.
  3. In the left navigational menu, click Audit Trails.
  4. Select the audit trails that you want to delete and then, if necessary, click Stop to stop the audit trail.
  5. Select the audit trails that you want to delete, and then click Delete.

Parent topic: Configuring and Managing Audit Trail Collection

7.4.7 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.

Parent topic: Configuring and Managing Audit Trail Collection

7.4.7.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.

7.4.7.2 Running the XML Transformation Utility for MySQL Audit Formats

Learn how to run the XML transformation utility for MySQL audit formats.

Audit records of some databases are in the format that cannot be read directly by Oracle Audit Vault and Database Firewall collectors. Such audit records are first converted to a readable format and then collected.
For MySQL targets, Oracle Audit Vault and Database Firewall provides a utility to transform the MySQL XML audit format log file into a required format for audit data collection. You must run this utility on the MySQL host machine before adding an audit trail.

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:

  1. On the MySQL host computer, go to the directory AGENT_HOME/av/plugins/ com.oracle.av.plugin.mysql/bin/
  2. Run the following command:
    MySQLTransformationUtility.bat inputPath=path_to_log_folder 
outputPath=path_to_converted_xml agentHome=path_to_AGENT_HOME 
interval=interval_in_minutes xslPath=XSL_file_path securedTargetName=registered_secured_target_name

    This command contains the following variables:

    • path_to_log_folder
      :

      • For MySQL version prior to 5.7.21: The path to the MySQL log folder listed in my.ini

      • For MySQL version 5.7.21 and later: The path to the MySQL log folder listed in my.ini\<audit file name>.*.log

    • path_to_converted_xml - The path to the folder where the converted XML files will reside. You will use this path as the Trail Location when creating the audit trail for this MySQL target in the Audit Vault Server, or when starting audit trail collection using the AVCLI command line.

    • path_to_AGENT_HOME - The path to the installation directory of the Audit Vault Agent

    • interval_in_minutes - (Optional) The waiting time, in minutes, between two transformation operations. If not specified, the default it is 60 minutes. To run the transformation utility once, specify -ve for this argument.

    • XSL_file_path - (Optional) The path to the XSL file to use for the transformation.

    • registered_secured_target_name - The name of the MySQL target registered in the Audit Vault Server.

    Example:

    For MySQL version prior to 5.7.21: MySQLTransformationUtility.bat inputPath=D:\MySQLLog outputPath=D:\ConvertedXML agentHome=E:\MySQLCollector interval=1 securedTargetName=MYSQL_DEV

    For MySQL version 5.7.21 and later: MySQLTransformationUtility.bat inputPath=D:\MySQLLog\audit.*.log outputPath=D:\ConvertedXML agentHome=E:\MySQLCollector interval=1 securedTargetName=MYSQL_DEV

7.4.7.3 Converting Binary Audit Files to ASCII Format

Learn about converting binary audit files to ASCII format.

IBM DB2 creates its audit log files in a binary file format that is separate from the DB2 database. For IBM DB2 targets, you must convert the binary file to an ASCII file before each time you collect audit data (start an audit trail) for a DB2 database, using the script instructions in this section.
Ideally, schedule the script to run periodically. If the script finds older text files that have already been collected by the DB2 audit trail, then the script deletes them. It creates a new, timestamped ASCII text file each time you run it. Optionally, you can set the script to purge the output audit files.

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.

  1. Identify a user who has privileges to run the db2audit command.

    This user will extract the binary files to the text files.

  2. Grant the user you identified in Step 1 execute privileges to run the conversion script from the Oracle AVDF directory. The script name is:

    • DB2 release 8.2 databases: DB282ExtractionUtil (for Microsoft Windows, this file is called DB282ExtractionUtil.bat.)

    • DB2 release 9.5 databases: DB295ExtractionUtil (for Microsoft Windows, this file is called DB295ExtractionUtil.bat.)

  3. Grant the user you identified in Step 1 read permission for the $AGENT_HOME/av/atc directory and its contents.
  4. In the server where you installed the IBM DB2 database, open a shell as the SYSADM DB2 user.
  5. Set the following variables:

    • AGENT_HOME (this is the Audit Vault Agent installation directory)

    • DB2AUDIT_HOME (this directory points to the main directory that contains the db2audit command)

  6. Ensure that the Oracle AVDF owner of the agent process has read permissions for the audit text files that will be generated by the extraction utility.
  7. Log in as the DB2 user that you identified in "IBM DB2 for LUW Setup Scripts".
  8. Run one of the following scripts, depending on the version of DB2 that you have installed:

    • For DB2 release 8.2 databases:

      DB282ExtractionUtil -extractionpath default_DB2_audit_directory -audittrailcleanup yes/no

      • default_DB2_audit_directory: Enter the full directory path to the location of the DB2 audit directory. Typically, this directory is in the following locations:

        UNIX: DB2_HOME/sqlib/security/auditdata

        Microsoft Windows: DB2HOME\instance\security\auditdata

      • yes/no: Enter yes or no, to enable or disable the audit trail cleanup. Entering yes deletes the IBM DB2 audit file up to the latest audit record which has been collected by the Oracle AVDF DB2 audit trail. If you omit this value, then the default is no.

      For example, to extract audit files and enable the audit trail cleanup:

      DB282ExtractionUtil -extractionpath /home/extract_dir -audittrailcleanup yes

      This script creates the ASCII text file in the auditdata directory, using the following format, which indicates the time the file was created: 

      db2audit.instance.log.0.YYYYDDMMHHMMSS.out

    • For DB2 release 9.5 databases:

      DB295ExtractionUtil -archivepath archive_path -extractionpath extraction_path -audittrailcleanup yes/no -databasename database_name

      In this specification:

      • archive_path: This is DB2 archive path configured using the db2audit utility.

      • extraction_path: This is the directory where the DB2 extraction utility places the converted ASCII text file. This file is created in either the db2audit.instance.log.0.YYYYDDMMHHMMSS.out or db2audit.db.database_name.log.0.20111104015353.out format.

      • yes/no: Enter yes or no, to enable or disable the audit trail cleanup. Entering yes deletes the archived IBM DB2 audit files that were collected by the Oracle AVDF DB2 audit trail. If you omit this value, then the default is no.

      • database_name: (Optional) This is the name, or names separated by spaces, of the database(s) that contain the audit records.

        The utility creates a separate ASCII file for each database named in the command. If this parameter is omitted, then the utility converts the instance binary to an ASCII file. This parameter enables you to collect categories of audit records such as object maintenance (objmaint) records, which capture the creation and dropping of tables.

        Important: If you enter more than one database name in this command, be sure to put the ASCII file for each database in a separate directory after you run the command.

      Example 1: The following command creates an ASCII file for the TOOLSDB database, puts the file in the /home/extract_dir directory, and deletes archive files after you have collected audit data: 

      DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes -databasename TOOLSDB

      Example 2: The following command creates an ASCII file for the database instance, puts the file in the /home/extract_dir directory, and deletes archive files after you have collected audit data: 

      DB295ExtractionUtil -archivepath /home/archive_dir -extractionpath /home/extract_dir -audittrailcleanup yes

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.8 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

TABLE

To configure table trail audit data collection from Oracle RAC environment, 1 audit trail is sufficient.

DIRECTORY

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.

TRANSACTION LOG

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.

Parent topic: Configuring and Managing Audit Trail Collection

7.4.9 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.1 data is 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 from CDB_UNIFIED_AUDIT_TRAIL is lower than audit collection from UNIFIED_AUDIT_TRAIL of every PDB instance. If the number of audit records generated per day in CDB_UNIFIED_AUDIT_TRAIL is higher than 8 million, then configure audit collection from UNIFIED_AUDIT_TRAIL of every PDB instance.

To configure Audit Trail collection for CDB or PDB, follow these guidelines:

Audit Trail Type Guidelines

TABLE

  • Audit records pertaining to CDB activities can be collected from UNIFIED_AUDIT_TRAIL table of the CDB target. Audit records corresponding to CDB activities and all PDB activities can be collected from CDB_UNIFIED_AUDIT_TRAIL.

  • Every PDB stores the audit data in its own UNIFIED_AUDIT_TRAIL table. It does not contain audit data of other PDBs. Separate audit trails must be configured for a PDB target to collect data corresponding to that specific PDB only.

  • For PDB target, collection from CDB_UNIFIED_AUDIT_TRAIL is not supported.

Note:

Audit collection from CDB_UNIFIED_AUDIT_TRAIL is supported in release 20.1.0.0.0.

DIRECTORY

  • Audit from directory trail can be collected for CDB, by providing directory trail location as <value of AUDIT_FILE_DEST> (database parameter).

  • Audit from directory trail can be collected for each PDB, by providing directory trail location as <value of AUDIT_FILE_DEST>/<GUID of the PDB>.

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 processes are updated in AV.COLLECTOR.IGNORE_PDB_IF_DOWN_LIST, and then 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.

Parent topic: Configuring and Managing Audit Trail Collection

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.

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

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.

See Also:

Configuring Database Firewall and Its Traffic Sources on Your Network

Parent topic: Configuring Database Firewall Monitoring Points

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.

Ensure that you have configured traffic sources on the Database Firewall you plan to use for this monitoring point. See Configuring Database Firewall and Its Traffic Sources on Your Network for more information.
  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab.

    The Targets tab in the left navigation menu is selected by default.

  3. Select and click the target you wish to modify.
  4. From the Database Firewall Monitoring section on the main page, click on Add. The Database Firewall Monitor dialog is displayed.
  5. In the Basic tab (for 20.3 or later the name of the tab is Core), enter the name for this Database Firewall instance or select one from the list.
  6. Select a Mode from the following:
    • Monitoring (Out-of-Band)
    • Monitoring (Host Monitor)
    • Monitoring / Blocking (Proxy)
  7. In the Network Interface Card field, select one from the list. For Monitoring (Host Monitor) mode, see Create a Monitoring Point for the Host Monitor.
  8. Select the Proxy Ports from the list for Monitoring / Blocking (Proxy) mode. This field does not apply to other modes of Database Firewall deployment.
  9. In the Connection Details section, select one or more targets. You can Add the targets from the list.

    Note:

    • Select the check box against RAC Instance field if the target is Oracle Real Application Cluster. Select this option for Oracle Databases where the monitoring point is in Monitoring / Blocking (Proxy) mode. For Monitoring (Out-of-Band) mode, uncheck this box. Enter the IP address of the individual RAC node in Target Connections field.
    • Select the Network Interface Card and Proxy Ports for Monitoring / Blocking (Proxy) mode. The proxy port is not applicable for monitoring only modes.

    Enter the following information for each network location of the database. Click the Add button to configure the following additional details of the target instance:

    • Host Name / IP Address
    • Port
    • Service Name (Optional, for Oracle Database only). SID can be used in this field. To enter multiple service names and/or SIDs, enter a new line for each of them, and then click Add. Multiple entries are allowed for monitoring only mode. For Monitoring / Blocking (Proxy) mode, only one target detail is allowed. To enforce different Database Firewall policies for different service names or SIDs on the same database, create a separate monitoring point, and register a separate target for each of the service name or SID.

    Note:

    Targets are listed here with the policy details. Choose the right deployment mode as per the requirement. Choose Monitoring / Blocking (Proxy) for monitoring, blocking, and alerting. Choose Monitoring (Out-of-Band) or Monitoring (Host Monitor) modes for monitoring and alerting only.
  10. In the Advanced tab, enter the number of Database Firewall Monitor Threads (minimum and default value is 1). This controls the number of traffic handling threads in the Database Firewall monitoring point. Use due caution before modifying the value.
  11. Select the check box for Capture Database Response field. If you check this field, the Database Firewall monitors the SQL response from the database. Select Full Error Message check box to capture the database response codes and error codes.
  12. Select the check box for Decrypt With Network Native Encryption Key field. This is for enabling decryption of traffic if database is using Oracle Native encryption. Decrypt with network native encryption key option also supports retrieval of session information for Oracle Database. Upon selection there are many fields that appear. Fill in these fields as applicable.

    For Oracle RAC target (if RAC Instance checkbox was enabled in the Basic tab (for 20.3 or later the name of the tab is Core)), enter the SCAN Listener IP address.

    For Oracle standalone database targets, enter the IP address of the database listener.

    For other database types (non Oracle) the field is Retrieve session information from target DB.

    Note:

    Ensure the Database Firewall is allowed to make a network connection to the above mentioned database listener.
  13. Click Save at the bottom of the dialog.

    The new monitoring point appears in the list and starts automatically.

  14. To stop or restart the monitoring point, select it from the Database Firewall Monitoring section and click Stop or Start.

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:

Parent topic: Configuring Database Firewall Monitoring Points

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, database interrogation, and host monitoring.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click Targets tab.
    The Targets tab in the left navigation menu is selected by default.
  3. Select and click on a specific target from the list.
  4. From the Database Firewall Monitoring section on the main page, click the name of the monitoring point you want to modify.
  5. In the Database Firewall Monitor dialog, you can change some of the settings.
  6. Select a different Mode from the following:

    • Monitoring (Out-of-Band) - In this deployment mode, 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 block or substitute SQL statements.

    • Monitoring (Host Monitor) - In this deployment mode, Database Firewall can monitor and alert on SQL traffic, but cannot block or substitute SQL statements.

    Note:

    • For Oracle AVDF 20.2 and earlier, while configuring the Monitoring (Host Monitor) deployment mode, you must select a network interface card that is not used as a Management Interface.
    • For Oracle AVDF release 20.3 and later, while configuring the Monitoring (Host Monitor) deployment mode, you must select a NIC which has an IP address configured. This may be the Management Interface. This is the NIC to which the Host Monitor will connect. When you select Monitoring (Host Monitor) as the deployment type, only those network interface cards which have IP address configured are displayed in the Network Interface Card field.
  7. Select a different traffic source in the field Network Interface Card.
  8. In the Advanced tab, enter the number of Database Firewall Monitor Threads (minimum value is 1). This controls the number of traffic handling threads in the Database Firewall monitoring point. This value should be left at the default (1) unless there are indications that the Database Firewall is unable to cope with the amount of traffic it is receiving.
  9. Select the check box for Capture Database Response field. If you check this field, the Database Firewall monitors the SQL response from the database. Select Full Error Message check box to capture the database response codes and error codes.
  10. Select the check box for Decrypt With Network Native Encryption Key field. This is for enabling decryption of traffic if database is using Oracle Native encryption. Decrypt with network native encryption key option also supports retrieval of session information for Oracle Database. Upon selection there are many fields that appear. Fill in these fields as applicable.

    For Oracle RAC target (if RAC Instance checkbox was enabled in the Basic tab (for 20.3 or later the name of the tab is Core), enter the SCAN Listener IP address

    For Oracle standalone database targets, enter the IP address of the database listener.

    For other database types (non Oracle) the field is Retrieve session information from target DB.

    Note:

    Ensure the Database Firewall is allowed to make a network connection to the above mentioned database listener.
  11. Click Save.

Parent topic: Configuring Database Firewall Monitoring Points

7.5.4 Starting, Stopping, or Deleting Database Firewall Monitoring Points

Learn about starting, stopping, and deleting Database Firewall monitoring points.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab.
  3. Click on a specific target. The details of the target are displayed on the main page.
  4. Under Database Firewall Monitoring tab, select a specific Database Firewall monitoring point.
  5. Click one of the following buttons:

    • Start - To start the monitoring point

    • Stop - To stop the monitoring point

    • Delete - To delete the monitoring point

    See Also:

    Using Audit Vault Server Console

Parent topic: Configuring Database Firewall Monitoring Points

7.5.5 Viewing the Status of Database Firewall Monitoring Points

Learn about viewing Database Firewall monitoring point status.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab.
  3. Select a specific target. The details of the specific target are displayed on the main page.
  4. Under Database Firewall Monitoring section, click on a specific Database Firewall monitoring point.

    A list of monitoring points and their status is displayed. Possible status values are:

    • Up - The monitoring point is up and running, and there are no errors.

    • Suspended - The user has stopped the monitoring point, and there are no errors.

    • Down - The monitoring point is not working, probably due to errors.

    • Unreachable - There are communication errors between the Database Firewall and the Audit Vault Server.

    See Also:

    Using Audit Vault Server Console

Parent topic: Configuring Database Firewall Monitoring Points

7.5.6 Finding the Port Number Used by a Database Firewall Monitoring Point

Learn about finding Database Firewall monitoring point port numbers.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab.
  3. Select a specific target. The details of the specific target are displayed on the main page.
  4. Under Database Firewall Monitoring section, click on a specific Database Firewall monitoring point.
  5. The port number is displayed in the field Proxy Ports.

Parent topic: Configuring Database Firewall Monitoring Points

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.

See Also:

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

7.7 Configuring Advanced Settings for Database Firewall

Learn about configuring database connection details under advanced options.

Database interrogation enables Oracle Database Firewall to interrogate supported database targets for specific information. The information collected depends on the database type.

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

7.7.1 Enabling Database Interrogation

Learn about enabling database interrogation.

Use this procedure to enable database interrogation.

Prerequisite

Log in to the Audit Vault Server console as administrator. See Using Audit Vault Server Console for more information.

To enable database interrogation for a Database Firewall monitoring point:

  1. Click the Targets tab. The Targets tab in the left navigation menu is selected.
  2. Click on the specific target. The details of the target are displayed on the main page.
  3. Under Database Firewall Monitoring section, select the monitoring point for which database interrogation needs to be enabled.
  4. In the Advanced tab, select the check box for Decrypt With Network Native Encryption Key field. This is for enabling decryption of traffic if database is using Oracle Native encryption. Decrypt with network native encryption key option also supports retrieval of session information for Oracle Database. Upon selection there are many fields that appear. Fill in these fields as applicable.

    For Oracle RAC target (if RAC Instance checkbox was enabled in the Basic tab, enter the SCAN Listener IP address

    For Oracle standalone database targets, enter the IP address of the database listener.

    For other database types (non Oracle) the field is Retrieve session information from target DB.

    Note:

    Ensure the Database Firewall is allowed to make a network connection to the above mentioned database listener.
  5. Once the above mentioned field is checked, the following fields are populated. Enter the values in the appropriate fields.
    • Host Name / IP Address - Enter the host name or the IP address of the target database that needs to be interrogated. For Oracle standalone Database targets, enter the IP address of the database host machine. For Oracle RAC target, enter the SCAN Listener IP address.

    • Port - Enter the port number of the target database that needs to be interrogated.

    • Service Name - Enter the service name of the database or database instance.

    • User Name - Enter the database interrogation user name that was set up for this target.

      See Also:

      Configuring Database Interrogation for SQL Server and SQL Anywhere

    • Password - Enter the password for the database interrogation user name.

  6. Click Save.

Parent topic: Configuring Advanced Settings for Database Firewall

7.7.2 Disabling Database Interrogation

Learn about disabling database interrogation.

You can temporarily disable database interrogation. Audit Vault and Database Firewall saves the configuration information that you have created for the next time that you want to enable it.

To disable database interrogation:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab. The Targets tab in the left navigation menu is selected.
  3. Click on the specific target. The details of the target are displayed on the main page.
  4. Under Database Firewall Monitoring section, select the monitoring point for which database interrogation needs to be disabled.

    Alternatively, navigate to Database Firewalls tab and then click Database Firewall Monitoring tab in the left navigation menu. A list of monitoring points are displayed on the page. The list can be sorted or filtered.

  5. In the Advanced tab, uncheck the box against Decrypt With Network Native Encryption Key field (for Oracle Databases) or Retrieve session information from target DB (for other database types). This is for disabling database interrogation. Upon deselection the remaining fields disappear.
  6. Click Save.

Parent topic: Configuring Advanced Settings for Database Firewall

7.7.3 Using Database Interrogation for SQL Server and SQL Anywhere Databases

Learn about using database interrogation for SQL Server and SQL Anywhere databases.

You can use database interrogation to interrogate a monitored 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, if this information is not available from the network traffic. This information then is made available in the Audit Vault and Database Firewall reports.

To configure database interrogation for these two databases you must:

  • Create a user account for Audit Vault and Database Firewall database interrogation on the database. Grant specific privileges to that user account.

  • Enable database interrogation in the monitoring point that is associated with the target database, using the Audit Vault Server console.

See Also:

Parent topic: Configuring Advanced Settings for Database Firewall

7.7.4 Using Database Interrogation for Oracle Databases with Network Encryption

Learn about using database interrogation for Oracle Databases with network encryption.

If you are using the Database Firewall to monitor an Oracle Database target that uses Network Encryption, you must use Database Interrogation 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.
  • If you are using Oracle Container Databases (CDB), ASO decryption is not available for root container databases (CDB$ROOT). It is available only for Pluggable Container Databases (PDB). One or more PDBs together are called a container database (CDB).

See Also:

Configuring Database Firewall for Databases That Use Network Native Encryption

Parent topic: Configuring Advanced Settings for Database Firewall

7.7.5 Configuring Database Interrogation for SQL Server and SQL Anywhere

Learn about configuring database interrogation for SQL Server and SQL Anywhere.

Parent topic: Configuring Advanced Settings for Database Firewall

7.7.5.1 Setting Database Interrogation Permissions in Microsoft SQL Server

Learn about setting database interrogation permissions in Microsoft SQL Server.

To configure the user account for Microsoft SQL Server:

  1. Create a user account for Audit Vault and Database Firewall database interrogation on the database that you want to interrogate. (This database should be a target in Oracle Audit Vault and Database Firewall.)

    Make a note of the user name and password for this account.

  2. Grant the following permissions to the user account you created in the previous step:

    • VIEW ANY DEFINITION and VIEW SERVER STATE for SQL Server

    • SELECT on the master.dbo.sysdatabases table

  3. Enable database interrogation 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.
    • 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 Service 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.

    See Also:

    Enabling Database Interrogation

7.7.5.2 Setting Database Interrogation Permissions in a Sybase SQL Anywhere Database

Learn about setting interrogation permissions in Sybase SQL Anywhere databases.

Note:

Before you can use Sybase SQL Anywhere, you must download and install the SQL Anywhere ODBC driver for Linux.

To set user permissions for database interrogation in a Sybase SQL Anywhere database:

  1. Create a user account for Audit Vault and Database Firewall database interrogation on the database that you want to interrogate. (This database should be a target in Audit Vault and Database Firewall.)

    Make a note of the user name and password for this account.

  2. Grant the following permissions to the user account created in the earlier step:

    • CONNECT

    • SELECT on these system tables: 

      sys.sysuser
sys.sysuserauthority
sys.sysremoteuser
sys.sysloginmap
sys.sysgroup
  3. Enable database interrogation for the Database Firewall monitoring point that is associated with this target database, using the credentials created in the earlier step.

7.8 Configuring Database Firewall for Databases That Use Network Native Encryption

Learn about configuring database interrogation for Oracle Databases that use network encryption.

You can also use database interrogation to interrogate a monitored 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 Database Interrogation for an Oracle Database that uses Network Encryption, follow steps in this section.

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

7.8.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:

  1. Shut down the Oracle Database.
  2. Get the patch identified by the bug number 13051081.

    The patch file will be in the format: p13051081_OracleVersion_Platform.zip. For example: p13051081_112030_Linux-x86-64.zip

  3. Unzip the patch .zip file in a directory, identified here as Patch_Directory.
  4. Go to the directory Patch_Directory/13051081.
  5. Execute the command:

    $ opatch apply

  6. Start the Oracle Database.

Parent topic: Configuring Database Firewall for Databases That Use Network Native Encryption

7.8.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:

  1. From the Oracle Audit Vault and Database Firewall utilities file dbfw-utility.zip (downloaded with the software), copy the database directory to a location from which you can connect to the Oracle Database being patched.
  2. In this location, go to the database/ddi directory and uncompress one of the two oracle compressed files (both contain the same content), preferably into a directory called oracle.

    This directory now contains the uncompressed file: advanced_security_integration.sql.

  3. Execute the following command as a user with privileges to create users and grant privileges.

    sqlplus / as sysdba @advanced_security_integration <param1> <param2> <param3>

    where <param1> is the schema or username

    <param2> is the password to be set for the username

    <param3> valid values are ASO and SESSION_INFO

    ASO retrieves oracle native network encryption key and session information

    SESSION_INFO retrieves session information

    Note:

    The third parameter (<param3>) is mandatory. In case it is missed, the system prompts with a help message.

    In case value of the third parameter (<param3>) is incorrect, the following help message is displayed: 

    
Invalid value is provided for <param3>
The valid values are ASO, SESSION_INFO.
ASO retrieves oracle native network encryption key and session information
SESSION_INFO retrieves session information

Parent topic: Configuring Database Firewall for Databases That Use Network Native Encryption

7.8.3 Step 3: Provide the Oracle Database Firewall Public Key to Oracle Database

Learn how to provide Oracle Database Firewall public keys to Oracle Database.

In order for to decrypt database traffic using database interrogation, you must provide the Database Firewall public key to the Oracle Database that is using Network Encryption.

To provide the public key to the Oracle Database:

  1. Log in to the Audit Vault Server console as administrator.
  2. Click Database Firewall tab.
  3. Click the specific Database Firewall instance from the list.
  4. Click Oracle Native Encryption under Configuration section.

  5. 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 the sqlnet.ora file on the Oracle Database server.

  6. Modify the sqlnet.ora file in the Oracle Database to include the public key and to require Network Encryption native traffic encryption:

    1. Put the file you created in the earlier step on the Oracle Database server, preferably in the same directory as the sqlnet.ora file.

    2. Open the sqlnet.ora file and append the following parameters (in this example the public key file is dbfw_public_key.txt): 

      SQLNET.ENCRYPTION_TYPES_SERVER=AES256
SQLNET.DBFW_PUBLIC_KEY="/path_to_file/dbfw_public_key.txt"
SQLNET.ENCRYPTION_SERVER=REQUIRED

      Note:

      If the sqlnet.ora file contains the optional parameter SQLNET.ENCRYPTION_CLIENT, its value must not be REJECTED. Otherwise, an error will occur.

    3. Save and close the sqlnet.ora file.

See Also:

Oracle Database Security Guide for more information on network encryption.

Parent topic: Configuring Database Firewall for Databases That Use Network Native Encryption

7.8.4 Step 4: Enable Database Interrogation for Oracle Database

You can enable database interrogation for Oracle Database.

Follow the procedure in "Enabling Database Interrogation" to complete the Database Interrogation setup for Oracle Databases that use network encryption.

Parent topic: Configuring Database Firewall for Databases That Use Network Native Encryption

7.9 Configuring and Using Database Response Monitoring

Learn about configuring and using database response monitoring.

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points

7.9.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.

Figure 7-1 Database Response Monitoring

Description of Figure 7-1 follows
Description of "Figure 7-1 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).

Parent topic: Configuring and Using Database Response Monitoring

7.9.2 Enabling Database Response Monitoring

Learn about enabling database response monitoring.

To enable database response monitoring for a target:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Targets tab. The Targets tab in the left navigation menu is selected.
  3. Click on the specific target. The details of the target are displayed on the main page.
  4. Under Database Firewall Monitoring section, select the monitoring point for which database interrogation needs to be enabled.
  5. In the Database Firewall Monitor dialog, click the Advanced tab.
  6. Select the check box against Capture Database Response field.

    After this field is checked, the Full error message check box is displayed. If this field is checked, any detailed error message text generated by the database is logged along with the error code.

  7. Click Save.

    See Also:

Parent topic: Configuring and Using Database Response Monitoring

7.10 Securing the Agent and Oracle Database Target Connection

Learn how secure the Agent and Oracle Database target connection.

Data security between an Audit Vault Agent and an Oracle Database target is achieved by default, through network encryption over TCP connection. Data security can also be achieved by using a TCPS/SSL connection.

If the target has been setup to accept TCPS/SSL connections, then follow these steps to configure the Agent:

  1. 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

  2. Log in to the Audit Vault Server console as an administrator.

  3. Click the Targets tab.

  4. In the left navigation menu, select Targets.

  5. Select the name of the target that you want to modify.

  6. In the target page, do the following:

    1. In the Audit Data Collection section, enter the details in Host Name/IP Address, choose TCPS protocol, Server DN, and upload the wallet file.

    2. 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")))

    3. Click Save.

See Also:

Parent topic: Configuring Targets, Audit Trails, and Database Firewall Monitoring Points