IBM Support

Redirecting AIX® audit events to the syslogd subsystem

How To


Summary

This document shows a typical set-up for AIX® auditing subsystem redirected to the syslogd.

Objective

Describe and explain the typical set-up.

Environment

It is common for AIX® administrators to be asked to set up auditing and redirect the output to syslogd.
The syslogd can then either or both write the output to a local file or forward to a central syslog system.
That set-up is often seen in environments that use Qradar® or similar products.

Steps

Configure the /etc/syslog.conf file:
        In the syslog.conf file, you need to add lines with facility and priority that will correspond to the ones used in the logger command that will be used in next steps. Then, choose the destination where the syslog writes these events, and possible options for that destination. Several entries can be made for the same facility and priority, also other entries with higher priorities or wild facility or priority might log the events coming from the audit subsystem.         
        Depending on the audit set up and the frequency of events, you might have to pay attention to the number of entries you have here so that the syslogd subsystem is not overloaded. In this example, we are going to use the facility "local7" and priority "notice" so that it writes outputs to auditlog with rotating options. It is also going to forward outputs to the central_syslog system.
/etc/syslog.conf entries:
local7.notice /var/adm/auditlog rotate time 1w files 4 
local7.notice @central_syslog
      Once the /etc/syslog.conf is modified use the following for the new set-up to be taken into account.
touch /var/adm/auditlog
stopsrc -s syslogd 
startsrc -s syslogd 
Configure /etc/security/audit/config:
        In the config file, we set at least binmode to off and streammode to on.
        Then, for each user or the default user we set in the user stanza the list of classes we want to audit. 
Configure the /etc/security/audit/streamcmds:
        The typical streamcmds is as follows:
/usr/sbin/auditstream | /usr/sbin/auditselect -m -e "command != logger && command != auditstream && command != auditpr && command != auditselect"|auditpr -t0 -h eclrRdi -v |awk -u 'NR%2{printf "%s ",$0;next}{print;}' | /usr/bin/logger -p local7.notice -r &
  • The auditstream command read events from the audit subsystem and pass them to the auditselect command
  • The auditselect here is used to filter out events we don't need to audit, these events are generated by the different commands generated by the streamcmds pipeline itself.
  • The auditpr command converts the events in a readable format.
  • Because the auditpr write two lines on output for each event, we use an awk command to merge these two lines into one.
  • Finally, the logger command sends the output to the syslogd subsystem on the local7 facility with a notice severity. The "-r" option is required here, the syslogd daemon when too busy might drop messages, the -r option ensure that the logger command retries logging these messages until the syslogd accept them.
  • The "&" make the whole pipeline run in background, which allows several pipelines to be run in parallel that might trigger different events based on the auditselect parameters.
 Finally, start the audit subsystem:
        The audit start starts the streamcmds pipeline and events are logged in the syslog outputs depending on your syslog.conf set-up.

Document Location

Worldwide

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"a8m0z000000cw2BAAQ","label":"Security->Audit"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Version(s)","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}}]

Document Information

Modified date:
17 June 2020

UID

ibm16233286