Before you enable auditing on your network, you might want to edit the audit configuration files. Many of the following procedures require you to restart the service or reboot the local system. You should make as many of these changes as possible before you start the service.
The following task map describes the tasks in this section.
Task |
Description |
For Instructions |
---|---|---|
Select audit flags, change audit_control settings |
Preselects the events are being to be audited. Changes preset values in the audit_control file. | |
Change audit characteristics for users |
Sets user-specific exceptions to the system-wide audit flag settings. | |
Add audit classes |
Defines new audit classes. | |
Change event-to-class mappings |
Changes the class that certain events belong to | |
Add audit events |
Adds new user-level events to the audit_event file. |
Audit flags are defined in the /etc/security/audit_control file. The audit flags select which classes of audit records are written to the audit log.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_control file.
# cp /etc/security/audit_control /etc/security/audit_control.save |
Add new entries to the audit_control file.
Each entry has the following format:
title:string |
Defines the type of line. Options are dir:, flags:, minfree:, or naflags:.
Lists specific data that is associated with the line type.
Instruct the audit daemon to read the new audit_control file.
The audit daemon stores the information internally. To use the new information, either reboot the system or type the following command:
# audit -s |
Lines that start with dir: define which audit file systems can be used to store audit trail files. In this example, two additional locations for audit trail files are defined.
# cat /etc/security/audit_control dir:/etc/security/audit/host.1/files dir:/etc/security/audit/host.2/files dir:/var/audit flags: minfree:10 naflags:lo |
The flags line in the audit_control file defines which classes of events are audited for all users on the host. The classes are separated by commas, with no spaces. In this example, the events in the lo class are audited for all users.
# cat /etc/security/audit_control dir:/var/audit flags:lo minfree:10 naflags:lo |
The minfree line in the audit_control file defines the minimum free-space level for all audit file systems. In this example, the soft limit is set so that a warning is issued when only 10 percent of the file system is available.
# cat /etc/security/audit_control dir:/var/audit flags: minfree:10 naflags:lo |
The naflags: line in the audit_control file defines which classes of nonattributable events are audited for all users on the host. The classes are separated by commas, with no spaces. In this example, the na event class was added.
# cat /etc/security/audit_control dir:/var/audit flags: minfree:10 naflags:lo,na |
Definitions for each user are stored in the /etc/security/audit_user file. These definitions are exceptions to the flags in the audit_control file.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_user file.
# cp /etc/security/audit_user /etc/security/audit_user.save |
Add new entries to the audit_user file.
Each entry has the following format:
username:always:never |
Selects the name of the user to be audited.
Selects the list of audit classes that should always be audited.
Selects the list of audit classes that should never be audited.
You can specify multiple flags by separating the audit classes with commas. For more information about audit flags, see Audit Classes and Their Audit Flags.
Make the new data available to the auditing daemon.
To use the new data, you can reboot the system. You can also have the user log out and then log back in again.
This example shows an entry that causes audit records to be generated any time that the user sue accesses any programs in the login class (lo).
# grep sue /etc/security/audit_user sue:lo: |
If all the audit partitions are full and logins are audited, then users might not be able to log in to a host. To avoid this situation, you can set up a special account that is not audited. The special account could log in to the host even when the audit partitions are full, and fix the problem with the full partitions. In this example, the account auditadm is defined so that no auditing takes place.
# grep auditadm /etc/security/audit_user auditadmin:no:yes |
The user who is selected to use the audit admin account might need to be monitored in another way.
Audit classes are defined in the /etc/security/audit_class file.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_class file.
# cp /etc/security/audit_class /etc/security/audit_class.save |
Add new entries to the audit_class file.
Each entry has the following format:
0xnumber:name:description |
Identifies number as hexadecimal.
Defines the unique audit class mask.
Defines the two-letter name of the audit class.
Defines the descriptive name of the audit class.
Make the new data available to the BSM service .
To use the new data, either reboot the system, or type the following command:
# auditconfig -conf |
In this example, add an entry to the audit_class file that resembles the following entry. The entry creates a new audit class that is called ta.
0x01000000:ta:test application |
Event-class mappings are defined in the /etc/security/audit_event file.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_event file.
# cp /etc/security/audit_event /etc/security/audit_event.orig |
Change the class to which particular events belong by changing the flag of the events.
Each entry has the following format:
number:event:program:flag |
Defines the audit event ID.
Defines the name of the audit event.
Defines the system call or user-level program executable that triggers the creation of an audit record.
Defines the two-letter name of the audit class.
Make the new data available to the BSM service.
To use the new data, either reboot the system, or type the following commands:
# auditconfig -conf # audit -s |
In this example, you define a new class, and then add events to that class. To use the mapping, put the new class in the audit_control file, then reboot the system.
In the audit_class file, define a site-specific class to collect just those audit events that you want to monitor.
0x00000800:sc:site class |
In the audit_event file, change a set of audit events to the new class.
26:AUE_SETGROUPS:setgroups(2):sc 27:AUE_SETPGRP:setpgrp(2):sc 40:AUE_SETREUID:setreuid(2):sc 41:AUE_SETREGID:setregid(2):sc 214:AUE_SETEGID:setegid(2):sc 215:AUE_SETEUID:seteuid(2):sc |
Use the new flag in the audit_control file. The following entry audits logins, and audits all successful invocations of the events in the sc class.
flags:lo,+sc |
To ensure that the new configuration audits all processes, reboot the system. Or, you can use the following set of commands to ensure that each user who uses the machine is correctly audited. auid is the user ID.
# auditconfig -conf # audit -s # setumask auid lo,+sc |
Audit event definitions are stored in the /etc/security/audit_event file.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_event file.
# cp /etc/security/audit_event /etc/security/audit_event.save |
Add new entries to the audit_event file.
Each entry has the following format:
number:name:description:classes |
Defines a unique audit event number, which must start after 32767.
Defines the unique audit event name.
Describes the audit event. Often includes the name of the man page for the audit event.
Selects the audit classes that include this event.
Make the new data available to the auditing daemon.
To use the new data, either reboot the system, or type the following command:
# auditconfig -conf |
This example shows an entry that defines a new audit event for a local application.
# grep localapp /etc/security/audit_event 32768:AUE_localapp:localapp(1):ta |