Suggested Audit Events

When deciding which system events to audit, you need to keep in mind that auditing uses system resources. Logging a large number of events to allow for in-depth auditing has a cost in terms of system performance.

The safest practice is to log all events at all times. But unless your system requires very thorough security protection, this is unnecessary. Typically, you can achieve an adequate level of protection by regularly logging a limited number of events and by performing deeper logging at more widely spaced intervals. This provides a

reasonable level of auditing capability and minimizes the impact on system performance.

Note

If you vary the depth of logging, avoid signalling to the user community the times when the deep audits occur; otherwise, would-be violators, hoping to avoid detection, will simply avoid those times for their illicit activity.

4.7.1 Dependencies Among Audit Events

In order for certain information to be available, particular system calls must be logged. For example, to be able to retrieve audit records by user name, login must be logged. You should log the following at all times:

login

chroot, chdir

open

Provides a connection between the user name and the audit ID or real UID. When given an audit ID or RUID, the audit tool returns a user name only when login is being logged.

Log records do not include the current directory or absolute pathname of a process. If chroot and chdir are logged, then the audit tool can return the current working directory of a process.

Provides a connection between the file descriptor and the filename. When events such as dup are logged, the file descriptor allocated by the event but not the file name is returned. If you log open in addition to logging the process that allocates the descriptor, then you can learn the file name associated with the events.

fcntl, dup, dup2 Events that allocate file descriptors.

exit Makes the audit tool more efficient. The audit tool keeps track of information for each process in the audit log it is analyzing. By knowing when a process exited, the audit tool can stop maintaining information on that process.

4.7.2 Auditable Events

The following tables lists all of the auditable events, dividing them into two

categories: auditable system calls and auditable trusted events. A trusted event is an event that is associated with a security protection mechanism. It does not always correspond directly to a system call.

If you don't use the audi tmask command to tailor the list of audited events to the needs of your site, then the events in the table are audited as indicated. A list of all auditable events can also be found in the the file /etc/sec/audit_events.

Table 4-2: Auditable System Calls Event Audited Conditions accept succeed fail

access succeed fail

acct succeed fail

audcntl succeed fail

bind succeed fail

chdir succeed fail chmod succeed fail chown succeed fail chroot succeed fail

close succeed

connect succeed fail creat succeed fail

dup succeed

dup2 succeed

execv succeed fail execve succeed fail

exit succeed

Tracking Activity on the System: Auditing 4-13

Table 4-2: (continued)

Event Audited Conditions exportfs succeed fail

fchmod succeed fail old setpgrp succeed fail old setuid succeed fail recvmsg succeed fail rename succeed fail rmdir succeed fail semctl succeed fail semget succeed fail sendmsg succeed fail sendto succeed fail setdomainname succeed fail setgroups succeed fail sethostid succeed fail sethostname succeed fail setpgrp succeed fail setregid succeed fail setreuid succeed fail setsysinfo succeed fail settimeofday succeed fail shmat succeed fail

Table 4-2: ( continued)

Event Audited Conditions symlink succeed fail

truncate succeed fail umount succeed fail unlink succeed fail utimes succeed fail vhangup succeed fail

Table 4-3: Auditable Trusted Events Event

The audgenS and login trusted events correspond to the use of those commands.

The other trusted events relate to auditing and authentication activity as follows:

audit daemon exit

The audit daemon exited abnormally. This occurs only when there is insufficient memory available during initialization of the audit daemon. The exit is recorded in the new audit log, and a message is displayed on the system console.

audit_log_change

The audit daemon closed the current audit log and began writing a new log (for example, in response to the -x auditd option). The change in logs is recorded in the current (pre-change) audit log, and a message is displayed on the system console.

audit_log_creat

A new audit log was created in response to the accidental loss of the current log file. The new file has the generation number of the lost log file incremented by 1. The creation of the new log is recorded at the beginning of the new audit log, and a message is displayed on the system console.

Tracking Activity on the System: Auditing 4-15

audit_lag_overwrite

The audit daemon began overwriting the current audit log in response to an overflow of the log (you previously used the ^{- 0} auditd option to select e, which specifies overwrite as the overflow action). The overwrite is recorded at the beginning of the newly overwritten audit log, and a message is displayed on the system console.

audit reboot

The audit daemon initiated a system reboot in response to an overflow of the log (you previously used the - 0 auditd option to select b, which specifies reboot as the overflow action). The reboot is recorded at the end of the current audit log, and a message is displayed on the system console before the reboot occurs.

audit_setup

The - 0 option of the audi td command was used to change the specified overflow action. The change in the audit setup is recorded in the current audit log.

audit shutdown

The audit daemon was killed normally (typically, with the -k auditd option.

The shutdown is recorded at the end of the current audit log, and a message is displayed on the system console when the shutdown occurs.

audit_suspend

The audit daemon suspends auditing in response to an overflow of the log (you previously used the - a auditd option to select d, which specifies suspension as the overflow action). The suspension is recorded in the current (pre-suspension) audit log, and a message is displayed on the system console.

audit xmit fail

The audit daemon was sending audit records across a network and the transmission failed. The failure is recorded in the local log specified as the alternate path (with the -b option) or the default local path (/ u s r / a drn) .

auth event

An event associated with user-authentication and the management of user accounts occurred. Trusted auth events include adduser, vipw, passwd, login, and edauth. The event is recorded in the current audit log.

For a description of the information contained in a report for login and other auth_events, see Section 4.8.3