14 Managing the Audit Vault Server and Database Firewalls

This section describes managing day-to-day Audit Vault Server and Database Firewall operations once the initial configuration is completed.

Topics

14.1 Managing Audit Vault Server Settings, Status, and Maintenance Operations

Topics

14.1.1 Checking Server Status and System Operation

To check the Audit Vault Server status:

  1. Log in to the Audit Vault Server as an Administrator.
  2. Click the Settings tab.
  3. In the System menu, click Status.

    The status page displays the following:

    • Uptime and free space

    • High availability status (whether the server is standalone or paired)

    • Software and component versions

    • Server connect string

    • Status for Database Firewall log collector process and background worker process

14.1.2 Running Diagnostics Checks for the Audit Vault Server

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:

  1. Log in to the Audit Vault Server console as a super Administrator.
  2. Click the Settings tab, and in the System menu, click Diagnostics.
  3. In the Diagnostics page, click the Run Diagnostics button to perform a series of diagnostic checks.

    These diagnostics include testing the existence of the following:

    • Existence and access permissions of configuration files

    • File system sanity

    • Network configuration

    • Status of various process that are required to run on the system, for example, database server process(es), event collection process, Java framework process, HTTP server process, etc.

    After the system completes the diagnostic tests, it displays a report listing the results of each test.

  4. Click the Back button to return to the Diagnostics page.

See Also:

14.1.3 Downloading Detailed Diagnostics Reports for the Audit Vault Server

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:

  1. Log in to the Audit Vault Server console as a super Administrator.
  2. Click the Settings tab, and in the System menu, click Diagnostics.
  3. Click the Download Diagnostics button.

    A download window appears for the diagnostics zip file.

  4. Select a file location and then click Save.

    A diagnostics log file (.zip) is downloaded to the location that you select. Be aware that the diagnostics zip file may contain sensitive data from your appliance. Take appropriate precautions when you transfer and store this file.

  5. If you are trying to diagnose problems and had set the LOGLEVEL to DEBUG, consider setting it back to ERROR or the original setting (such as INFO). Otherwise, in subsequent diagnostic tests, many log or trace files are generated.

    See Also:

14.1.4 Accessing the Audit Vault Server Certificate and Public Key

Topics

14.1.4.1 Accessing the Server Certificate

If you have deployed Database Firewalls, you must provide the Audit Vault Server certificate and IP address to each Database Firewall.

To access the server certificate:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. In the Security menu, click Certificate. The server's certificate is displayed. You can copy the certificate and provide it to each Database Firewall.

14.1.4.2 Accessing the Server Public Key

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:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. In the Archiving menu, click Manage Archive Locations, and then click Create. The Public Key field contains the public key. You can copy the key and paste it into the appropriate file on another system.

14.1.5 Changing Logging Levels and Clearing Diagnostic Logs

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:

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

  2. Click the Settings tab, and then under the System menu, click Diagnostics.

  3. For any of the components listed, select a logging level from the drop-down list.

  4. Click Save.

Clearing Diagnostic Logs

To clear diagnostic logs from the Audit Vault Server:

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

  2. Click the Settings tab, and then under the System menu, click Log Management.

  3. Click Clear Diagnostic Logs, then click OK to confirm.

    A confirmation message is displayed when logs have been cleared.

See Also:

Logging in to the Audit Vault Server Console UI

14.1.6 Changing the Keyboard Layout

To change the keyboard layout used in the Audit Vault Server:

  1. Log in to the Audit Vault Server console as a super Administrator.
  2. Click the Settings tab, and in the System menu, click Manage.
  3. From the Keyboard drop-down list, select the keyboard you want.
  4. Click Save.

14.1.7 Rebooting or Powering Off the Audit Vault Server

To reboot or power off the Audit Vault Server:

  1. Log in to the Audit Vault Server as super Administrator.
  2. Click the Settings tab, and in the System menu, click Manage.
  3. Click Reboot or Power Off.

