Category Archives: Audit Vault

Release of Audit Vault and Database Firewall 12.1.2 Bundle Patch 2

End of last week, Oracle has released the second Bundle Patch for Audit Vault and Database Firewall 12.1.2. I’ve missed the release due to public holiday here in Switzerland. 🙂 The patch can be downloaded as usual on Oracle Metalink as Patchset 19190265 for existing installations or on Oracle eDelivery as full installation image for new installations. The installation image is split in two parts which need to be merged before use. A short description on how to merge the image can be found on my blog post about Audit Vault and Database Firewall 12.1.2.

According the readme, the Release 12.1.2 BP2 contains the July 2014 PSU 11.2.0.3.11 for the database as well several bug fix for the base platform. These include security and stability fixes to Java and the underlying Linux operating system. This is more or less similar to thelast bundle patch. What’s new, are the bug fix for the following bugs:

Bug Number Description
18724624 WITH EXCESSIVE VALUE FOR RMEM_MAX, TRAFFIC MONITORING IS SILENTLY DISABLED
18161187 INTEGRATE INTERFACE MASTERS NEW DRIVERS INTO THE PRODUCT
18940816 AVDF SERVER FAILS TO INSTALL ON HP DL380 GEN8 WITH CCISS!C0D0 ERROR
18823169 AFTER UPGRADE, THE DBFW CAN NOT COMMUCIATE WITH THE AVDF SERVER
18112713 ERRORS RELATING TO ILM AND DISK METRICS SEEN IN ALERT LOGS
18442791 NFS ARCHIVE JOB FAILS
18459675 SUPPORT FOR NVARCHAR DATA TYPE IN TABLE EZCOLLECTOR

In particular, I am interested in bug 18940816. I’ve discussed this issues in my post about AVDF installation fails on HP server with Smart Array Disk Controller. To verify if this issue is successfully fixed, I’ll have to reinstall one of the HP BL465c Blades.

References

Some links related to the Audit Vault and Database Firewall:

OAV-46599 when trying to add new secure target on AVDV 12.1.1.1

It is the second time that I run into this problem. Therefore, it is time to write a quick note before I struggle a third time. At some point adding a new secure targets no longer works and breaks with an OAV-46599.

OAV 46599

Initially I was a bit confused about the error. Because there haven’t been any changes on the system since the last secure target has been added. But reading the whole error message above gives the correct indication of the root cause. It’s nothing else than an ORA-28001 the password has expired. Lets see which user has an expired password.

SQL> ALTER SESSION SET nls_date_format='DD.MM.YYYY HH24:MI:SS';

SESSION altered.

SQL> SET linesize 160 pagesize 200
SQL> SELECT username,account_status,expiry_date FROM dba_users WHERE account_status='EXPIRED';

USERNAME                       ACCOUNT_STATUS                   EXPIRY_DATE
------------------------------ -------------------------------- -------------------
ANONYMOUS                      EXPIRED                          17.09.2011 10:21:08
AVREPORTUSER                   EXPIRED                          17.07.2013 21:25:55

It looks like the account AVREPORTUSER is expired. Because I do not know the password yet know whether it was stored somewhere, I’ll just reset the old password. For this I need both password hash’s.

SQL> col name FOR a15
SQL> col password FOR a17
SQL> col spare4 FOR a65
SQL> SELECT name,password,spare4 FROM USER$ WHERE name='AVREPORTUSER';

NAME            PASSWORD          SPARE4
--------------- ----------------- -----------------------------------------------------------------
AVREPORTUSER    F315BBCEBB3F78E7  S:14155D035FEBAB05790EAB47CCC4ACDBD8B728C373EECDABE6EB5FAA9D03

With alter user identified by values I’m able to specify both the 10g and the 11g password hash to reset the password to the same value.

 ALTER USER AVREPORTUSER IDENTIFIED BY VALUES 'S:14155D035FEBAB05790EAB47CCC4ACDBD8B728C373EECDABE6EB5FAA9D03;F315BBCEBB3F78E7';

As you can see in DBA_USERS the account has now status open again. Adding secure targets does work again.

SQL> SELECT username,account_status,expiry_date,password_versions FROM dba_users WHERE username='AVREPORTUSER';

USERNAME                       ACCOUNT_STATUS                   EXPIRY_DATE         PASSWORD
------------------------------ -------------------------------- ------------------- --------
AVREPORTUSER                   OPEN                             11.02.2014 06:39:02 10G 11G

