Audit Splunk activity
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
Audit Splunk activity
With auditing enabled, Splunk logs distinct events to the audit index (
index=_audit). Every interaction with Splunk -- search, configuration changes, etc -- generates an audit event. Directories monitored by file change monitoring create audit events as well. This topic outlines the composition and generation of audit events.
Note: The punct field is not available for events in the _audit index.
What's in an audit event?
- date and time of the event.
- User information:
- the user who generated the event.
- If the event contains no user information, Splunk sets the user to whoever is currently logged in.
- Additional information:
- available event details -- what file, success/denial, etc.
- ID (only if audit event signing is turned on):
- a sequential number assigned to the event for detecting gaps in data.
- Hash signature:
- PKI encrypted SHA256 hash signature, including the timestamp and ID.
- Additional attribute/value pairs specific to the type of event.
The following is a sample signed audit log entry:
06-20-2012 17:22:33.452 -0700 INFO AuditLogger - Audit:[timestamp=06-20-2012 17:22:33.451, id=2, user=admin, action=login attempt, info=succeeded] [GE8BVo5kj0UL8p/0VKN710JiQjIQUwBDXGpCote295NLCK8w7EsR5sCJMk0Ysge wIGI1Ejq3ejcDXoFahNSD4VAQsHqmfnRLnpkx1VdtDp4hGgKaUYC6Y5QGs6+zUdr cxnHTJ44jjLBBLcDEBbqz19owArHdDJ+MrVHeCgfyN6E=]
The information within the first set of brackets ([ ]) is the hashed and signed data. The string in the second set of brackets is the hash signature.
What activity generates an audit event?
Audit events are generated from monitoring:
- all files in Splunk's configuration directory
- files are monitored for add/change/delete using the file system change monitor.
- system start and stop.
- users logging in and out.
- adding / removing a new user.
- changing a user's information (password, role, etc).
- execution of any capability in the system.
- capabilities are listed in authorize.conf
Audit event storage
Splunk stores audit events locally in the audit index (
index=_audit). Audit events are logged in the log file:
If you have configured Splunk as a forwarder in a distributed setting, audit events are forwarded like any other event. Signing can happen on the forwarder, or on the receiving Splunk instance.
Audit event processing
The file audit.conf 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 a SQLite database. If there is no user information specified when the event is generated, Splunk uses the currently signed in user information. Finally, if audit event signing is set, Splunk hashes and encrypts the event.
Search for audit events
Search audit events in Splunk Web or in Splunk's CLI. To do this, pipe your searches to the audit command. The audit search command is most useful if audit event signing has been configured. However, if you want to search for all audit events where audit event signing has not been configured (or to skip integrity validation) you may search the whole audit index.
- To search for all audit events, specify the
This search returns all audit events.
- Pipe your search to the audit command:
index=_audit | audit
This search returns the entire audit index, and processes the audit events it finds through the
Narrow your search before piping to the audit command. However, you can only narrow the time range, or constrain by a single host. This is because each host has its own ID number sequence. Since sequential IDs exist to enable detection of gaps in audit events, narrowing a search across multiple hosts causes false gap detection.
The field that contains the status of the event is called "validity". Values can be:
- VALIDATED - no gap before this event and event signature matches
- TAMPERED - event signature does not match
- NO SIGNATURE - the signature was not found
The field that contains the gap status is called "gap". Values can be:
- TRUE - a gap was found
- FALSE - no gap was found
- N/A - no id was found