14.2 Changing the Audit Vault Server's Network or Services Configuration

To set or change the network or services configuration, follow the relevant procedure below:

14.3 Managing Server Connectors for Email, Syslog, and Arcsight SIEM

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.

14.4 Archiving and Retrieving Audit Data

Topics

14.4.1 Starting an Archive Job

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:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Settings tab, and from the Archiving menu, click Archive.
  3. Complete the following fields:

    • Job Name: Enter a name for the archive job.

    • Archive Location: Select the archive location.

  4. Select the files you want to archive.

    The files listed are those for which the Months Online period has expired according to the secured target's retention policy.

  5. Click the Archive button.

Note:

14.4.2 Retrieving Oracle Audit Vault and Database Firewall Audit Data

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:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Settings tab, and from the Archiving menu, click Retrieve.
  3. In the Job Name field, enter a name for this retrieve job.
  4. Select the Secured Target whose data you want to retrieve, and a Start Date and End Date for the data to be retrieved.

    The start and end dates are associated with the event time (the time the event occurred).

  5. Click the Retrieve button.

    You can check the status of the retrieve job in the Jobs page (from the System menu in the Settings tab). When the retrieved data files are available, they are listed in the retrieved data files section of the Retrieve From Archive page, and the data will be visible in reports.

  6. To purge retrieved files when no longer needed, from the retrieved data files section of the page, select the files you want to unload from the system, and then click the Release button. Once the release is successful, the data is not visible in reports.
  7. After the retrieved data files are released, they are now eligible to be archived again. If they are not needed anytime soon, then they should be archived to release disk space to the system.

14.5 Managing Repository Encryption

Topics

14.5.1 About Oracle Audit Vault Server Repository Encryption

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.

14.5.2 Rotating the Master Key for Repository Encryption

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.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab, and then in the Storage menu, click Repository Encryption.
  3. In the Rotate Master Key section, enter the Keystore Password.

    This password is originally set as a required post-installation step.

  4. Click Re-key. A success message is displayed when the re-key is complete.

14.5.3 Changing the Keystore Password

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:

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab, and then in the Storage menu, click Repository Encryption.
  3. In the Change Keystore Password section, enter the old Password, and then enter the New Password twice.
  4. Click Change Password.

    See Also:

14.5.4 Backing Up the TDE Wallet

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.

14.5.5 Data Encryption on Upgraded Instances

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:

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

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

  1. Log in to the system as root user.
  2. Execute the following command to start encryption:
    /usr/local/dbfw/bin/avdf_data_encryption.sh start
  3. The following message is displayed on the screen: 
    **************************************************************
* This script will encrypt all online tablespaces and create *
* a background job to encrypt offline tablespaces.           *
* Encrypting online tablespaces could potentially take long  *
* time depending on the size of the online data collected.   *
* Note that during this time                                 *
*   - There will be no access to Web UI console.             *
*   - Event collection will be shutdown.                     *
*   - AV agents will not be able to connect.                 *
*   - AVCLI will not be able to connect.                     *
*                                                            *
*  NOTE: It is recommended to take backup before continuing. *
**************************************************************
Do you want to continue (Y/N):
  4. Type Y to continue with encryption.
  5. The following message is displayed: 
    ************************************************************
* Do not interrupt this script execution or reboot.        *
* To stop the script execution use                         *
* 'avdf_data_encryption stop' command.                     *
* Check /root/avdf_data_encryption.log to track progress   *
************************************************************

    Note:

    At this point, it is recommended to move the process to background by executing Ctrl+z followed by bg. Alternately to keep the session alive, the user can execute the command ssh -o ServerAliveInterval 20

    The following messages are displayed on the screen:

    Successfully encrypted online table spaces. 
