Κεφάλαιο 18. Έλεγχος Συμβάντων Ασφαλείας

Selection expressions are used in a number of places in the audit configuration to determine which events should be audited. Expressions contain a list of event classes to match, each with a prefix indicating whether matching records should be accepted or ignored, and optionally to indicate if the entry is intended to match successful or failed operations. Selection expressions are evaluated from left to right, and two expressions are combined by appending one onto the other.

The following list contains the default audit event classes present in audit_class:

These audit event classes may be customized by modifying the audit_class and audit_event configuration files.

Each audit class in the list is combined with a prefix indicating whether successful/failed operations are matched, and whether the entry is adding or removing matching for the class and type.

The following example selection string selects both successful and failed login/logout events, but only successful execution events:

In most cases, administrators will need to modify only two files when configuring the audit system: audit_control and audit_user. The first controls system-wide audit properties and policies; the second may be used to fine-tune auditing by user.

Audit trails are stored in the BSM binary format, so tools must be used to modify or convert to text. The praudit command convert trail files to a simple text format; the auditreduce command may be used to reduce the audit trail file for analysis, archiving, or printing purposes. auditreduce supports a variety of selection parameters, including event type, event class, user, date or time of the event, and the file path or object acted on.

For example, the praudit utility will dump the entire contents of a specified audit log in plain text:

Where AUDITFILE is the audit log to dump.

Audit trails consist of a series of audit records made up of tokens, which praudit prints sequentially one per line. Each token is of a specific type, such as header holding an audit record header, or path holding a file path from a name lookup. The following is an example of an execve event:

This audit represents a successful execve call, in which the command finger doug has been run. The arguments token contains both the processed command line presented by the shell to the kernel. The path token holds the path to the executable as looked up by the kernel. The attribute token describes the binary, and in particular, includes the file mode which can be used to determine if the application was setuid. The subject token describes the subject process, and stores in sequence the audit user ID, effective user ID and group ID, real user ID and group ID, process ID, session ID, port ID, and login address. Notice that the audit user ID and real user ID differ: the user robert has switched to the root account before running this command, but it is audited using the original authenticated user. Finally, the return token indicates the successful execution, and the trailer concludes the record.

Since audit logs may be very large, an administrator will likely want to select a subset of records for using, such as records associated with a specific user:

This will select all audit records produced for the user trhodes stored in the AUDITFILE file.

Members of the audit group are given permission to read audit trails in /var/audit; by default, this group is empty, so only the root user may read audit trails. Users may be added to the audit group in order to delegate audit review rights to the user. As the ability to track audit log contents provides significant insight into the behavior of users and processes, it is recommended that the delegation of audit review rights be performed with caution.

Audit pipes are cloning pseudo-devices in the device file system which allow applications to tap the live audit record stream. This is primarily of interest to authors of intrusion detection and system monitoring applications. However, for the administrator the audit pipe device is a convenient way to allow live monitoring without running into problems with audit trail file ownership or log rotation interrupting the event stream. To track the live audit event stream, use the following command line

By default, audit pipe device nodes are accessible only to the root user. To make them accessible to the members of the audit group, add a devfs rule to devfs.rules:

See devfs.rules(5) for more information on configuring the devfs file system.

Audit trails are written to only by the kernel, and managed only by the audit daemon, auditd. Administrators should not attempt to use newsyslog.conf(5) or other tools to directly rotate audit logs. Instead, the audit management tool may be used to shut down auditing, reconfigure the audit system, and perform log rotation. The following command causes the audit daemon to create a new audit log and signal the kernel to switch to using the new log. The old log will be terminated and renamed, at which point it may then be manipulated by the administrator.

Adding the following line to /etc/crontab will force the rotation every twelve hours from cron(8):

The change will take effect once you have saved the new /etc/crontab.

Automatic rotation of the audit trail file based on file size is possible via the filesz option in audit_control(5), and is described in the configuration files section of this chapter.

As audit trail files can become very large, it is often desirable to compress or otherwise archive trails once they have been closed by the audit daemon. The audit_warn script can be used to perform customized operations for a variety of audit-related events, including the clean termination of audit trails when they are rotated. For example, the following may be added to the audit_warn script to compress audit trails on close:

Other archiving activities might include copying trail files to a centralized server, deleting old trail files, or reducing the audit trail to remove unneeded records. The script will be run only when audit trail files are cleanly terminated, so will not be run on trails left unterminated following an improper shutdown.