diff --git a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml index eb18d4a5b8..3fcb4dc0c6 100644 --- a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml @@ -1,558 +1,558 @@ Tom Rhodes Written by Security Event Auditing Synopsis AUDIT Security Event Auditing MAC The &os; 7-CURRENT development branch includes support for Event Auditing based on the &posix;.1e draft and - &sun;'s published BSM API and file format. + Sun's published BSM API and file format. Event auditing permits the selective logging of security-relevant system events for the purposes of post-mortem analysis, system monitoring, and intrusion detection. After some settling time in &os; 7-CURRENT, this support will be merged to &os; 6-STABLE and appear in subsequent releases. The audit facility in FreeBSD is considered experimental, and production deployment should occur only after careful consideration of the risks of deploying experimental software. This chapter will focus mainly on the installation and configuration of Event Auditing. Explanation of audit policies, and an example configuration will be provided for the convenience of the reader. After reading this chapter, you will know: What Event Auditing is and how it works. How to configure Event Auditing on &os; for users and processes. Before reading this chapter, you should: Understand &unix; and &os; basics (). Be familiar with the basics of kernel configuration/compilation (). Have some familiarity with security and how it pertains to &os; (). Event auditing can generate a great deal of log file data, exceeding gigabytes a week in some configurations. An administrator should read this chapter in its entirety to avoid possible self inflicted DoS attacks due to improper configuration. The implementation of Event Auditing in &os; is similar to that of the &sun; Basic Security Module, or BSM library. Thus, the configuration is almost completely interchangeable with &solaris; and Mac OS X/Darwin operating systems. Key Terms - Words to Know Before reading this chapter, a few key terms must be explained. This is intended to clear up any confusion that may occur and to avoid the abrupt introduction of new terms and information. event: An auditable event is an event that can be logged using the audit subsystem. The administrator can configure which events will be audited. Examples of security-relevant events include the creation of a file, the building of a network connection, or the logging in of a user. Events are either attributable, meaning that they can be traced back to a user authentication, or non-attributable. Examples of non-attributable events are any events that occur before authentication has succeeded in the login process, such as failed authentication attempts. class: Events may be assigned to one or more classes, usually based on the general category of the events, such as file creation, file access, or network. Login and logout events are assigned to the lo class. The use of classes allows the administrator to specify high level auditing rules without having to specify whether each individual auditable operation will be logged. record: A record is a log entry describing a security event. Records typically have a record event type, information on the subject (user) associated with the event, time information, information on any objects, such as files, and information on whether the event corresponded to a successful operation. trail: An audit trail, or log file, consists of a series of audit records describing security events. Typically, trails are in roughly chronological order with respect to the time events completed. Only authorized processes are allowed to commit records to the audit trail. prefix: A prefix is considered to be the configuration element used to toggle auditing for success and failed events. Installing Audit Support Support for Event Auditing is installed with the normal installworld process. An administrator may confirm this by viewing the contents of /etc/security. Files beginning with the word audit should be present. For example, audit_event. In-kernel support for the framework must also exist. This may be done by adding the following lines to the local kernel configuration file: options AUDIT Rebuild and reinstall the kernel via the normal process explained in . Once completed, enable the audit daemon by adding the following line to &man.rc.conf.5;: auditd_enable="YES" Functionality not provided by the default may be added here with the option. Audit Configuration By default, all configuration is done within the realm of /etc/security and the files contained within. The following files must be present before the audit daemon is started: audit_class - Contains the definitions of the audit classes. audit_control - Controls aspects of the audit subsystem, such as default audit classes, minimum disk space to leave on the audit log volume, etc. audit_event - Defines the kernel audit events. These map, mostly, to system calls. audit_user - The events to audit for individual users. Users not appearing here will be subject to the default configuration in the control configuration file. audit_warn - A shell script used by auditd to generate warning messages in exceptional situations, such as when space for audit records is running low. Audit File Syntax The configuration file syntax is rather arcane, albeit easy to work with. One thing an administrator must be leery about is overriding system defaults. This could create potential openings for audit data to not be collected properly. The audit subsystem will accept both the short name and long name with regards to configuration syntax. A syntax map has been included below. The following list contains all supported audit classes: - all - All audit flags set. - administrative - Administrative actions performed on the system as a whole. - application - Application defined action. - file_close - Audit calls to the close system call. - exec - Audit program or utility execution. - file_attr_acc - Audit the access of object attributes such as &man.stat.1;, &man.pathconf.2; and similar events. - file_creation - Audit events where a file is created as a result. - file_deletion - Audit events where file deletion occurs. - file_attr_mod - Audit events where file attribute modification occurs, such as &man.chown.8;, &man.chflags.1;, &man.flock.2;, etc. - file_read - Audit events in which data is read, files are opened for reading, etc. - file_write - Audit events in which data is written, files are written or modified, etc. - ioctl - Audit use of the &man.ioctl.2; system call. - ipc - Audit System V IPC operations. - login_logout - Audit &man.login.1; and &man.logout.1; events occurring on the system. - non_attrib - Audit non-attributable events. - no_class - Null class used to disable event auditing. - network - Audit events related to network actions, such as &man.connect.2; and &man.accept.2;. - other - Audit miscellaneous events. - process - Audit process operations, such as &man.exec.3; and &man.exit.3;. Following is a list of all supported audit prefixes: none - Audit both the success or failure of an event. For example, just listing a class will result in the auditing of both success and failure. + - Audit successful events only. - - Audit failed events only. Using the class with either the positive or negative prefix can generate a large amount of data at an extremely rapid rate. Extra prefixes used to modify the default configuration values: ^- - Disable auditing of failed events. ^+ - Enable auditing of successful events. ^ - Disable auditing of both successful and failed events. Configuration Files Configuration is set in only two files, the first being audit_control and audit_user being the second. The first is system-wide, controlling every aspect of event auditing in the system. The latter may be used for fine grained user auditing. The <filename>audit_control</filename> File The audit_control file contains some basic defaults that the administrator may wish to modify. Perhaps even set some new ones. Viewing the contents of this file, we see the following: dir:/var/audit flags:lo minfree:20 naflags:lo The option is used to set the default directory where audit logs are stored. Audit is frequently configured so that audit logs are stored on a dedicated file system, so as to prevent interference between the audit subsystem and other subsystems when file systems become full. The option is used to set the system-wide defaults. The current setting, configures the auditing of all &man.login.1; and &man.logout.1; actions. A more complex example, audits all system &man.login.1; and &man.logout.1; actions, all administrator actions, all failed events in the system, and finally disables auditing of failed attempts for , , and . Even though the turned on the auditing of all failed attempts, the prefix will override that for the latter options. Notice that the previous paragraph shows the file is read from left to right. As such, values further on the right side may override a previous value specified to its left. The option defines the minimum percentage of free space for audit file systems. This relates to the file system where audit logs are stored. For example, if the specifies /var/audit and is set to twenty (20), warning messages will be generated when the /var file system grows to eighty (80) percent full. The option specifies audit classes to be audited for non-attributed events — that is, events for which there is no authenticated user. The <filename>audit_user</filename> File The audit_user file permits the administrator to determine which classes of audit events should be logged for which system users. The following is the defaults currently placed in the audit_user file: root:lo:no audit:fc:no Notice how the default is to audit all cases of login/logout and disable auditing of all other actions for root. This configuration also audits all file creation and disables all other auditing for the audit user. While event auditing does not require a special user exist, some configurations, specifically environments making use of MAC, may require it. Event Audit Administration Events written by the kernel audit subsystem cannot be altered or read in plain text. Data is stored and accessed in a method similar to that of &man.ktrace.1; and &man.kdump.1;, that is, they may only be viewed by dumping them using the praudit command; audit trails may be reduced using the auditreduce command, which selects records from an audit trail based on properties of interest, such as the user, time of the event, and type of operation. For example, the praudit utility will dump the entire contents of a specified audit log in plain text. To dump an audit log in its entirety, use: &prompt.root; praudit /var/audit/AUDITFILE Where AUDITFILE is the audit log of viewing choice. Since audit logs may contain enormous amounts of data, an administrator may prefer to select records for specific users. This is made possible with the following command, where trhodes is the user of choice: &prompt.root; auditreduce -e trhodes /var/audit/AUDITFILE | praudit This will select all audit records produced by the user trhodes stored in the AUDITFILE file. There are several other options available for reading audit records, see the aforementioned command's manual pages for a more in depth explanation. Rotating Audit Log Files Because of log reliability requirements, audit trails are written to only by the kernel, and managed only by auditd. Administrators should not attempt to use &man.newsyslog.conf.5; or other tools to directly rotate audit logs. Instead, the audit management tool should 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. &prompt.root; audit -n If the auditd daemon is not currently running, the previous command will fail and an error message will be produced. Adding the following line to /etc/crontab will force the rotation every twelve hours from &man.cron.8;: * */12 * * * root /usr/sbin/audit -n The change will take effect once you have saved the new /etc/crontab.