Central audit logging: Configuration and collecting of Linux audit events

Central audit logging: Configuration and collecting 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.

/etc/rsyslog.conf

# Receive syslog messages via TCP
$ModLoad imtcp
$InputTCPServerRun 65432

 

$AllowedSender TCP, 127.0.0.1, 192.168.1.0/24, 1.2.3.4

 

 

$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

/etc/rsyslog.conf

# 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
$InputRunFileMonitor

local6.* @@logserver.cisofy.com:65432

Permissions

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.

Testing

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”

 

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)