System is ready for use.
Offline table space encryption can be managed on the AVS GUI.

    Note:

    Contact My Oracle Support with the printed output in the event of a failure.

  6. The following message is displayed in the /var/log/avdf_data_encryption.log file: 
    Encrypting <tbsp name> Tablespace : % done
  7. Once the encryption process is successfully completed, another job to encrypt offline table spaces is created and enabled in the background. All the services appear online and the following message is displayed:
    System is ready for use
  8. In case the encryption process fails, the /var/log/avdf_data_encryption.log file displays the following error message.
    Failed to encrypt table spaces: Please contact Oracle Support
  9. Execute the following command to stop encryption:
    /usr/local/dbfw/bin/avdf_data_encryption.sh stop

    Note:

    Ensure to execute the stop command only after you see the following message in the /var/log/avdf_data_encryption.log:

    You may issue stop command to gracefully stop the encrypting process

    Note:

    Once the stop encryption command is executed, the encryption process exits only after encrypting the current table space that is being encrypted. It is always recommended to run the script again to complete the encryption process.

  10. In case the user decides to perform a reboot of the system during the encryption process, it stops at the current table space that encryption last accessed. The user can decide to run the script again to complete the encryption process.
  11. In case the dbfwdb service terminates unexpectedly, contact Oracle Support. The encryption script will not run if this service is down.
  12. The encryption process collects all the logs to /var/log/avdf_data_encryption.log file securely.
  13. After all online table spaces are encrypted, a background job ENCRYPT_OFFLINE_TBSP is enabled to perform encryption of offline table spaces. This job encrypts all table spaces for those data files that reside locally on the system. In case the data file is located on the remote location nfs/scp/smb, the data file is copied to the local system, encrypted, and setup for re archival. The user must manually perform the re archival process to ensure that the data file in the remote location scp/smb is encrypted. The user can navigate to Settings and Repository Encryption page to view a list of offline table spaces that are not encrypted. If the data file is not available, the message displayed indicates the same.
  14. The process of encrypting offline table spaces can be in one of the following states.
    Message Description

    NOT YET STARTED

    The user has not executed the script to encrypt table spaces.

    COMPLETED

    All online and offline table spaces are encrypted. Any new table spaces created will also be encrypted. This is the final state.

    IN PROGRESS

    The background job is currently encrypting offline table spaces.

    USER

    The background job is waiting for user input. User must visit the Repository Encryption page and take appropriate action.

    ERROR

    There was an error in encrypting one or more table spaces. The user must download the diagnostics and provide that to Oracle Support.

    TRAIL

    The table space has been retrieved by a trail as it is collecting old data. Wait for the trail to release the table space.
  15. In the ERROR state the background job is disabled and hence the user, after fixing the cause of the error must re-enable the job from the Repository Encryption page.
  16. In the event of system reboot, power failure, switch over, or fail over the user can execute the encryption process again.

14.6 Backing Up and Restoring the Audit Vault Server

Topics

14.6.1 About the Backup and Restore Utility

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:

14.6.2 How Much Space Do I Need for Backup Files?

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.

14.6.3 Backing Up the Audit Vault Server

Topics

14.6.3.1 Step 1: Configure the Backup Utility

To configure the backup utility:

  1. If you are using a high availability configuration and want to perform a cold backup, then do the following:

    1. Log in to the Audit Vault Server console.

    2. Select Settings.

    3. Under System, select High Availability.

    4. Select the Disable Failover button.

    5. In the Confirmation dialog, click OK.

  2. Log in to the Audit Vault Server as root.

  3. 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 set CHANNEL_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

14.6.3.2 Step 2: Back Up the Audit Vault Server

This step backs up the Audit Vault Server database and configuration.

  1. If applicable, ensure you have the backup file encryption password and/or event repository encryption (keystore) password.
  2. Log in to the Audit Vault Server as root.
  3. Run the following command and input information at the prompts: 
    /var/lib/oracle/dbfw/bin/avbackup backup

    When the backup is complete, you should see a number of files in your backup directory, similar to the following:

    DBID_1440353975_09Q7EF7L_1_1
