Deciding Who and What to Audit

1. Determine the audit classes that you need for your site 

The best time to add audit classes or to change the default classes is before you start the auditing service. 

See Audit Classes and Their Audit Flags for information about auditing classes.

2. Determine event-to-class mappings 

In many situations, the default mapping is sufficient. However, if you have added new classes or have changed class definitions, you might also need to move an event to a different class. 

3. Decide what classes should be audited for all users on all machines 

The system-wide audit flags in the audit_control file apply to all users and processes. Audit flags determine whether an audit class is audited for success, for failure, or for both. Every machine in the installation should have the same audit flag settings in the machines' audit_control file.

4. Determine user exceptions to the installation-wide audit settings 

If you decide that some users should be audited differently from the system-wide settings, modify the users' entries in the audit_user file on each machine.

For more information, see How to Change Users' Audit Characteristics.

5. Determine the minimum free disk space (minfree) that should be available on an audit file system before a warning is sent

When disk space on an audit file system drops below the minfree percentage, the audit daemon switches to the next available audit directory. The daemon then sends a warning that the soft limit has been exceeded.

For more information, see Example—Changing the Soft Limit for Warnings.

6. Decide which audit policies your site needs 

The policy variable is a dynamic kernel variable, so its value is not saved when the system is brought down. Therefore, you should set the desired policy by using an appropriate startup script. 

For more information, see How to Enable or Disable an Audit Policy.

7. Decide how to manage the audit_warn mail alias

The audit_warn script is run by the auditd daemon whenever the daemon switches audit directories. The script also runs when the daemon encounters a difficulty, such as a lack of disk space. By default, the audit_warn script sends mail to an audit_warn alias and sends a message to the console. You need to either modify the alias, or change the script to send the message to a different alias.

For more information, see How to Configure the audit_warn Alias.

8. Decide what to do when all the audit directories are full 

To permit the system to continue functioning in the event of an audit trail overflow, you can enable the cnt policy.

For a cnt policy example, see Example—Setting the cnt Policy.

Alternatively, you can create an account that can log in and work without being audited. 

See Example—Creating an Audit Admin Login for an audit account example.