But how has this account become expired? The reason is quite obviously. All AV user do have the Oracle DEFAULT profile which has a limited password life time of 180 days. Therefore, the accounts expire after 180 days. And yes my AVDF test system was set up about 180 days ago. 🙂

SQL> SELECT username,profile FROM dba_users WHERE username='AVREPORTUSER';

USERNAME                       PROFILE
------------------------------ ------------------------------
AVREPORTUSER                   DEFAULT

SQL> SELECT * FROM dba_profiles WHERE profile='DEFAULT' AND RESOURCE_NAME='PASSWORD_LIFE_TIME';

PROFILE                        RESOURCE_NAME                    RESOURCE LIMIT
------------------------------ -------------------------------- -------- ----------------------------------------
DEFAULT                        PASSWORD_LIFE_TIME               PASSWORD 180

An Oracle Bug has been opened for this issue. BUG 17078860 Relax The profile settings in the AV server’s database

Error installing Audit Vault Agent 12.1.1 on AIX

The Problem

During the setup of the current audit vault agent 12.1.1 on AIX, I’ve run into issues. Depending on the configuration of the AIX environment, the agent can not be installed at all.

avagent@host:/u00/app/avagent/ [avagent] java -jar agent.jar -d /u00/app/avagent/product/avagent
/u00/app/avagent/product/avagent/bin/agentctl[56]: LOGNAME: is read only
Error while executing command: [sh, /u00/app/avagent/product/avagent/bin/agentctl, fixperms]
avagent@host:/u00/app/avagent/ [avagent]

The problem is in the for loop on line 56 of agentctl where it tries to unset environment variables. Specifically, the environment variable LOGNAME can not be reset. On our AIX LOGNAME has been defined as read only in /etc/profile.

49
50
51
52
53
54
55
56
57
58
# Unset all env vars
#
for var in `$ENV | $SED 's#=.*##'`; do
  $ECHO $var | $EGREP "$passthru" > /dev/null

  # If no match, i.e. not a passthru then unset
  if [ $? -eq 1 ]; then
    unset $var
  fi
done

The Solutions

Change OS default profile

One solution would be to change the default profile on the OS. For this just open /etc/profile and comment out line 37. But I assume for most of us it is not an option to change the default profile.

32
33
34
35
36
37
# System wide profile.  All variables set here may be overridden by
# a user's personal .profile file in their $HOME directory.  However,
# all commands here will be executed at login regardless.

trap "" 1 2 3
#readonly LOGNAME

Change the audit agent

The alternate solution is to update the agent.jar and fix agentctl. Get the current agent.jar from the audit vault server and extract the agentclt script.

jar -xf agent.jar bin/agentctl

Update the agentctl and add LOGNAME the the list of pass through variable on line 46.

43
44
45
46
# Passthrough env vars
# Note: we passthru any vars with "-" invalid character
#
passthru='^TZ$|^LANG$|^LC_|^JAVA_HOME$|^PATH$|^PS1$|^LOGNAME$|-'

Put the updated agentctl script back to the agent.jar and run a regular installation.

jar -uf agent.jar bin/agentctl

The Bugfix

The problem was reported to Oracle and can be tracked using the bug number 17058352.

By the way if you’re using multiline shell prompts agentctl will fail on the same code on any OS. Here you may simple workaround by setting a single line prompt.

Use of DEFAULT_CLEANUP_INTERVAL

Following a question to the blog post Database Audit and Audit trail purging, I noticed something interesting about the DEFAULT_CLEANUP_INTERVAL parameter. On one hand, it is mandatory to initialize the audit trail and to define a DEFAULT_CLEANUP_INTERVAL, on the other hand, the parameter is not used at all. Oracle explains this in the MOS note Parameter DEFAULT_CLEANUP_INTERVAL of DBMS_AUDIT_MGMT.INIT_CLEANUP procedure [1243324.1]

Quote Oracle Support (MOS Note 1243324.1):

The dbms_audit_mgmt.init_cleanup parameter DEFAULT_CLEANUP_INTERVAL is not intended to be used to control the frequency of execution of audit management automatic cleanup. This parameter, although assigned a value during initialisation of audit infrastructure, is unused in current releases. However, in future releases it is intended to be used to control functionality which automatically partitions audit tables based on their archive frequency. This functionality already exists in the DBMS_AUDIT_MGMT package but is disabled in current releases. This is not a classified product bug, but expected behaviour.

