Setting up auditing

Edit online

This procedure shows you how to set up an auditing subsystem. For more specific information, refer to the configuration files noted in these steps.

Select system activities (events) to audit from the list in the /etc/security/audit/events file. If you have added new audit events to applications or kernel extensions, you must edit the file to add the new events.
- You add an event to this file if you have included code to log that event in an application program (using the auditwrite or auditlog subroutine) or in a kernel extension (using the audit_svcstart, audit_svcbcopy, and audit_svcfinis kernel services).
- Ensure that formatting instructions for any new audit events are included in the /etc/security/audit/events file. These specifications enable the auditpr command to write an audit trail when it formats audit records.
Group your selected audit events into sets of similar items called audit classes. Define these audit classes in the classes stanza of the /etc/security/audit/config file.
Assign the audit classes to the individual users and assign audit events to the files (objects) that you want to audit, as follows:
- To assign audit classes to an individual user, add a line to the users stanza of the /etc/security/audit/config file. To assign audit classes to a user, you can use the chuser command.
- To assign audit events to an object (data or executable file), add a stanza for that file to the /etc/security/audit/objects file.
- You can also specify default audit classes for new users by editing the /usr/lib/security/mkuser.default file. This file holds user attributes that will be used when generating new user IDs. For example, use the general audit class for all new user IDs, as follows:
```
user:
    auditclasses = general
    pgrp = staff
    groups = staff
    shell = /usr/bin/ksh
    home = /home/$USER
```
  To get all audit events, specify the ALL class. When doing so on even a moderately busy system, a huge amount of data will be generated. It is typically more practical to limit the number of events that are recorded.
In the /etc/security/audit/config file, configure the type of data collection that you want using BIN collection, STREAM collection, or both methods. Make sure that audit data does not compete with other data about file space by using a separate file system for audit data. This ensures that there is enough space for the audit data. Configure the type of data collection as follows:
- To configure BIN collection:
  1. Enable the BIN mode collection by setting binmode = on in the start stanza.
  2. Edit the binmode stanza to configure the bins and trail, and specify the path of the file containing the BIN mode back-end processing commands. The default file for back-end commands is the /etc/security/audit/bincmds file.
  3. Make sure that the audit bins are large enough for your needs and set the freespace parameter accordingly to get an alert if the file system is filling up.
  4. Include the shell commands that process the audit bins in an audit pipe in the /etc/security/audit/bincmds file.
- To configure STREAM collection:
  1. Enable the STREAM mode collection by setting streammode = on in the start stanza.
  2. Edit the streammode stanza to specify the path to the file containing the streammode processing commands. The default file containing this information is the /etc/security/audit/streamcmds file.
  3. Include the shell commands that process the stream records in an audit pipe in the /etc/security/audit/streamcmds file.
When you have finished making any necessary changes to the configuration files, you are ready to use the audit start command to enable the audit subsystem. This will generate the AUD_It event with a value of 1.
Use the audit query command to see which events and objects are audited. This will generate the AUD_It event with a value of 2.
Use the audit shutdown command to deactivate the audit subsystem again. This will generate the AUD_It event with a value of 4.