Configuration and collecting of Linux audit events

This guide is to help our users of the Lynis Enterprise Suite to configure a central node to receive Linux audit events. It provides some pointers on how to do a quick set-up, to store and forward events. This information is very valuable for forensic investigations and intrusion detection.

Configure the server

First start by configuring the server. Since this is a central log host, it should have enough disk capacity and enough bandwidth to sustain peaks.

For these examples we use the rsyslog server. It’s commonly available on Linux distributions and a very powerful syslog daemon, with flexibility in mind.


# Receive syslog messages via TCP  
$ModLoad imtcp  
$InputTCPServerRun 514
$AllowedSender TCP,,,

Restart the rsyslog daemon and see if it now listens to port 514

ss -plant | grep 514

Send a test message from a client system

logger -p --tcp -P 514 --server test

If that works correctly, let’s further tune the configuration to allow for a custom file format.

$template HostAudit, "/var/log/rsyslog/%$YEAR%/%$MONTH%/%$DAY%/%HOSTNAME%_audit.log"  
$template auditFormat, "%msg%\n"
local6.*      ?HostAudit;auditFormat

The ModLoad enables the reception of syslog messages. Depending on your set-up, you can also alter the default listening port (514) and limit allowed senders. The format (HostAudit) creates a directory structure for the audit files, by date and puts data in a file specifically by hostname. To avoid cluttering up files, hostnames should therefore be unique.

Configure the clients

On the client we have to adjust the rsyslog configuration to perform two tasks:

  • Monitor the audit file
  • Log all events to the central node


# Add under the modules section  
$ModLoad imfile

# Add at the end of the file

# Add at bottom of configuration file  
$InputFileName /var/log/audit/audit.log  
$InputFileTag tag\_audit\_log:  
$InputFileStateFile audit_log  
$InputFileSeverity info  
$InputFileFacility local6  

local6.* @@


Make sure to adjust the group membership of /var/log/audit and underlying files to syslog. This way the rsyslog daemon can actually read the files. After adjusting the permissions, reload rsyslog and check for any warnings in /var/log/syslog.


On the client, use cat of a file which is being watched (in our case /home/cisofy/test).

This should create an event on the client system itself, in the /var/log/audit/audit.log file. We can test this with the command ausearch -k test.

Next check is to see if the data has been logged on both the client system and remote syslog server.

root@server:/var/log/rsyslog/2014/03/19# ausearch -if cisofy1_audit.log -k test
time->Wed Mar 19 19:08:46 2014  
type=PATH msg=audit(1395252526.691:8194): item=0 name="test" inode=411440 dev=fd:03 mode=0100664 ouid=1002 ogid=1002 rdev=00:00  
type=CWD msg=audit(1395252526.691:8194):  cwd="/home/cisofy"  
type=SYSCALL msg=audit(1395252526.691:8194): arch=c000003e syscall=90 success=yes exit=0 a0=1ae23a0 a1=81b4 a2=0 a3=0 items=1 ppid=4725 pid=31097 auid=1002 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002 sgid=1002 fsgid=1002 tty=pts0 ses=2690 comm="vi" exe="/usr/bin/vim.tiny" key="test"

Relevant commands in this article

Like to learn more about the commands that were used in this article? Have a look, for some there is also a cheat sheet available.


Small picture of Michael Boelen

This article has been written by our Linux security expert Michael Boelen. With focus on creating high-quality articles and relevant examples, he wants to improve the field of Linux security. No more web full of copy-pasted blog posts.

Discovered outdated information or have a question? Share your thoughts. Thanks for your contribution!

Mastodon icon