DBID_1440353975_C-1440353975-20150520-00

    Note:

    Oracle recommends the user to reboot the system in case there is a failure while performing a cold backup operation.

14.6.3.3 Step 3: Validate the Backup

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.

  1. Log in to the Audit Vault Server as root.
  2. Run the following command: 
    /var/lib/oracle/dbfw/bin/avbackup validate

    The backup status is displayed, similar to the following:

    Backup Restore exit status: 0

    Status 0 = Success. Status 1 = Failure.

  3. Check these log files for errors: 
    /TMP_DIR/av_backup_timestamp
/var/lib/oracle/dbfw/av/log/av.backup_restore-pid-0.log
/var/lib/oracle/dbfw/av/log/av.backup_restore_error-pid-0.log

    If you need help diagnosing errors, contact Oracle Support.

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 /var/lib/oracle/dbfw/av/backup/.backup_restore_config to /var/lib/oracle/dbfw/av/backup/.full_backup_restore_config

To run the avbackup configuration once for the full incremental backup.

Move /var/lib/oracle/dbfw/av/backup/.backup_restore_config to /var/lib/oracle/dbfw/av/backup/.incr_backup_restore_config

To setup one cron job for full backup.

Copy full_backup_restore_config to backup_restore_config. Run the command avbackup backup.

To setup one cron job for incremental backup.

Copy incr_backup_restore_config to backup_restore_config. Run the command avbackup backup.

14.6.4 Restoring the Audit Vault Server

Topics

14.6.4.1 About Restoring the Audit Vault Server

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.

14.6.4.2 Prerequisites for Restoring Audit Vault Server

Examine the prerequisites for restoring Audit Vault Server.

Before restoring backup files to a new Audit Vault Server:

  • Shut down and remove the earlier Audit Vault Server from the subnet on which it resides. This task enables the new Audit Vault Server to be restored on the same subnet as the previous server.
  • Perform full installation of the same release version of Oracle AVDF, including the post-installation tasks, on the system to which you are restoring. See Oracle Audit Vault and Database Firewall Installation Guide for instructions.
  • Ensure that the new Audit Vault Server is on the same subnet as the Audit Vault Server from which you took the backups.
  • Ensure that the new Audit Vault Server has a different IP address than the Audit Vault Server from which you took the backups.

Note:

  • After you complete the restore process, the IP address of the new Audit Vault Server is automatically changed to the IP address of the old system. If you want to restore the system with the IP address of the old system (prior to backup), ensure the new Audit Vault Server is on the same subnet as the Audit Vault Server from which you took the backup. Set the 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.
  • If you plan to restore the system to a new IP, not to the original backed up system IP, make sure you set 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.

14.6.4.3 Step 1: Configure the Backup Utility on the Audit Vault Server

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.

14.6.4.4 Step 2: Restore Audit Vault Server

Learn how to restore Audit Vault Server.

To restore the Audit Vault Server:

  1. Copy the backup files to your new Audit Vault Server, placing the files in the BACKUP_DIR directory that you specified in "Step 1: Configure the Backup Utility on the Audit Vault Server".

    Make sure the backup files are owned by oracle:oinstall.

  2. Log in to Audit Vault Server as root.
  3. In case the backup files are in NFS, then ensure the NFS location is mounted on the system used for restore. The backup directory must be accessible through the mount point. Run the following command to manually mount the NFS location prior to performing the restore operation: 
    /bin/mount -t nfs <NFS server IP>:<NFS export> <mount point of Audit Vault Server>
  4. Run the following command: 
    /var/lib/oracle/dbfw/bin/avbackup restore
  5. If you have TDE enabled, then when prompted, then enter the keystore password, using the same value for the keystore password for the original system.

    For example:

    Enter keystore password:

    If TDE is not enabled, then this step is bypassed.

  6. When restore is complete, check the following log files for errors: 
    /TMP_DIR/av_backup_timestamp