According to the MOS Note DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL Not Clearing FGA Audit Trail When Using Last Archive Timestamp [1532676.1] it could be a no go for audit purging if DEFAULT_CLEANUP_INTERVAL has not or never been. Conclusion initialize the audit trail and define a value for the default cleanup interval but manualy setup a purge job.

I’m curious what Oracle plans for the future. Unified and self purging audit trail 🙂

Reference

A few Metalink Notes related to Audit and Audit Management.

  • Master Note For Oracle Database Auditing
  • Known Issues When Using: DBMS_AUDIT_MGMT
  • How to Truncate, Delete, or Purge Rows from the Audit Trail Table AUD$
  • DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL Not Clearing FGA Audit Trail When Using Last Archive Timestamp
  • Parameter DEFAULT_CLEANUP_INTERVAL of DBMS_AUDIT_MGMT.INIT_CLEANUP procedure

New Oracle Audit Vault and Database Firewall

In the hustle and bustle of the Christmas season, it went under that Oracle had released a new version of Oracle Audit Vault respectively Oracle Audit Vault and Database Firewall. This weekend I found some time to take a first look into the new release.

What’s New

About a year ago Oracle released the Audit Vault Server 10.3. (see New release of Oracle Audit Vault). During this update Oracle mainly moved internally to a 11.2.0.3 database. The architecture has remained more or less the same. But this has changed now. Oracle is trying to complete its security portfolio. Therefore Oracle has merged the two Oracle Audit Vault and Oracle Database Firewall into the new Oracle Audit Vault and Database Firewall. From the security officer point of view it is definitely more interesting to only have one platform. On the other hand a software appliance is one of the favorites of the DBA and Unix admins. What about, updates, HA, backup & recovery etc? I’ll try to consider these thoughts in a later post on installing and configuring the new Oracle Audit Vault and Database Firewall.

Some short notes on the new features:

  • Oracle Audit Vault and Database Firewall is released as a software appliance-based platform
  • Internally Oracle does use Oracle 11.2.0.3 including Advance Security and Database Vault to enforce Database security and segregation of duties
  • One simple setup does install and configure the operating system, software, database, web frontend etc
  • Audit Vault Agents for:
  • Oracle Database 10g
  • Oracle Database 11g
  • Microsoft SQL Server 2000
  • Microsoft SQL Server 2005
  • Microsoft SQL Server 2008
  • Sybase Adaptive Server Enterprise (ASE) versions 12.5.4 to 15.0.x
  • IBM DB2 version 9.x (Linux, UNIX, Microsoft Windows)
  • Solaris operating system
  • Oracle ACFS
  • Microsoft Windows Server 2008
  • Microsoft Windows Server 2008 R2
  • Microsoft Active Directory 2008
  • Microsoft Active Directory 2008 R2 on 64 bit

New Architecture

As initially mentioned Audit Vault and Database Firewall are moving closer. Oracle Audit Vault is now also the data storage and analysis platform for the Oracle Database Firewall. Former Database Firewall Management Server is eliminated and thus is replaced with Oracle Audit Vault.

OverviewAVDF

An important note here is that Oracle Audit Vault can not be installed on different platforms as before. It is rather a software appliance like the Oracle Database Firewall. The license for each Oracle Audit Vault and Oracle Database Firewall includes always a license for Oracle Enterprise Linux as well. To install only the appropriate hardware is required. This can be a virtual or a physical host. To setup my test environment, I’ve use as usual virtual servers.

Oracle AVDF Requirements

To install Oracle AVDF the following minimal Hardware Requirements must be met. See as the online installation guide for more details on the installation requirements in particular for the supported secured target products (agents).

  • x86 64-bit Server
  • 2 GB Ram
  • single hard drive 125 GB
  • 1 NIC for Audit Vault Server
  • 1 NIC for Database Firewall Proxy Mode
  • 2 NICs for Database Firewall DAM Mode (monitoring)
  • 3 NICs for Database Firewall DPE Mode (blocking)

In addition to the hardware the following software is required to begin the installation:

  • Oracle Linux Release 5 Update 8 for x86_64 (64 Bit) V31120-01 (3.7GB)
  • Oracle Audit Vault and Database Firewall (12.1.0.0.0) – Server V35715-01 (3.4GB)
  • Oracle Audit Vault and Database Firewall (12.1.0.0.0) – Database Firewall V35716-01 (3.1GB)

The server can not be used for other activities, setup of either Oracle Audit Vault or Oracle Database Firewall will completely reimage the server. But I’ll post more details on the installation later this month.

Resources

Links all around the new Oracle Audit Vault and Database Firewall…