Monitoring Events with AIX Audit

Print 1

 

The AIX* built-in audit subsystem allows system administrators to monitor and record security-related events on the system. This utility provides a good footing for identifying security vulnerability concerning user profile attribute changes and security settings on your system files. You can also use the audit reports to make security decisions based on the Sarbanes-Oxley Act of 2002 (SOX) recommendation for UNIX systems and your internal policy. In this article, I’ll describe how to configure AIX’s built-in audit system to monitor events.

About Audit

AIX Audit works by defining an audit class, which can be any name. Within this class, audit events, such as logging in and file changes, are defined. Once audit is running, any event that has been defined will be monitored, and can be tracked in the audit log. Events can be recorded on a per-user basis or by groups of users. Individual files can also be monitored. The IBM Redbooks* publication, “Accounting and Auditing on AIX 5L” (SG24-6396-00, http://www.redbooks.ibm.com/abstracts/sg246396.html?Open) contains the full list of audit events, their meanings and how audit works.

The list of system or ad-hoc files to monitor can be exhaustive, so I’ll just focus on a few. Looking at a typical framework for a daily security audit, I would recommend it contain at least user account-changed attributes, user account-changed passwords and user su attempts. I’ll leave it up to you to address other system events you wish to monitor. As is always the case, what needs to be audited will depend on your security policy.

One thing to note is audit will monitor against the user ID for the audit event triggered and not the audit event itself. When data is written to the audit log, it’s written as a record that includes a header and a tail. The header contains the user, the time, the type of event and whether or not it was successful. The tail consists of other available information, like the parsing attributes. Auditing data can be collected in two modes, bin or stream. This article will only describe the stream mode. The stream mode writes to a circular buffer file, thus when the file becomes full it starts re-writing at the beginning of the file. Clearly the stream mode has advantages; if a file system containing the audit log file becomes full, it’ll still log events.

Let’s Configure

The audit configuration files are located in /etc/security/audit, and all the configurations files are populated with default settings. The destination of the audit log is located in /audit; this is the main audit log. For stream mode, the log file is /audit/stream.out. I strongly suggest the directory /audit is mounted as a file system. It if isn’t you could be in danger of filling up the root file system.

When audit is running, it will log events in non-readable form. To read the events, you must inform audit of the command to use. This command goes in the streamcmds file. The command to read the events is auditpr; this is piped from the auditstream utility. The auditstream reads the audit records and copies them to stdout. The auditpr utility formats the output prior to its transfer to the audit log. The file /etc/security/streamcmds should contain the following command to correctly process and format the audit record into the audit log:

/usr/sbin/auditstream | auditpr -v > /audit/stream.out & 

The file /etc/security/audit/config contains the audit configuration information. Here, audit is tracking the mode used, the commands associated with the mode, the classes to monitor and the users to monitor. Let’s look more closely at the config file.

1. Select which mode is used at startup. In the following stanza, only streammode will be used:

start:
        streammode = on
        binmode = off 

2. Identify the location of the streammode command to process auditing:

stream:
        cmds = /etc/security/audit/streamcmds 

3. The audit events or classes can now be defined for the kernel to hook into. Auditclass is the name for the class name of events. The audit_event are the event(s) to be monitored. The format for defining the classes stanza is:

classes:
auditclass=audit_event,audit_event, ... 

4. In the users stanza, define the users to monitor for the audit events.

users:
user_name = audit_class, audit_class 

AIX provides the word default, to include all users. All users by default belong to the auditclass general. However, you may want certain users monitored on certain audit events. Different users can be associated with different classes; I’ll discuss different classes and users later.

For each audit event entry in /etc/security/config, there should be a corresponding entry in the /etc/security/events file. This events file contains entries for each audit event on how they should be formatted in the audit log via auditpr. If you only use pre-defined events for an audit class, these entries will already be in the events file. To monitor files for change or modification, there must be an entry in the /etc/security/objects file for each event being monitored. AIX Audit will reference these files as audit objects. This file will already be populated with entries for most of the files contained in /etc/security directory; this is the default, unless the user changes the default settings. To add an entry, the format for this stanza is:

full path to file:
access mode = "audit event" 

Access mode can be r ( read), w ( write) or x (execute), and the audit event is a short, unique, descriptive name for the event—which will get printed in the audit log if the user triggers this event. So, to add the file /etc/sudoers to monitor read and writes I’d use:

/etc/sudoers:
       r = "SUDO_READ"
       w = "SUDO_WRITE" 

For each customized entry of the objects file, a corresponding print command should go into the events file. For example, the following files will also be monitored and flagged if they are written to:

/etc/inetd.conf
/etc/syslog.conf
/etc/sudoers 

The following (local script) file will also be monitored if executed:

/usr/local/bin/pass_set.sh 

The entry in /etc/audit/objects for these files, could be:

/usr/local/bin/pass_set.sh:
        x= "PASS_SET_EXE"
/etc/inetd.conf:
        w= "INET_WRITE"
/etc/syslog.conf
        w = "SYSLOG_WRITE"
/etc/sudoers:
        w = "SUDO_WRITE" 

Add more file entries to the objects file to suit your own audit file policy needs. The objects cannot be tied by user ID like audit events, rather they are logged by any user referencing the objects.

The /etc/security/audit/events file should contain entries on how each audit object should be handled by auditpr. If you are using predefined objects, there is no need to add these entries, as they will already be present. In this example I’ve added the following objects (or files):

/etc/sudoers
/etc/syslog.conf
/etc/inetd.conf
/usr/local/bin/pass_set.sh 

A normal printf statement will suffice. The basic format for object entries in the /etc/security/audit/events file is:

*         full path to object
    audit event = printf "%s" 

To add inetd.conf to the events file, in the objects section I could use:

*       /etc/inetd.conf
        INET_WRITE= printf "%s" 

Running Audit

To start the audit subsystem, use # /usr/sbin/audit start. To stop the audit subsystem, use # /usr/sbin/audit shutdown. To view the current status of the audit—to see what mode it is running under and what classes are being monitored—use # /usr/sbin/audit query. Please note, when audit is restarted the stream.out file will be overwritten. At this point, I’m ready to invoke the audit subsystem. Let’s start it, query the configuration and see audit record events as per this configuration:

# /usr/sbin/audit start
# /usr/sbin/audit query 

The output of the audit query command is contained in Listing 1 query output. Notice in Listing 1 audit has output the current audit classes and events being monitored, as well as the objects being monitored.

Next, I invoked some user attribute changes and su commands, and the /audit/stream.out file has been populated with the events as they are triggered. Listing 2 Audit Log shows typical events that are recorded. Notice in Listing 2, that user spmak, not root, executed the chuser command and visudoand. User spmak is an administrator, and is allowed to su to root. The su to root event is recorded in the above listing. Audit will always try and report the initial login ID of the user. If the user has SSH from another host, then audit won’t be able to discover his or her original login ID, so audit will only report the SSH connection.

Customize Audit Monitoring

It may be the case that you only want to monitor certain users on certain events. No problem. First, choose the events to be monitored, then select a class name for those events. Next, add those users to the user stanza, tying them to the event class you have created. Then, add the new audit class to the users auditclassess attribute. Finally, restart audit and the events will be logged. Normal monitoring for the user account changes, su attempts, etc., will still apply, as will any of the files contained in the objects file.

Audit Log Rotation

Now information is being collected in the audit log, some automation is now required. Ideally the audit log ( /audit/stream.out) should be rolled over each night, so there is one audit log for each day’s events. To roll/rotate the audit log, it’s best to use via cron or another scheduler. The commands to run just before midnight could be:

# /usr/sbin/audit shutdown
# sleep 5
# mv /audit/stream.out /audit/audit`date +%m%d`.log
# /usr/sbin/audit start
# fuser -k /audit/audit`date +%m%d`.log 

Running audit is a good practice; it demonstrates to the external auditors and internal security officers that you can produce evidence on security-related events. It helps build trust, and can identify ways to improve you current internal security policy.

Listing 1 query output

auditing on
bin processing off
audit events:
        general - File_Write,PASSWORD_Change,USER_Change,USER_Remove,USER_Create
,GROUP_Change,GROUP_Create,GROUP_Remove,USER_SU,AUD_lt

audit objects:

        /usr/local/bin/pass_set.sh:
                 x = PASS_SET
        /etc/syslog.conf:
                 w = SYSLOG_WRITE
        /etc/sudoers:
                 w = SUDO_WRITE
...
...
...  

Listing 2 Audit Log

USER_SU    spmak      OK         Fri Nov 28 10:22:03 2008 su
    root
USER_Change     spmak     OK          Fri Nov 28 12:16:16 2008 chuser
        alpha data=-1
USER_SU         alpha    FAIL              Fri Nov 28 12:54:03 2008 su
        bravo
SUDO_WRITE     spmak      OK         Fri Nov 28 22:01:33 2008 visudo
audit object event detected /etc/sudoers