/var/lib/oracle/dbfw/av/log/av.backup_restore-pid-0.log
/var/lib/oracle/dbfw/av/log/av.backup_restore_error-pid-0.log

    Common errors and their solutions are as follows:

    • No access to BACKUP_DIR: Ensure that the BACKUP_DIR directory is owned by oracle:oinstall.

    • Disk full: Ensure that the BACKUP_DIR disk has enough room for the backup files.

    • Incorrect password: Re-run the avbackup config command to set the password correctly.

    • In addition, a common error is not running the script as root.

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

14.6.5 Restoring a Backup to a New System with a New or Different IP Address

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:

  1. Log in to the Audit Vault Server as root user.
  2. Restore the backup on a new Audit Vault Server with a new IP address.
  3. Update the IP addresses in the av/conf/bootstrap.prop files of the Agent deployments. Replace all the old IP address with the new IP address in bootstrap.prop file.
  4. Restart the Agent. It downloads the new agent.jar from the Audit Vault Server with the new IP address.

    Note:

    Execute this operation on all Audit Vault Agents and restart them.

  5. Log in to the Database Firewall console as admin user.
  6. Click Database Firewall tab.
  7. In the System menu, click Audit Vault Server.
  8. In the Audit Vault Server 1 IP Address field, enter the new IP address of the Audit Vault Server.

    Result:

    This ensures that new communication between Audit Vault Server and Database Firewall is established.

    Note:

    If this communication is not established, then Oracle Audit Vault Server cannot access Oracle Database Firewall. It may result in a common access issue error or an incomplete restore operation.

  9. Update the IP address on all instances of Database Firewall.

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.

14.7 Enabling Oracle Database In-Memory for the Audit Vault Server

Topics

14.7.1 About Enabling Oracle Database In-Memory for the Audit Vault Server

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.

14.7.2 Enabling and Allocating Memory for Oracle Database In-Memory

To enable and allocate memory for Oracle Database In-Memory:

  1. Log in to the Audit Vault Server console as a super administrator.
  2. In the home page, click Oracle Database In-Memory.

    Alternatively, click the Settings tab, and then click Oracle Database In-Memory under the System menu.

  3. If there is sufficient memory, click the check box Enable Oracle Database In-Memory.

    The system displays the total available RAM and the maximum available for in-memory.

  4. In the Oracle Database In-Memory page, select from the following options to send data to Oracle Database In-Memory:

    • Date Range: Enables the memory to be available for a specific period of time.

    • Keep Latest Data: Retains the data that has just been collected and enables the system to automatically select the most recent dates, based on the in-memory size that was configured.

  5. In the Allocated for in-memory field, enter (or change) the amount of RAM to allocate in gigabytes.

    You must enter a minimum of 1 (default), and up to Maximum available for Database In-Memory indicated on this page.

  6. Click Save.

    After enabling or disabling Oracle Database In-Memory, the Audit Vault Server database, Audit Vault Agents, and audit trails go down for a few minutes, and then restart automatically.

    See Also:

    Logging in to the Audit Vault Server Console UI

14.7.3 Setting the Oracle Database In-Memory Options

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.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. In the home page, click Oracle Database In-Memory.

    Alternatively, click the Settings tab, and then click Oracle Database In-Memory under the System menu.

  3. In the Oracle Database In-Memory page, select from the following options to send data to Oracle Database In-Memory:

    • Date Range: Enables the memory to be available for a specific period of time.

    • Keep Latest Data: Retains the data that has just been collected and enables the system to automatically select the most recent dates, based on the in-memory size that was configured.

  4. Click Save.

14.7.4 Disabling Oracle Database In-Memory

