Linux audit – Log files in /var/log/audit

Linux audit – Log files /var/log/audit

By default the Linux audit framework logs all data in the /var/log/audit directory. Usually this file is named audit.log.

/var/log/audit/audit.log

This is the default log file for the Linux audit daemon. The file has a capture of all related audit events. It has been configured in auditd.conf:

root@server# cat /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

 

Usually there is no reason to alter this location, unless a different storage location is preferred. For safeguarding of the data, it’s also wise to monitor this file and duplicate data to a locate storage location (e.g. with remote syslog).

Tools

Although the log file is logged in plain ASCII format, it is better suited for parsing with specific tools in the audit framework.

ausearch

This utility helps with searching specific events, for example during the last day and with a specific type. Another possibility is filtering on a defined column, like a file name. In this case the file name should match the requested name.

aureport

While searching for data has its purpose, reporting is a second useful goal. The aureport utility comes in handy and extracts all data from the file. It will then present the system administrator or auditor with the related information. This information varies from configuration changes (to the audit daemon) up to the amount of failed system calls (syscalls).

Summary Report
======================
Range of time in logs: 12/07/2013 03:30:01.190 – 04/18/2014 15:00:01.378
Selected time for report: 12/07/2013 03:30:01 – 04/18/2014 15:00:01.378
Number of changes in configuration: 425
Number of changes to accounts, groups, or roles: 0
Number of logins: 0
Number of failed logins: 0
Number of authentications: 0
Number of failed authentications: 0
Number of users: 5
Number of terminals: 10
Number of host names: 0
Number of executables: 32
Number of files: 223
Number of AVC’s: 0
Number of MAC events: 0
Number of failed syscalls: 4190
Number of anomaly events: 3
Number of responses to anomaly events: 0
Number of crypto events: 0
Number of keys: 3
Number of process IDs: 31405
Number of events: 116468

The example above shows clearly how broad the events can be to be monitored. Proper configuration and safeguarding of the audit.log file will be necessary to protect this valuable information!

Lynis Enterprise

Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series and the mission to get Linux and Unix-based systems more secure.

Does system hardening take a lot of time, or do you have any compliance in your company? Have a look at Lynis Enterprise.

Or start today with the open source security scanner Lynis (GitHub)