If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.
Determine if you want a single-system image audit trail.
Systems within a single administrative domain can create a single-system image audit trail. If your systems use different naming services, start with the next step. You should complete the rest of the planning steps for every system.
A single-system image audit trail treats the systems that are being audited as one machine. To create a single-system image audit trail for a site, every system in the installation should be configured as follows:
Use the same naming service.
To interpret the audit records, two commands are used, auditreduce and praudit. For correct interpretation of the audit records, the passwd, hosts, and audit_user files must be consistent.
Use the same audit service settings for all systems. For information about displaying and modifying the service settings, see the auditconfig(1M) man page.
Use the same audit_warn, audit_event, and audit_class files for all systems.
Use the same audit_user database. The database can be in a naming service such as NIS or LDAP.
Have identical flags, naflags, and plugin entries in the audit_control file.
Determine the audit policy.
Use the auditconfig -lspolicy command to see a short description of available policy options. By default, only the cnt policy is turned on. For a fuller discussion, see Step 8.
Determine if you want to modify event-to-class mappings.
In many situations, the default mapping is sufficient. However, if you add new classes, change class definitions, or determine that a record of a specific system call is not useful, you might also need to move an event to a different class.
For an example, see How to Change an Audit Event's Class Membership.
Determine which audit classes to preselect.
The best time to add audit classes or to change the default classes is before you start the audit service.
The audit class values of the flags, naflags, and plugin entries in the audit_control file apply to all users and processes. The preselected classes determine whether an audit class is audited for success, for failure, or for both.
To preselect audit classes, see How to Modify the audit_control File.
Determine user exceptions to the system-wide preselected audit classes.
If you decide that some users should be audited differently from the system-wide preselected audit classes, modify the individual users' entries in the audit_user database.
For an example, see How to Change a User's Audit Characteristics.
Determine the minimum free disk space.
When disk space on an audit file system drops below the minfree percentage, the auditd daemon switches to the next available audit directory. The daemon then sends a warning that the soft limit has been exceeded.
To set the minimum free disk space, see Example 30–4.
Decide how to manage the audit_warn email alias.
The audit_warn script is run whenever the audit system needs to notify you of a situation that requires administrative attention. By default, the audit_warn script sends email to an audit_warn alias and sends a message to the console.
To set up the alias, see How to Configure the audit_warn Email Alias.
Decide what action to take when all the audit directories are full.
By default, when the audit trail overflows, the system continues to work. The system counts the audit records that are dropped, but does not record the events. For greater security, you can disable the cnt policy, and enable the ahlt policy. The ahlt policy stops the system when an asynchronous event cannot be placed in the audit queue.
For a discussion of these policy options, see Audit Policies for Asynchronous and Synchronous Events. To configure these policy options, see Example 30–13.
Decide whether to collect audit records in binary format, in syslog format, or in both formats.
For overview information, see Audit Logs.
For an example, see How to Configure syslog Audit Logs.