To disable Oracle Database In-Memory:

  1. Log in to the Audit Vault Server console as a super administrator.
  2. In the home page, click Oracle Database In-Memory.

    Alternatively, click the Settings tab, and then click Oracle Database In-Memory under the System menu.

  3. Click the Enable Oracle Database In-Memory check box to clear it.
  4. Click Save.

    After enabling or disabling Oracle Database In-Memory, the Audit Vault Server database, Audit Vault Agents, and audit trails go down for a few minutes, and then restart automatically.

    See Also:

    Logging in to the Audit Vault Server Console UI

14.7.5 Monitoring Oracle Database In-Memory Usage

To see in-memory usage in the Audit Vault Server dashboard:

  1. Log in to the Audit Vault Server console as an administrator.
  2. In the home page, click Oracle Database In-Memory.

    Alternatively, click the Settings tab, and then click Oracle Database In-Memory under the System menu.

  3. Note the data next to Database In-Memory utilization.

14.8 Managing Plug-ins

You can deploy additional plug-ins to support more types of secured targets, or un-deploy plug-ins that are no longer needed.

See Also:

Deploying Plug-ins and Registering Plug-in Hosts

14.9 Monitoring Server Tablespace Space Usage

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:

14.10 Monitoring Server Archive Log Disk Space Use

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:

14.11 Monitoring Server Flash Recovery Area

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.

See Also:

14.12 Monitoring Jobs

You can see the status of various jobs that run on the Audit Vault Server, such as report generation, and user entitlement or audit policy retrieval from secured targets.

To see the status of jobs on the Audit Vault Server:

  1. Log in to the Audit Vault Server as an Administrator.
  2. Click the Settings tab.
  3. In the System menu, click Jobs.

    A list of jobs is displayed, showing the job type, ID, timestamp, status, and associated user name.

  4. To see details for an individual job, click the icon to the left of that job.

14.13 Scheduling Maintenance Job

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:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click Settings tab, and then Manage.
  3. To schedule a new maintenance job, select Start Time. Enter the time in hours and minutes for the maintenance job to start at a specific time. The time specified here is the time on the browser.
  4. In the Time Out (In hours) field, enter the duration of the maintenance job in hours.

    Note:

    In case the job does not complete within the duration specified, it is timed out.

  5. In the Repeat Frequency field, select the frequency of the maintenance job to be repeated.

    Note:

    This field cannot be edited, and by default the value remains Daily. The job runs at the specified start time daily.

    See Also:

    Monitoring Jobs in the Oracle Audit Vault and Database Firewall Administrator's Guide to check the status of the job scheduled.

14.14 Downloading and Using the AVCLI Command Line Interface

Topics

14.14.1 About the AVCLI Command Line Interface

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.

14.14.2 Downloading the AVCLI Command Line Utility and Setting JAVA_HOME

The AVCLI utility is already installed on the Audit Vault Server. If you want to run AVCLI on a different computer, then you must download it from the Audit Vault Server console and install it on the other computer.

To download the AVCLI command line utility:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab, and in the System menu, click Manage.
  3. Click the Download Command Line Utility button, and save the avcli.jar file.
  4. Copy the avcli.jar file to the computer from which you want to run AVCLI, and then run this command:

    java -jar avcli.jar

    The AVCLI utility is installed in the current directory with the necessary permissions. To install in a different directory, use the command:

    java -jar avcli.jar -d directory_name

  5. Set the JAVA_HOME environment variable to point to the JDK installation directory. On Windows, add %JAVA_HOME%\bin to the PATH environment variable.

14.14.3 Starting AVCLI

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

Note:

Set the JAVA_HOME environment variable to point to JDK installation directory.

14.14.3.1 Starting AVCLI Interactively

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.

14.14.3.2 Starting AVCLI Using Stored Credentials

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:

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

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

Running AVCLI Scripts

14.14.4 Running AVCLI Scripts

You can run AVCLI scripts without user intervention or putting credentials inside the script.

