Sunday, 12 October 2014

Invalid record in Event name in Audit vault

Issue: If we set audit_trail=DB,extended then audit vault report is showing correct data in Event Name. But if we change it to XML,extended then somtimes it shows Invalid record in Event name in Audit vault.Attached audit vault report for your reference.
Also,there is some time lag while getting the data into the audit vault report.


SQL> select command_class, event_name, length(command_text) from avsys.event_log where event_name like '%INVALID%';

COMMAND_CLASS EVENT_NAME LENGTH(COMMAND_TEXT)
-------------------------------------------------- -------------------------------------------------- --------------------
UNKNOWN EVENT INVALID RECORD 1311
UNKNOWN EVENT INVALID RECORD 1311
UNKNOWN EVENT INVALID RECORD 1311
UNKNOWN EVENT INVALID RECORD 1311
UNKNOWN EVENT INVALID RECORD 176
UNKNOWN EVENT INVALID RECORD 51
UNKNOWN EVENT INVALID RECORD 112
UNKNOWN EVENT INVALID RECORD 249
UNKNOWN EVENT INVALID RECORD
UNKNOWN EVENT INVALID RECORD
UNKNOWN EVENT INVALID RECORD
UNKNOWN EVENT INVALID RECORD
UNKNOWN EVENT INVALID RECORD
UNKNOWN EVENT INVALID RECORD
UNKNOWN EVENT INVALID RECORD 171
UNKNOWN EVENT INVALID RECORD 171


Impact of changing the DB to XML:
1) Parsing XML files is slower than reading data from a table like AUD$. There is no surprise that the data is not collected very fast when the audit_trail parameter was set to XML,EXTENDED.

2) Using XML rather than DB is riskier. There were many bugs in the past because of which the XML tags were not set correctly and as such the parsers had issues. Furthermore , parsing an XML file is much slower than reading a row of the AUD$ table.


This issue is caused by bug 17048003. The developers are trying to solve this in 12.1.3. As an workaround we can set the audit_trail parameter to DB,EXTENDED and have table trail collecting the data from the AUD$ table.

Tuesday, 12 August 2014

Oracle Audit Vault and Database Firewall 12.1.2 New Features

Couple of months back,Oracle has released a new feature of AVDF which is 12.1.2. One of the main feature is that you can configure external iSCSI SAN server to store the audit data.

According to the Release Notes, the following features are available as of 12.1.2:
  • Configure the Audit Vault Server to use an external iSCSI SAN server to store the audit event repository and system data
  • The Audit Vault Agent is updated automatically when the Audit Vault Server is upgraded or a patch is applied
  • Store archive data in a Network File Share (NFS) location
  • Entitlement reports include data specific to Oracle Database 12c
  • Database Vault is automatically enabled and configured in the Oracle Database embedded in the Audit Vault Server. This further strengthens security by restricting privileged access to the Oracle Database for all users including those with administrative access
  • Password hashing has been upgraded to a more secure standard. Change your passwords after upgrade to take advantage of the more secure hash
  • The Audit Vault Agent deployment procedure has been simplified. Registering a host in the Audit Vault Server automatically generates an Agent activation key, and therefore, the step requesting Agent activation is no longer required
  • Adding and updating a secured target location has been simplified in the Audit Vault Server administrator console UI
  • Define policy alerts to be forwarded to syslog
  • Download diagnostics log files from the Audit Vault Server UI
  • The Audit Vault Agent is supported on 32-bit Linux and Windows platforms
  • Oracle Database 9i is supported for Database Firewall
  • MySQL 5.6 is supported on the Database Firewall
  • Migration Path to Migrate Oracle Audit Vault 10.3 to AVDF 12.1.2. See MOS Note1666742.1

Friday, 13 June 2014

VKTM detected a time drift. Please check trace file for more details.

Issue: Frequent warning message in alert log
VKTM detected a time drift. Please check trace file for more details.

Error in trace file->
ksesethighpri: (ksb.c:4178) Failed to elevate VKTM's priority from 0 to 1
Error Info: Category(-2), Opname(skgdism_create), Loc(sp.c:1553), ErrMsg(Error 0) Dism(-1038804382)
*** SESSION ID:(1.1) 2014-06-10 20:15:51.823
*** SERVICE NAME:() 2014-06-10 20:15:51.823

kstmmainvktm: failed in setting elevated priority
Verify: SETUID is set on ORADISM and restart the instance
highres_enabled
VKTM running at (100ms) precision
kstmrmtickcntkeeper: param _dbrm_quantum will not be effective

*** 2014-06-10 20:15:51.823
[Start] HighResTick = 1402445751823794
kstmrmtickcnt = 0, ksudbrmseccnt[0] = 1402445751
kstmchkdrift (kstmrmtickcntkeeper:lowres): Time jumped forward by (8000000)usec at (1402445759) whereas (5000000) is allowed


Cause:
OSDBA has the wrong permissions on /etc/privgroup.


Solution:
1.Log in as the root user.
2.Using any text editor, open the /etc/privgroup file, or create it if
necessary.
3.Add or edit the following line, which begins with the name of the OSDBA
group, specifying the privileges RTPRIO and RTSCHED that you want to grant to
this group every time the system restarts (here dba is the OSDBA group):
dba RTPRIO RTSCHED
4.Save the file, and quit the text editor.
5.Enter the following command to grant the privileges to the OSDBA group:
# /usr/sbin/setprivgrp -f /etc/privgroup
6.Enter the following command to verify that the privileges are set
correctly:
# /usr/sbin/getprivgrp dba