IBM Support

AIX Audit: Redirecting 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. You should also consider that the audit stream data is plain text, and you should manage this data according to your security requirements.
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. See the Important Note  at the end of this note regarding the pipeline for this method.
  • 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.

Additional Information

Security scanners and intrusion detection systems (IDS) gather information about systems by inspecting files, checking for vulnerabilities, and monitoring services. Security scanners focus on identifying vulnerabilities, while IDS monitors for signs of active intrusions. Their activities, such as probing ports, inspecting processes, and checking configuration files, might inadvertently, or even intentionally, trigger a service restart.

The logger command is an interface to the syslog subroutine. It depends on a functioning syslogd.

In the example streamcmds, the logger command forwards audit records to syslogd. If syslogd is restarted, the logger process loses its connection to the logging service. As a result, the entire pipeline breaks because logger can no longer deliver messages to syslogd. Since logger becomes the parent process of the other components in the pipeline (such as auditstream and auditpr), the disconnection causes these commands to exit as well.
If you experience issues with syslog restarting, it is recommended to have some contingency plans.
Some plans might include:
1) Run the audit in bin mode to ensure that auditing continues to be logged locally even if the stream mode exits.
2) Run multiple auditstream processes, with the second one writing to a local /audit/stream.out.
3) Write some script to check for the process, restart the audit daemon if  syslog gets restarted.
These solutions are out of scope for AIX Support. If you have specific questions about the recommended documentation, IBM support experts are happy to assist you. If you require consulting services, there are additional fee based services available.
IBM Technology Expert Labs infrastructure services
Email: systems-expert-labs@ibm.com

Document Location

Worldwide

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"ARM Category":[{"code":"a8m0z000000cw2BAAQ","label":"Security-\u003EAudit"}],"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:
03 October 2024

UID

ibm16233286

Page Feedback