This documentation does not apply to the most recent version of Splunk.
This documentation applies to the following versions of Splunk: 3.1.2 , 3.1.3 , 3.1.4
Audit events are generated for every interaction with Splunk. When auditing is enabled, searches, configuration changes, and file system modifications all get logged into Splunk's audit index. This page outlines the composition and generation of audit events.
11-01-2007 09:23:59.581 INFO AuditLogger - Audit:[timestamp=Thu Nov 1 09:23:59 2007, id=1, user=admin, action=splunkStarting, info=n/a][NSsJkuZZNn1dKaH3tjgxN/RbGeKaQ/dXArIdK2M97E0Ckv6xqMurYbUVqC6YoICLjW/H113u6FDTPMBGdk29J95X1SecazMf+H1tRqfc+vcJPZH1RcQaiVCcJwRTJuXD4Z5JidyvjVIECIdrhPSAGj7CSEhTdYx4tOEfl5yMckU=]
The information within the first set of brackets ([ ]) is the data which is hashed and signed. The string in the second set of brackets is the hash signature.
Audit events are generated from monitoring:
$SPLUNK_HOME/etc/*
In a single stand-alone instance of Splunk, audit events are stored locally in a special audit index (index=audit), and are logged in the log file: $SPLUNK_HOME/var/log/splunk/audit.log.
When Splunk is configured as a forwarder, audit events are forwarded like any other event. Signing can happen on the forwarder, or on the receiving Splunk instance.
The file Documentation:preview:Auditconf:latest tells the audit processor whether or not to encrypt audit events. As audit events are generated, Splunk's auditing processor assigns a sequence number to the event and stores the event information in an SQLite database. If there is no user information specified when the event is generated, the currently signed user information is used for that event. At this point, if audit event signing is set, the audit event is hashed and encrypted.