An AVCLI script contains a series of AVCLI commands. You can run an AVCLI script from the shell. Valid AVCLI script names have a .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;
  1. Log in to the server where AVCLI is installed as a user who has been granted the AV_ADMIN role.
  2. Use the following syntax to run the script: 
    avcli -u username -f scriptname.av

    For example:

    avcli -u psmith -f myscript.av
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> the script myscript.av executes

    If you have stored administrator credentials, to run an AVCLI script, use the appropriate command below:

    • avcli /@ -f sample_script1.av

      This command uses the stored credentials, connects to the Audit Vault Server, and runs the script.

    • avcli -f sample_script2.av

      You can use the above command if you include the following command at the beginning of your script:

      connect /@

      Then the script runs using the stored credentials, and connecting to the Audit Vault Server.

14.14.5 Specifying Log Levels for AVCLI

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.

14.14.6 Displaying Help and the Version Number of AVCLI

To display the AVCLI help information and version number:

avcli -h

If you only want to find the version number, then use the V argument:

avcli -v

14.15 Downloading the Oracle Audit Vault and Database Firewall SDK

An SDK is available for developing custom Oracle Audit Vault and Database Firewall plug-ins.

To download the SDK:

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab, and then click Plug-ins (under the System subsection).
  3. Click Download SDK.

14.16 Managing Database Firewalls

Topics

14.16.1 Changing the Database Firewall's Network or Services Configuration

See one of the topics below if you need to change a Database Firewall's network, traffic sources, or services configuration:

14.16.2 Viewing Network Traffic in a Database Firewall

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:

  1. Log in to the Database Firewall administration console.
  2. Under Network Traffic, select Live Capture.
  3. In the Level of Detail region, select Summary or Packet Content.
  4. In the Duration field, select the number of seconds to capture live traffic.
  5. In the Network field, select the network traffic source for which to capture traffic.
  6. Click the Show Traffic button. In the Network traffic (first 1000 packets) region, the live traffic is displayed for the selected duration.

14.16.3 Capturing Network Traffic in Oracle 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:

  1. Log in to the Database Firewall administration console.
  2. Under Network Traffic, select File Capture.
  3. In the Duration field, select the number of seconds to capture traffic.
  4. In the Network field, select the network traffic source for which to capture traffic.
  5. Click the Capture button.

    The traffic file (.pcap format) is displayed in the Network Traffic Files list.

  6. Click Download for the network traffic file you want to download.

14.16.4 Restarting or Powering Off Oracle Database Firewall

Use this procedure to restart or power off Oracle Database Firewall.

To restart or power off a Database Firewall:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Database Firewalls tab, and then select the firewall(s) you want to reboot or power off.
  3. Click the Reboot or Power Off button.

14.16.5 Removing Oracle Database Firewall from Oracle Audit Vault Server

You can remove Oracle Database Firewall from Oracle Audit Vault Server.

To remove Oracle Database Firewall from Oracle Audit Vault Server:

  1. Log in to the Audit Vault Server as an administrator.
  2. Click the Database Firewalls tab, and then select the firewall(s) you want to remove.
  3. Click the Delete button.

14.16.6 Fetching an Updated Certificate from Oracle Database Firewall

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:

  1. After upgrading the Database Firewall, log in to the Audit Vault Server console as an administrator.
  2. Click the Database Firewalls tab.
  3. Click the name of a firewall with the status Certificate Validation Failed.
  4. In the Modify Firewall page, click Update Certificate.

14.16.7 Viewing Diagnostics for Oracle Database Firewall

See Also:

Viewing the Status and Diagnostics Report for a Database Firewall for viewing Database Firewall diagnostics.

14.16.8 Resetting Oracle Database Firewall

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:

  1. After replacing the Management Network Interface card on the Database Firewall.

  2. After replacing an existing and configured Firewall with a newly installed Firewall.

14.16.9 Restore Enforcement Points

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.