This section describes managing day-to-day Audit Vault Server and Database Firewall operations once the initial configuration is completed.
Topics
Managing Audit Vault Server Settings, Status, and Maintenance Operations
Changing the Audit Vault Server's Network or Services Configuration
Managing Server Connectors for Email, Syslog, and Arcsight SIEM
Enabling Oracle Database In-Memory for the Audit Vault Server
Downloading the Oracle Audit Vault and Database Firewall SDK
You can run a diagnostics check for the Audit Vault Server that tracks activities such as whether necessary files exist, whether the HTTP server is running, whether the Oracle listener and other processes are running.
To run Audit Vault Server diagnostics:
See Also:
Viewing the Status and Diagnostics Report for a Database Firewall if you need to view diagnostic information for an individual Database Firewall.
When you need to debug the Audit Vault Server appliance, you can generate and download a detailed diagnostics report that captures a wide range of information such as ports that are used in the overall configuration, configuration settings, and so on.
You can adjust the amount of diagnostics information gathered by setting the LOGLEVEL
for different server components using the AVCLI
ALTER SYSTEM SET
command. When you perform the download operation, the process captures the log and trace file information, along with configuration information that is available at that time. Be aware that a change in the log level only affects those trace or log files that are generated after the change is made. For example, if you encounter a problem after you set the log level to DEBUG
, then you must reproduce the issue before you run the procedure in this section to download the diagnostic report. Otherwise, the debug or trace is not captured in the report.
Be aware, however, that the DEBUG
setting will generate many files, which can affect the performance of your system. Therefore, only use this setting on a temporary basis, when you are trying to diagnose problems. After you find and correct the problem, then set DEBUG
to the original setting, such as ERROR
.
To download zip file for Audit Vault Server diagnostics:
You must provide the server's public key to another system in order to upload archive files from the Audit Vault Server to that system. This public key must be added to the authorized_keys
file for that system. For a typical linux installation, this file is in the user's home directory under .ssh
, and its permissions must be set to 0600, or even 0400.
To access the server public key:
You can set different logging levels for these system components:
Table 14-1 Components with Variable Logging Levels
Agent | Alert |
---|---|
Archive and Retrieve |
Background Server Process |
Data Repository |
Database Firewall |
Notification |
Plug-in Management |
Policy Management |
Report Generation |
SAN Storage |
Transaction Log Trail |
Web Console UI (has three logging levels only) |
N/A |
Different logging levels provide more or less information in system logs and affect the size of those logs. The following logging levels are listed in the order of amount of information written to log files, with debug providing the most information:
error - Reports only critical information. This generates the least amount of log messages.
warning - (Default) Reports warning and error messages (not supported for Web Console UI).
info - Writes informational, warning, and error messages. This level is appropriate for testing environments but not for production.
debug - Writes detailed messages for debugging purposes. This generates the most amount of log messages. Debug logs may contain sensitive information about the state of your system. Add the debug log level only when necessary, and remove it once debugging is complete.
Setting or Changing Logging Levels
To set logging levels:
Log in to the Audit Vault Server console as a super administrator.
Click the Settings tab, and then under the System menu, click Diagnostics.
For any of the components listed, select a logging level from the drop-down list.
Click Save.
Clearing Diagnostic Logs
To clear diagnostic logs from the Audit Vault Server:
Log in to the Audit Vault Server console as a super administrator.
Click the Settings tab, and then under the System menu, click Log Management.
Click Clear Diagnostic Logs, then click OK to confirm.
A confirmation message is displayed when logs have been cleared.
To set or change the network or services configuration, follow the relevant procedure below:
To set or change connector information, follow the relevant procedure below:
Note:
Micro Focus Security ArcSight SIEM (previously known as HP ArcSight SIEM) is deprecated in 12.2.0.8.0
and is desupported in 12.2.0.9.0
. Use the syslog
integration feature instead.
To start an archive job, you must have configured at least one archive location.
Oracle recommends that you use NFS to transfer data to an archive location. If you use Secure Copy (SCP) or Windows File Sharing (SMB) to transfer data to an archive location, then your data files are first copied to a staging area in the Audit Vault Server. Therefore, you must ensure that there is additional space in the file system. Otherwise the data file copying may fail. Be aware that transferring large files using SCP or SMB may take a long time.
Note:
You can register a remote filesystem using the AVCLI utility, so that the filesystem can be selected here. See REGISTER REMOTE FILESYSTEM for details.
To start an archive job:
Note:
Monitoring Jobs to view the progress of an archive job from the Jobs page > System menu > Settings tab.
Defining Archive Locations to create archiving locations.
About Archiving And Retrieving Data In Oracle Audit Vault And Database Firewall
You can retrieve data files for a specific secured target and time range. The Months Archived value in a secured targets retention (archiving) policy determines how long the secured target's data is available to retrieve to the Audit Vault Server. When the Months Archived period expires, the data is no longer available to retrieve, however, it continues to reside in the archive location.
To retrieve data files from an archive:
Topics
Learn about repository encryption.
Encryption of the Oracle Audit Vault Server's event repository is enabled on new installations of Oracle Audit Vault and Database Firewall 12.2. This feature uses Oracle Database's Transparent Data Encryption (TDE) to encrypt all audit event data stored in the Audit Vault Server, data stored in external SAN storage, and data stored in archive locations.
Rotating encryption keys adds a layer of security to your encrypted data.
You should rotate the master encryption key for the Audit Vault Server's event repository on a regular basis, according to your organization's guidelines. It is also a good practice to rotate the encryption key as needed, for example, when a person who had access to your master key leaves your organization.
Note:
If you restore the Audit Vault Server from a backup, the restore operation restores the system to a point in time. Therefore, restoring the system may reinstate an older encryption key.
The keystore password for repository encryption is originally set as a required post-installation step. It is the same as the Event Repository Encryption password. You only need this password for restore operations, not backup operations. Thereafter, you can change this password in the Audit Vault Server console.
To change the Event Repository Encryption password:
It is important to perform regular backups of the Audit Vault Server, which include the TDE wallet. However, if you cannot back up the Audit Vault Server, then you should at a minimum do regular backups of the TDE wallet at this location:
/usr/local/dbfw/etc/wallets/dbfwdb_wallet
Oracle Audit Vault and Database Firewall does not provide the ability to back up wallets. You should securely back the wallet up in a remote location.
Learn about data encryption on upgraded instances in Oracle Audit Vault Server.
Phases of Data Encryption
This topic contains a detailed procedure that can be used to start data encryption process.
WARNING:
Do not run data encryption processes on a newly installed Oracle Audit Vault Server or on a system that has been upgraded from fresh install of release Oracle Database 12.2.x. With versions of Oracle Database 12.2.0 and above, all of the new installations have encryption enabled automatically. Thus, all of the table spaces are encrypted by default.
The data encryption process happens in two phases:
Enabling Data Encryption:
This phase is automatic and data encryption is enabled while performing an Audit Vault Server upgrade. The upgrade process prompts for a keystore password on standalone and primary systems. Upon successful upgrade, data encryption is automatically enabled. The newly created table spaces thereafter are automatically encrypted. However, table spaces created before upgrade continue to be in clear text.
Encrypting existing clear text table spaces:
This phase is triggered by the user. To encrypt the existing clear text table spaces, the user must initiate the data encryption process. This process is triggered by running the /usr/local/dbfw/bin/avdf_data_encryption.sh
script. The detailed steps for encrypting existing clear text table spaces triggered by the user are available in this topic.
Before you begin
The rate of encryption is approximately 20 to 50 seconds to encrypt 1 GiB of data, depending on the hardware profile of the system.
To begin the process of encrypting the table spaces, the user must execute the /usr/local/dbfw/bin/avdf_data_encryption.sh
script as root.
Ensure to take AVDF backup prior to the encryption process.
The user must have root operating system user privileges to execute this procedure. Ensure the proper privileges are obtained.
The encryption process script must be executed on standalone system or on the primary in a HA set up. Ensure that the standby system is also up and running before running the encryption script. The script may result in an error if the standby system is down. The script encrypts table spaces on both the primary and standby system.
Ensure that the database is up and running prior to executing the encryption process. To verify the status of the database, log in as root user and execute the command /etc/init.d/dbfwdb status
The encryption process script stops all the jobs running in the background. Ensure there is no critical process running that may be impacted.
Note:
Data encryption is not completely enabled on HA system, until the primary is successfully upgraded. After a successful upgrade, all clear text table spaces are in one of the following states:
online
offline local (offline but the data file resides on the AVS)
offline remote (offline but the data files reside on the remote archive location)
online retrieved by user
online retrieved by a trail
To start Data Encryption process:
Topics
The Oracle Audit Vault Server backup utility backs up all Oracle Audit Vault Server data as well as configuration settings.
You can perform full backups as well as incremental backups, which contain only new data and configuration changes since the previous hot backup. For example, you might do full backups on Sundays, then do incremental backups on Mondays, Wednesdays, and Fridays.
The backup utility can perform hot or cold backups. A hot backup runs while Oracle Audit Vault Server is up and running. A cold backup shuts down Oracle Audit Vault Server before running.
You can store the backup files on the Audit Vault Server, but it is better to store them in a remote location, such as an NFS file system, in case the Audit Vault Server computer fails. The location of the backup files should be accessible by the Audit Vault Server.
The restore utility lets you restore the data and configuration to a new Audit Vault Server from backup files. The computer on which you do a restore must have the same version of Oracle Audit Vault and Database Firewall as the computer from which you took the backups.
Note:
The user must note to have the same path of the backup while performing restore operation. For example, if the backup directory is /usr/local/backup
, then while performing restore operation specify /usr/local/backup
, as the backup directory.
The Database Firewall does not need to be backed up. The Audit Vault Server can reapply all existing Enforcement Point configuration to the Database Firewall. See Restore Enforcement Points for more information.
The backup functionality does not backup archived files. The data files in the archive location are not backed up by avbackup
as they may be located on a remote file system. In case those files are on NFS mount point, then they are accessible after restoring on a new system with the same mount points setup as before.
NFS is a mount point on the Audit Vault Server. If you want to replace NFS server, then make sure the Audit Vault Server does not access the mount point.
The restore operation takes time to complete. It depends on the amount of data being restored. In case the restore operation is being performed using SSH or Terminus, the connection may drop if there is no user interaction. Ensure to keep the SSH or Terminus alive.
How Backup and Restore Operations Work in a High Availability Configuration
If you are using a high availability configuration, then be aware that Oracle Audit Vault and Database Firewall performs the backup only on the primary server, not the secondary server. When you perform a restore operation from the high availability primary backup, then the final restored system becomes a standalone server, which is not in high availability configuration.
Repository Encryption and Backup Encryption
If you did a full install of Oracle Audit Vault and Database Firewall (as opposed to an upgrade), the stored data in the Audit Vault Server is automatically encrypted using Oracle Database Transparent Data Encryption (TDE). This feature is not available on upgraded systems.
If you are restoring from backup files where the system backed up had TDE enabled, you will be prompted for the TDE keystore password during the restore. You must use the TDE keystore password that was in place when the backup was taken. Since the TDE keystore password may change after a backup, it is important that you keep track of the keystore password in place at the time you do each backup.
In addition, you can set encryption on backup files regardless of whether you have the TDE feature available. In this case, you will need a backup encryption password, which will be required if you do a restore.
Therefore, you may need to provide up to two passwords when doing a restore.
See Also:
Managing Repository Encryption for more information on TDE.
Configuring High Availability for information about configuring high availability for Oracle Audit Vault and Database Firewall.
Determine the amount of space you need for backup files.
The amount of space needed for backup files is determined by the size of your Oracle Audit Vault Server database. You can obtain an upper estimate of the backup file size for the database by running the following SQL query on the Audit Vault Server:
sqlplus system Enter password: password SELECT SUM (BYTES)/1024/1024/1024||' GB' FROM DBA_DATA_FILESFoot 1
Note:
Ensure that the RAM size and Disk size in the new system is equal or greater than the original system. This ensures that out of memory
error is not encountered while performing the backup and restore task.
The backup process does not include the SAN configuration. Ensure the new system has sufficient disk space before performing restore. For more information on the disk space needed, refer to the info.txt file available in the backup directory.
The restore system requires at least the same amount of memory and disk space as the backup system. Otherwise, the restore operation fails.
Topics
To configure the backup utility:
If you are using a high availability configuration and want to perform a cold backup, then do the following:
Log in to the Audit Vault Server console.
Select Settings.
Under System, select High Availability.
Select the Disable Failover button.
In the Confirmation dialog, click OK.
Log in to the Audit Vault Server as root
.
Run the command below and input information when prompted:
/var/lib/oracle/dbfw/bin/avbackup config
The system prompts you for the following:
BACKUP_DIR
This prompt specifies the directory where the backup files are stored. The directory name is limited to 200 character. After you specify this directory, do not change this directory path, because Oracle Recovery Manager (RMAN) tracks the backup files in this directory. Files are written to this directory by the Oracle user . All access to this directory is handled by the user oracle
. (The user oracle
is in the oinstall
group.) Oracle automatically uses this directory path during the restore operation.
This directory should be accessible by the Audit Vault Server, and owned by oracle:oinstall
. This value should never change once set, and must be the same whether you are doing a full or an incremental backup.
Do not put closed backups and online backups in the same BACKUP_DIR
location. Follow these guidelines:
Place the online incremental 1 backup on top of the online full (incremental 0) backup in the same BACKUP_DIR
directory. Alternatively, you can place a closed incremental 1 backup on top of a closed incremental 0 backup in the same BACKUP_DIR
directory.
Do not place a closed incremental 1 backup on top of an online incremental 0 backup in the same BACKUP_DIR
directory, nor an online incremental 1 backup on top of a closed incremental 0 backup in the same BACKUP_DIR
directory. Doing so cause the restore operation of these backup files to fail.
The same directory path will be used automatically during the restore operation. This backup destination must be a mounted file system with enough free space to hold the backup files. This may be an NFS file system (to mount this, see "Remote File System AVCLI Commands"), but not a SAN storage location.
For example:
BACKUP_DIR[/backup]:/AVBACKUP
TMP_DIR
This directory is a temporary working parent directory where the work directory is created. This directory must have at least 100 MB of free space. The oracle
user must have read-write access to TMP_DIR
.
For example:
TMP_DIR[/tmp]:/usr/local/dbfw/tmp/BCKTMP
KEEP_LOGS
This setting determines where the log files are kept after a successful backup operation. Log files are always kept after a failure. Enter YES
to retain logs upon successful backup or restore. Enter NO
to automatically delete logs after successful backup or restore.
For example:
KEEP_LOGS[NO]:yes
INCREMENTAL_STRATEGY
This setting selects the RMAN incremental backup level. Enter 0
to do a full backup. Enter 1
to do an incremental backup. An incremental backup backs up the changes since the previous backup.
For example:
INCREMENTAL[0]:0
BACKUP_TYPE
This setting specifies the type of backup to perform. Enter HOT
or COLD
. A hot backup runs while the Audit Vault Server database is running. However, archive log mode must be enabled during the hot backup process. If archive log mode is not enabled, then you must shut down the database to turn on archive log mode, and then restart the database. The operation to turn on archive log mode is quick, but a shutdown and restart must be performed. For a cold backup, the Audit Vault server database is shut down during the backup process. You should schedule a maintenance shutdown before you perform a cold backup.
For example:
BACKUP_TYPE[HOT]:COLD
PASSWD
(Optional) This setting sets an encryption password for the backup files. You will need this password when you restore from backup files. Unlike other parameters, the password parameter cannot be automatically retrieved from the backup. If you omit this setting, then the backup files are not encrypted.
For example:
PASSWD[-- not set --]: password Confirm password: password
MAXPIECESIZE
This setting specifies the maximum backup file size. The valid maximum file size depends on the actual file system. This is set only if CHANNEL_PARALLELISM
is set to 1.
For example:
MAXPIECESIZE[2G]:
CHANNEL_PARALLELISM
This setting specifies the number of channels (processes) used in executing commands. It should match the number of devices accessed.
If parallelism is more than 1, then the user is prompted for location and section size. If parallelism is equal to 1, then the user is prompted for MAXPIECESIZE
.
For example: One for each physical disk.
If the number of channels is larger than 1, then specify the location for each channel and section size next.
CHANNEL_PARALLELISM[1]:4
Best Practice:
In case there are multiple physical disks, then it is advised to setCHANNEL_PARALLELISM
to an appropriate value according to the number of physical disks. To backup large databases, set CHANNEL_PARALLELISM
and SECTION_SIZE
according to the actual physical disks setup to improve the time needed to backup the system.CHANNEL_LOCATION
Specifies the location for channel. The user can set multiple locations for each channel. All locations can be the same for all channels. The location is the full path for backup files. To improve performance, the user must specify different locations on a different physical hard disk. The user may specify all locations to the same path.
For example:
CHANNEL_LOCATION_1[]:/disk_1 CHANNEL_LOCATION_2[]:/disk_2 CHANNEL_LOCATION_3[]:/disk_3 CHANNEL_LOCATION_4[]:/disk_4
SECTION_SIZE
The section size is smaller than the largest data file or parallelism and smaller than the size the physical disk can handle.
For example:
SECTION_SIZE[]:32G
USE_NEW_IP
For restore operation it specifies the new (current) IP address of the restore system, instead of the old IP address from the backup system. The allowed values are Y
or N
.
USE_NEW_IP[N]:Y
REDUNDANCY
This setting specifies a number that sets how many full backups to keep. When you run the backup
command, backups that are older than this number of backups (as well as their related incremental backups) are deleted. More redundancy requires more disk space for the backup, specified in the BACKUP_DIR
parameter.
For example:
REDUNDANCY[1]:
After you complete these settings, a summary of your selection is displayed similar to the following:
BACKUP_DIR=/long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars TMP_DIR=/tmp KEEP_LOGS=NO INCREMENTAL=0 BACKUP_TYPE=HOT PASSWD=-- not set -- CHANNEL_PARALLELISM=3 CHANNEL_LOCATION=/long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars /long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars /long_backup_directory_name_so_three_times_is_more_than_two_hundred_chars SECTION_SIZE=500M REDUNDANCY=1 USE_NEW_IP=Y
If you changed the archivelog mode during the backup configuration process, after the database restarts, then ensure that the Java Framework internal tool is running on the Audit Vault Server.
For example:
/usr/local/dbfw/bin/javafwk status
If the output is Java framework process is stopped
, then restart it as follows:
/usr/local/dbfw/bin/javafwk start
This step validates the backup. It performs the validate operation on the last backup that you created, regardless the settings of the avbackup config
file.
Note:
The backup configuration file is release specific. It works only for the same release. It is advisable to execute the avbackup config
command and create a new configuration file before performing the backup operation after every upgrade.
The location of closed backup and online backup must be different. Do not use the same BACKUP_DIR
location. Once you specify this location, it is advisable not to change the directory path as Oracle Recovery Manager (RMAN) tracks the backup files in this directory.
Note:
If you use avbackup to do regular backup, or setup cron job for full and incremental backup, or using your own script to perform a backup operation, then:
The avbackup tool performs a back up of the database and the configuration of Oracle Audit Vault and Database Firewall.
RMAN backup is only backing up the Oracle Audit Vault and Database Firewall database. RMAN plays a crucial role in the archive, backup, and upgrade processes. The default RMAN settings of the Audit Vault Server must not be altered.
For RMAN only backup, in the event of a system crash, you cannot restore on a new system. The backup does not work as the original configuration is missing.
The backup strategy with RMAN works only in the event of the database crash and the system is still running.
To resolve this issue of avbackup configuration execute the following commands. These commands are example only and work for the cron job setup. However, any issues resulting out of this is not supported by Oracle.
Task | Procedure |
---|---|
To run the avbackup configuration once for the full backup. |
Move |
To run the avbackup configuration once for the full incremental backup. |
Move |
To setup one cron job for full backup. |
Copy |
To setup one cron job for incremental backup. |
Copy |
Topics
The following actions take place after you restore the contents of the Audit Vault Server:
All database accounts are replaced by the accounts from the earlier system. After the restore process, you can modify these accounts as needed.
The keystore password is replaced by the keystore password that was used in the earlier system. After the restore process is complete, you can modify the keystore password as needed.
Operating system accounts are not affected by the restore process. Therefore, the passwords that you set for the root
and support
accounts remain the same as before the restore.
Examine the prerequisites for restoring Audit Vault Server.
Before restoring backup files to a new Audit Vault Server:
Note:
USE_NEW_IP
parameter to N
while executing the avbackup config
command on the restore system. For this case, if the original system is still up and running, the restore fails because it cannot switch the IP address which is in use.USE_NEW_IP
parameter to Y
while executing the avbackup config
command on the restore system. In this case, you do not need to restore on the same subnet as the backup system. You may use this configuration when you are restoring on a different data center, which is on a different subnet, or restore the backup on a new IP while the backup system is up and running.To restore the new Audit Vault Server from backup files, first you configure the backup utility on the new Audit Vault Server.
Follow the same procedure as in "Step 1: Configure the Backup Utility", providing the same values for BACKUP_DIR
and PASSWD
as you did on the backed up system.
Learn how to restore a backup to a new system with a new or different IP address.
After performing the restore operation, the system has the same IP address. The user has an option to keep the new IP address without disrupting the service and functionality of the system. If the new IP address is used, the system restores the database and keeps the new IP address. This section contains the necessary steps to be performed after the restore operation so that the system or Audit Vault Server does not retain the original IP address by default.
Follow these steps after the restore operation when the system has a new IP address:
Note:
Upon completion of restore process on a new IP, the console certificate in the backup system is no longer valid or in use. You must generate a new certificate and upload it.
The restore operation takes time to complete. It depends on the amount of data being restored. In case the restore operation is being performed using SSH or Terminus, the connection may drop if there is no user interaction. Ensure to keep the SSH or Terminus alive.
Topics
You can improve the performance of Oracle Audit Vault and Database Firewall reports and dashboards by enabling Oracle Database In-Memory in the Audit Vault Server. This feature lets you allocate a certain amount of system memory for audit data for a specified period of time. The audit data residing in-memory then becomes available more quickly for use in dashboards and reports.
Based on the amount of system memory you allocate for Oracle Database In-Memory, and the average amount of data collected per day in your environment, Oracle Audit Vault and Database Firewall calculates the number of days of audit data that will fit into that allocated memory. From this calculation, the system displays the in-memory date range to Oracle Audit Vault and Database Firewall auditors, letting them know the time ranges for which they can obtain faster reports. For example, if 1 gigabyte can accommodate 2 days of data, and you have provided 1 gigabyte of memory for Oracle Database In-Memory, then 2 days of the latest data will be put in Oracle Database In-Memory. If you provide 2 gigabytes of memory to Oracle Database In-Memory, then 4 days of data will go to Oracle Database In-Memory.
Before enabling Oracle Database In-Memory, be sure to estimate the amount of memory needed for your current and future secured targets and enforcement points. You can find some guidelines for calculating RAM requirements in the Oracle Audit Vault and Database Firewall Sizing Advice (MOS Doc ID 2223771.1). This document can be obtained from Oracle Support. After estimating your normal RAM requirements, if you want to use the Oracle Database In-Memory feature, estimate how much RAM you want to use for in-memory database and add that to your RAM requirement. If you enable this feature, you must allocate at least 1 GB for Oracle Database In-Memory.
After you enable Oracle Database In-Memory, you can choose to have it perform based on a date range or to keep the latest data. This procedure does not restart the database and has no effect on any components such as the agent collectors.
You can deploy additional plug-ins to support more types of secured targets, or un-deploy plug-ins that are no longer needed.
You can monitor server table space usage in Oracle Audit Vault Server.
Oracle Audit Vault Server contains the SYSAUX
tablespace, which by default has one data file. The SYSAUX
tablespace is a locally managed tablespace with automatic segment space management.
You should monitor the space usage for the SYSAUX
tablespace and create additional data files for storage as needed.
See Also:
Oracle Database Administrator's Guide for more information about the ALTER TABLESPACE
SQL statement, which you can use to add more storage data files.
Oracle Database SQL Tuning Guide for information about optimizing a tablespace.
You can monitor archive log disk space use to manage your system.
By default, ARCHIVELOG
mode is disabled in Oracle Audit Vault Server. The ARCHIVELOG
mode once enabled, copies the filled online redo logs to disk. This enables you to back up the database while it is open and being accessed by users, and to recover the database to any desired point in time. You should monitor the disk space usage for the redo logs.
See Also:
Oracle Database Administrator’s Guide for more information to set up archive log mode and other general information about Archive logs.
Method 1: Using the LOG_ARCHIVE_DEST_n Parameter for more information about changing the LOG_ARCHIVE_DEST_
n
location to relocate these archive log files to larger disks.
Oracle Database Backup and Recovery User’s Guide for information about backing up the archive logs.
Monitoring server flash recovery area is advisable to ensure you have enough space for backups.
By default, Oracle Audit Vault Server has the following initialization parameter settings:
The DB_RECOVERY_FILE_DEST_SIZE
initialization parameter is set to 2 GB.
The DB_RECOVERY_FILE_DEST
initialization parameter is set to the default flash recovery area, typically the ORACLE_HOME/flash_recovery_area
directory.
Ensure that the size of your flash recovery area is large enough to hold a copy of all data files, all incremental backups, online redo logs, archived redo logs not yet backed up on tape, control files, and control file auto backups. This space can fill quickly, depending on the number of audit trails configured, the scope of the audit record collection being administered, and the backup and archive plans that you have in place.
You can use Oracle Enterprise Manager Database Control to monitor the available space in the flash recovery area. Monitor the percent space that is usable in the Usable Flash Recovery Area field under the High Availability section on the Home page. Check the alert log in the Database Console for messages. When the used space in the flash recovery area reaches 85 percent, a warning message is sent to the alert log. When the used space in the flash recovery area reaches 97 percent, a critical warning message is sent to the alert log.
You can manage space in the flash recovery area by increasing the value of the DB_RECOVERY_FILE_DEST_SIZE
initialization parameter to accommodate these files and to set the DB_RECOVERY_FILE_DEST
initialization parameter to a value where more disk space is available.
There are some jobs on the Audit Vault Server which needs to be scheduled for proper and effective functioning of the system. These jobs should run during a period when the Audit Vault server usage is low. For example, during the night.
The user can schedule these jobs as per their time zone, using this functionality.
To schedule maintenance jobs on the Audit Vault Server, follow this procedure:
Topics
As an alternative to using the Audit Vault Server console (Web) UI, you can use the AVCLI command line interface to manage Oracle Audit Vault and Database Firewall, including registering and configuring secured targets and their connections to the Audit Vault Server.
You can run AVCLI from the Audit Vault Server, or download the AVCLI utility from the Audit Vault Server and install and run the utility on another computer.
The syntax used for AVCLI is similar to SQL*Plus. For example, from within AVCLI, you can use the CONNECT
command to log in as another user. In addition, the AVCLI commands are not case sensitive. In this manual, the commands are entered in upper case.
Note:
Set the JAVA_HOME
environment variable to point to JDK installation directory. On Windows, add %JAVA_HOME%\bin
to the PATH environment variable.
See Also:
AVCLI Commands Reference for details of the available AVCLI commands.
You can invoke AVCLI interactively (that is, you must provide a password) with or without a user name. You can also start AVCLI by using stored credentials. This section contains instructions for the two methods of starting AVCLI.
Topics
Follow one of the methods below to invoke AVCLI interactively. Except for a few commands where it is optional, all AVCLI commands must end in a semi-colon (;). For simplicity, in this guide we use a semi-colon for all AVCLI commands.
Using Interactive Mode with a User Name
The command syntax for invoking AVCLI with a user name is:
avcli -u username Enter password: password
For example:
avcli -u psmith AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. Enter password for 'psmith': password Connected to: Oracle Audit Vault Server 12.2.0.0.0 AVCLI>
Using Interactive Mode Without a User Name
If you invoke AVCLI without a user name, you must connect to the Audit Vault Server as a valid user who has been granted the AV_ADMIN
role. The command syntax for invoking AVCLI with a user name is:
avcli AVCLI> CONNECT [username];
For example:
avcli AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. AVCLI> CONNECT psmith Enter password: password; Connected.
If you do not enter a user name you will be prompted for one.
Storing credentials for an Oracle AVDF administrator is useful when you need to run AVCLI scripts without user intervention or without putting credentials in the script.
If you are the AVCLI owner (that is, you installed the AVCLI utility) you can store the credentials of one Oracle AVDF administrator in the AVCLI wallet. Thereafter, that administrator can invoke AVCLI without providing credentials, and can also run scripts without intervention.
Storing or Overwriting Administrator Credentials
As a prerequisite for an administrator to be able to invoke AVCLI without credentials (non-interactively), the AVCLI owner must store that administrator's credentials. As the AVCLI owner, you can store credentials for only one administrator.
To store credentials for the designated administrator:
As the AVCLI owner, run avcli
without connecting to the Audit Vault Server. For example:
avcli
AVCLI : Release Release 12.2.0.0.0 - Production on timestamp
Copyright (c) 1996, 2015 Oracle. All Rights Reserved.
AVCLI>
Run the command STORE CREDENTIALS
and provide the administrator's credentials when prompted. For example:
AVCLI> STORE CREDENTIALS; Enter user name: username Enter password:password Re-enter password:password
Any previously stored credentials will be overwritten.
Note:
If this administrator's password changes, follow this procedure again to store the new credentials.
Starting AVCLI Using Stored Credentials (Non-Interactively)
To start AVCLI without having to enter credentials, your credentials must be stored, as detailed in the previous procedure.
There are two ways of starting AVCLI using stored credentials:
From the shell
In the Audit Vault Server, enter:
avcli /@
This command logs you in to AVCLI and connects to the Audit Vault Server.
From within AVCLI
If you have invoked AVCLI from the shell without credentials (by typing avcli
), connect to the Audit Vault Server by entering:
AVCLI> CONNECT /@;
For example:
avcli
AVCLI : Release 12.2.0.0.0 - Production on timestamp
Copyright (c) 1996, 2015 Oracle. All Rights Reserved.
AVCLI> CONNECT /@;
Connected.
See Also:
You can run AVCLI scripts without user intervention or putting credentials inside the script.
.av
extension.
Here is an example AVCLI script:
#Here is an AVCLI command start collection for secured target sample_target1 using host sample_host1 from table SYS.AUD$; #More AVCLI commands #Quit command quit;
When you invoke AVCLI, you can specify the following log levels. Oracle Audit Vault and Database Firewall writes the logs to the Audit Vault Server $ORACLE_HOME/av/log
directory.
info
: Logs informational and error messages
warning
: Logs both warning and error messages
error
: Logs only error messages (default)
debug
: Logs debug, error, warning, and informational messages
To specify a log level, enter the L
option. For example, to invoke AVCLI as user psmith
with the log level set to warning
:
avcli -l warning -u psmith AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. Enter password for 'psmith': password Connected to: Oracle Audit Vault Server 12.2.0.0.0 AVCLI>
To invoke AVCLI using a script and with the debug
warning level:
avcli -l debug -f myscript.av AVCLI : Release 12.2.0.0.0 - Production on timestamp Copyright (c) 1996, 2015 Oracle. All Rights Reserved. AVCLI> Connected. AVCLI> the script myscript.av executes
Note: You must be connected as a valid user who has been granted the AV_ADMIN
role. You can do so using the CONNECT
username
/
password
directive.
Topics
See one of the topics below if you need to change a Database Firewall's network, traffic sources, or services configuration:
You can view network traffic for debugging purposes. You can view live network traffic going through a firewall.
To view live network traffic in a Database Firewall:
Learn how to capture network traffic in Oracle Database Firewall.
You can capture traffic to a file (.pcap
file type) that you can download and analyze.
To capture network traffic to a file:
Use this procedure to restart or power off Oracle Database Firewall.
To restart or power off a Database Firewall:
You can remove Oracle Database Firewall from Oracle Audit Vault Server.
To remove Oracle Database Firewall from Oracle Audit Vault Server:
Learn how to obtain updated certificates from Oracle Database Firewall.
You can update the Database Firewall certificate stored in the Audit Vault Server using the Audit Vault Server console UI. You must update this certificate when you upgrade the Database Firewall to maintain communication between the firewall and the Audit Vault Server.
To update the Database Firewall certificate stored in the Audit Vault Server:
See Also:
Viewing the Status and Diagnostics Report for a Database Firewall for viewing Database Firewall diagnostics.
Learn how to reset Oracle Database Firewall.
This block contains information about the Oracle Database Firewall settings and the details of resetting a Firewall ID. The Reset ID button, in the Reset Database Firewall ID tab performs a reset of the Firewall ID. The Firewall ID is a unique identification number of the Firewall. It is derived from the Management Network Interface card. Once the reset is performed, it removes the existing enforcement points and creates new ones using the configuration information stored in Audit Vault Server. The enforcement points not listed on the Audit Vault Server are removed once the reset is performed. The captured data which is not processed is also deleted. The network setting of the Firewall is not altered. This action also resets the Firewall ID.
Note:
Whenever the Network Interface Card is replaced, the Firewall ID must be reset.
The network settings of the Firewall is not altered. Ensure the Firewall network is configured appropriately before attempting to reset Firewall ID.
The user must reset the Firewall ID in the following scenarios:
After replacing the Management Network Interface card on the Database Firewall.
After replacing an existing and configured Firewall with a newly installed Firewall.
When an Audit Vault Server is restored from backup, it is necessary to restore the status of the Enforcement Points registered on the Database Firewall.
See Also:
Resetting Oracle Database Firewall for more information.
Footnote Legend
Footnote 1:In this guide, 1 GB represents 2 to the 30th power bytes or in decimal notation 1,073,741,824 bytes.