Topics
Secured targets can be supported databases or operating systems that Audit Vault and Database Firewall monitors. You must register all secured 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 secured targets, you must configure an audit trail for each target and start collection manually.
If you want to monitor a secured target with the Database Firewall, you must create an enforcement point for that secured target.
For some database secured 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 secured target computers to configure the necessary privileges for database interrogation.
If you are using the Database Firewall, you can also monitor the secured 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.
Topics
Topics
An Oracle AVDF super administrator can create secured targets and grant access to them to other administrators. An Oracle AVDF administrator can also create secured targets, but they are only accessible to that administrator and the super administrator.
Important: In the following procedure, if you specify service names and/or SIDs, then the 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, the 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 each and every service that runs on a protected Oracle secured target. This ensures that the configuration enables each policy to be applied to the correct Oracle service name.
Always define a catch-all secured target (and associated enforcement point) to process the database traffic that does not match the Oracle service names that were explicitly configured in the previous secured targets. This new secured 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 secured 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 secured target for your database as you would for previous versions of Oracle Database. If you use a CDB, then you must register a secured target for the CDB, as well as each pluggable database (PDB).
To modify a secured target:
Note:
If you change the name of a secured target, the new name does not appear in Oracle Audit Vault and Database Firewall reports until you restart the Audit Vault Agent.
See Also:
Registering Secured Targets for description of the fields in the Modify Secured Target page.
Working with Lists of Objects in the UI to sort or filter the list of secured targets.
If you no longer need to have a secured target registered with Oracle AVDF, you can use either the console or the command-line utility to remove the secured target. After you have removed the secured target from Oracle AVDF, its audit data still resides in the data warehouse within its retention period (archiving policy).
After you have removed a secured target, its identity data remains in Oracle AVDF so that there will be a record of secured targets that have been dropped. Remove the secured target only if you no longer want to collect its data or if it has moved to a new host computer.
To remove a secured target:
As a super administrator you can create secured target groups in order to grant other administrators access to secured targets as a group rather than individually.
To create a secured target group:
Log into the Oracle Audit Vault and Database Firewall console as a super administrator, and click the Secured Targets tab.
Click the Groups menu on the left.
Preconfigured groups are listed in the top pane, and user defined groups are listed in the bottom pane.
You can adjust the appearance of the list in the bottom pane from the Actions menu.
Click Create, and enter a name and optional description for the group.
To add secured targets to the group, select the secured targets, and click Add Members.
Click Save.
The new group appears in the bottom pane of the groups page.
To modify a secured target group:
Log into the Oracle Audit Vault and Database Firewall console as a super administrator, and click the Secured Targets tab.
Click the Groups menu on the left.
Preconfigured groups are listed in the top pane, and user defined groups are listed in the bottom pane.
You can adjust the appearance of the list in the bottom pane from the Actions menu.
Click the group name.
In the Modify Secured Target page, select secured targets you want to add or remove, and then click Add Members or Drop Members.
Optionally, you can change the name or description of the group.
Click Save.
See Also:
Working with Lists of Objects in the UI to adjust the appearance of the list in the bottom pane from the Actions menu.
Oracle Audit Vault and Database Firewall super administrators can control which administrators have access to secured targets or secured target groups. You can control access for an individual user, or for an individual secured target or group.
Topics
It is recommended that you also use an NTP service on both your secured 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.
In order to collect audit data from a secured target, you must ensure that auditing is enabled on that secured target, and where applicable, note the type of auditing that the secured target is using. Check the product documentation for your secured target type for details.
Some secured 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 secured target, do stored procedure auditing (SPA), entitlements auditing, or enable database interrogation, you must create a user account on the secured target with the appropriate privileges to allow Oracle Audit Vault and Database Firewall to access the required data.
Setup scripts for database secured targets: Oracle Audit Vault and Database Firewall provides scripts to configure user account privileges for database secured target types.
Non-database secured targets: You must create a user that has the appropriate privileges to access the audit trail required. For example, for a Windows secured 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, "JSmith" would not be a valid user name for an Audit Vault and Database Firewall user account on secured targets.
See Also:
Scripts for Oracle AVDF Account Privileges on Secured Targets for information on scripts to configure user account privileges for database secured target types.
Learn about configuring and managing audit trail collection.
In order to start collecting audit data, you must configure an audit trail for each secured target in the Audit Vault Server, and then start the audit trail collection manually.
This procedure assumes that the Audit Vault Agent is installed on the same host computer as the secured target.
Prerequisites
Before configuring an audit trail for any secured target, you must:
Add the secured target in the Audit Vault Server. See Registering or Removing Secured Targets in the Audit Vault Server for details.
Register the host machine. This is usually the machine where both the secured target resides and the Audit Vault Agent is deployed. See Registering Hosts and Deploying the Agent.
Deploy and activate the Audit Vault Agent on the host machine. See Deploying and Activating the Audit Vault Agent on Host Computers.
For MySQL secured targets, run the XML transformation utility. For IBM DB2 secured targets, ensure that the binary audit file has been converted to ASCII format before starting an audit trail. See Converting Audit Record Format For Collection.
Log in to the Audit Vault Server console as an administrator. See Logging in to the Audit Vault Server Console UI for more information.
To configure an audit trail for a secured target:
Click the Secured Targets tab.
Under Monitoring, click Audit Trails.
The Audit Trails page appears, listing the configured audit trails and their status.
In the Audit Trails page, click Add.
From the Audit Trail Type 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 step 7) if you want to collect audit data from rsyslog
files. See Table B-23 for details.
Important: Be sure that records generated by rsyslog
have the same timezone information as the Audit Vault Agent running on the Collection Host.
TABLE
TRANSACTION LOG
For this audit trail type, ensure that the secured target database has a fully qualified database name. See the GLOBAL_NAMES
setting in Table C-1.
See Table B-17 for details on which type(s) of audit trails can be collected for a specific secured target type.
In the Collection Host field, click the up-arrow icon to display a search box, and then find and select the host computer where the Audit Vault Agent is deployed.
In the Secured Target field, click the up-arrow icon to display a search box, and then find and select the secured target.
In the Trail Location field, enter the location of the audit trail on the secured target computer, for example, sys.aud$
.
The trail location depends on the type of secured target.
Note 1: If you selected DIRECTORY for Audit Trail Type, the Trail Location must be a directory mask.
Note 2: If you selected SYSLOG for Audit Trail Type, and both syslog
and rsyslog
file types are present, enter the exact directory location of either the syslog
or rsyslog
files. See Table B-23 for important details.
If you have deployed plug-ins for this type of secured target, select the plug-in from the Collection Plug-in drop-down list.
Click Save.
The audit trail is added to the list on the Audit Trails page. The collection status displays a red down-arrow (stopped) initially. The audit trail starts automatically shortly after it is added.
See Also:
Summary of Data Collected for Each Audit Trail Type for descriptions of data collected.
Audit Trail Locations for supported trail locations.
An audit trail starts automatically shortly after you add it. In order 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 secured 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 secured target:
To check the status of audit trails:
Log in to the Audit Vault Server console as an administrator.
Click the Secured Targets tab.
Click Audit Trails.
The Audit Trails page lists audit trails and their status in the Collection Status column, along with other details. The status may 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 Secured Target to generate new audit data.
Starting - Collection process is starting.
Collecting - Trail is currently actively collecting audit data.
Stopping - Collection process is stopping.
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 secured 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, you can click the Hosts tab, and in the Agent Details column for that host click View Audit Trails.
Note:
If an audit trail fails to start, you can get more information by showing the Error Message column:
In the Audit Trails page, click the Actions button, then click Select Columns.
Double-click Error Message on the left to move it to the Display in Report box, and then click Apply.
See Also:
Working with Lists of Objects in the UI to sort and filter the audit trail list.
With established audit trail collection, audit data is retained in the 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 secured target, the audit data collected may contain records that fall into the Months Archived period in the retention policy assigned to this secured 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 secured 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
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.
Running The XML Transformation Utility For MySQL Auditing
For MySQL secured 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.
Prerequisites
Register the MySQL secured target in the Audit Vault Server. See Registering or Removing Secured Targets in the Audit Vault Server.
Deploy the Audit Vault Agent on the MySQL host machine. See Deploying the Audit Vault Agent on the Host Computer.
To run the XML Transformation Utility:
Converting Binary Audit Files to ASCII Format For IBM DB2 Auditing
IBM DB2 creates its audit log files in a binary file format that is separate from the DB2 database. For IBM DB2 secured 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.
To convert the binary DB2 Audit File to an ASCII file:
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 secured target database name in the scheduled task.
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 (REDO) audit data collection from Oracle RAC environment, 1 audit trail is sufficient. |
See Also:
Adding an Audit Trail in the Audit Vault Server to configure an audit trail.
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 secured 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 you must create a separate secured target for each PDB instance.
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 |
---|---|
|
Note: Audit collection from CDB_UNIFIED_AUDIT_TRAIL is not supported. |
|
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. |
|
Transaction log collection is not supported for PDB or CDB. |
|
Audit policies can be provisioned or retrieved by treating every PDB as an independent secured target. |
See Also:
Adding an Audit Trail in the Audit Vault Server to configure an audit trail.
Learn about configuring enforcement 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.
If you are monitoring databases with a Database Firewall, you must configure one enforcement point for every secured target database that you want to monitor with the firewall. The enforcement point configuration lets you specify the firewall monitoring mode (monitoring only or blocking), identify the secured target database being monitored, the network traffic sources to that database, and the Database Firewall used for the enforcement point.
Before configuring enforcement points, configure network traffic sources as part of database firewall configuration.
Configure each enforcement point at the Audit Vault Server console. If you have configured a resilient pair of Audit Vault Servers, configure the enforcement points on the primary server.
Prerequisites
Ensure that you have configured traffic sources on the Database Firewall you plan to use for this enforcement point. See Configuring Database Firewall and its Traffic Sources on Your Network for more information.
Log in to the Audit Vault Server console as an administrator. See Logging in to the Audit Vault Server Console UI for more information.
Note:
When you use a Database Firewall in DPE 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:
Configuring High Availability for details on configuring a resilient pair of servers.
Oracle Audit Vault and Database Firewall Concepts Guide for more information on different modes.
Configuring Traffic Sources for more information on traffic sources.
After you create an enforcement point, you can modify it to change its settings, or to enable database response monitoring, database interrogation, and/or host monitoring.
Advanced settings in the enforcement point let you configure Oracle Audit Vault and Database Firewall to work with BIG-IP Application Security Manager (ASM).
To modify an enforcement point:
Stored procedure auditing (SPA) enables Oracle Audit Vault and Database Firewall auditors to audit changes to stored procedures on secured 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. SPA is supported for all database secured targets supported by Oracle Audit Vault and Database Firewall.
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 secured target. Oracle Audit Vault and Database Firewall provides scripts for setting up these privileges. Run the scripts specific to the secured 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 Secured Target configuration.
Learn about configuring and using database interrogation.
Database interrogation allows the Database Firewall to interrogate supported database secured targets for specific information. The information collected depends on the database type. This section describes two ways to use database interrogation:
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.
In Audit Vault and Database Firewall, enable database interrogation in the enforcement point that monitors the secured target database.
If you are using the Database Firewall to monitor an Oracle Database secured 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.
Topics
Use this procedure to enable Database Interrogation.
Prerequisite
Log in to the Audit Vault Server console as an administrator. See Logging in to the Audit Vault Server Console UI for more information.
Learn about configuring Oracle Database Firewall for databases that use network encryption.
To configure Database Interrogation for an Oracle Database that uses Network Encryption, follow steps in this section:
Learn how to apply the 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:
To run the Network Encryption integration script:
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:
In the Administration console of the Database Firewall that will be monitoring this Oracle Database, in the System menu, click Public Keys .
Copy the public key under Oracle Advanced Security Decryption 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 enforcement point resiliency, when you have more than one Database Firewall monitoring this secured 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.
Modify the sqlnet.ora
file in the Oracle Database to include the public key and to require Network Encryption native traffic encryption:
Put the file you created in Step 2 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 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 sqlntet.ora
file contains the optional parameter SQLNET.ENCRYPTION_CLIENT
, its value must not be REJECTED
. Otherwise, an error will occur.
Save and close the sqlnet.ora
file.
See Also:
Oracle Database Security Guide for more information on network encryption.
Follow the procedure in "Enabling Database Interrogation" to complete the Database Interrogation setup for an Oracle Database that uses Network Encryption.
Enabling the Database Response Monitoring feature allows the Database Firewall to record responses that the secured target database makes to login requests, logout requests and SQL statements sent from database clients, as shown in Figure 6-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 6-1 illustrates the process flow of database response monitoring.
The Oracle AVDF auditor can view database responses in audit reports.
Database Response Monitoring records database responses for all SQL statements, logins, and logouts that are logged the Database Firewall policy
The information recorded includes the response interpreted by Oracle AVDF (such as "statement fail"), the detailed status information from the database, and the database response text (which may be displayed at the database client).
Topics
Data security between an AVDF agent and an Oracle Database secure 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 secure target has been setup to accept TCPS/SSL connections, then follow these steps to configure the agent:
Ensure that in the secure 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 Secured Targets tab.
Select the name of the secured target that you want to modify.
In the Modify Secured Target page, do the following:
In the Secured Target Location (For Auditing) area, 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 Secured 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.