diff --git a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml index 7058be81ba..352762865d 100644 --- a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml @@ -1,570 +1,580 @@ Tom Rhodes Written by + + Robert + Watson + Security Event Auditing Synopsis AUDIT Security Event Auditing MAC - The &os; 7-CURRENT development branch includes - support for Event Auditing implementing 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. - + FreeBSD 6.2-RELEASE and later include support for fine-grained + security event auditing. Event auditing allows the reliable, + fine-grained, and configurable logging of a variety of + security-relevant system events, including logins, configuration + changes, and file and network access. These log records can be + invaluable for live system monitoring, intrusion detection, and + postmortem analysis. &os; implements Sun's published + BSM API and file format, and is interoperable with + both Sun's Solaris and Apple's Mac OS X audit implementations. - 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. + This chapter focuses on the installation and configuration of + Event Auditing. It explains audit policies, and provides an example + audit configuration. 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. + + + How to review the audit trail using the audit reduction and + review tools. 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 audit facility in &os; 6.2 is considered experimental, and + production deployment should occur only after careful consideration + of the risks of deploying experimental software. + + + + The security event auditing facility is able to generate very + detailed logs of system activity: on a busy system, trail file + data can be very large when configured for high detail, exceeding + gigabytes a week in some configurations. Administrators should take + into account disk space requirements associated with high volume + audit configurations. For example, it may be desirable to dedicate + a file system to the /var/audit tree so that + other file systems are not affected if the audit file system becomes + full. - 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. + Before reading this chapter, a few key audit-related terms must be + explained: - event: An auditable event is - an event that can be logged using the audit subsystem. The - administrator can configure which events will be audited. + event: An auditable event is any event + that can be logged using the audit subsystem. 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. + meaning that they can be traced to an authenticated user, or + non-attributable if they cannot be. + Examples of non-attributable events are any events that occur + before authentication in the login process, such as bad password + 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. + class: Event classes are named sets of + related events, and are used in selection expressions. Commonly + used classes of events include file creation (fc), + exec (ex) and login_logout + (lo). - 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. + record: A record is an audit log entry + describing a security event. Records contain a record event type, + information on the subject (user) performing the action, + date and time information, information on any objects or + arguments, and a success or failure condition. 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. + selection expression: A selection + expression is a string containing a list of prefixes and audit + event class names used to match events. + + + + preselection: The process by which the + system identifies which events are of interest in order to avoid + generating audit records describing events that are not of + interest to the administrator. The preselection configuration + uses a series of selection expressions to identify which classes + of events to audit for which users, as well as global settings + that apply to both authenticated and unauthenticated + processes. + + + + reduction: The process by which records + from existing audit trails are selected for preservation, printing, + or analysis. Likewise, the process by which undesired audit + records are removed from the audit trail. Using reduction, + administrators can implement policies for the preservation of audit + data. For example, detailed audit trails might be kept for one + month, but after that, trails might be reduced in order to preserve + only login information for archival purposes. 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: + User space support for Event Auditing is installed as part of the + base &os; operating as of 6.2-RELEASE. However, kernel support for + Event Auditing must also be configured, which is done by adding the + following lines to the local 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;: + Once the kernel is built, installed, and the system has been + rebooted, 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 support must then be started by a reboot, or by manually + starting the audit daemon: + + /etc/rc.d/auditd start Audit Configuration All configuration files for security audit are found in /etc/security. 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_event - Textual names and + descriptions of system audit events, as well as a list of which + classes each event in in. - 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_user - Any user-specific audit + requirements, which are combined with the global defaults at + login. - 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_warn - A customizable shell script + used by auditd to generate warning messages in exceptional + situations, such as when space for audit records is running low or + when the audit trail file has been rotated. - - 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. + + Audit configuration files should be edited and maintained + carefully, as errors in configuration may result in improper + logging of events. + - The following list contains all supported audit - classes: + + Event Selection Expressions + + 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 on onto the other. For example, per-user + expressions are appended to global expressions to generate the + effective preselection mask for a user at login. + + The following list contains the default audit event classes + present in audit_class: - - all - All - audit flags set. + - all - Match all + event classes. - 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 various forms of Inter-Process Communication, including POSIX pipes and 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. + Match no audit events. - 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: + 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. - 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. + (none) Audit both successful and failed instances of the + event. - + - Audit successful events - only. + + Audit successful events in this + class. - - - Audit failed events - only. + - Audit failed events in this + class. - - - - 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. + ^ Audit neither successful nor failed + events in this class. - ^+ - Enable auditing of successful events. + ^+ Don't audit successful events in this + class. - ^ - Disable auditing of both successful and failed - events. + ^- Don't audit failed events in this + class. + + + The following example selection string selects both successful + and failed login/logout events, but only successful execution + events: + + lo,+ex + Configuration Files 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 paramaters and defaults for both attributable and - non-attributable events. The second may be used to tune the level - and nature of auditing for individual users. + audit properties and policies; the second may be used to fine-tune + auditing by user. 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: + The audit_control file specifies a number + of defaults for the audit subsystem. 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 one or more + directories where audit logs will be stored. If more than one + directory entry appears, they will be used in order as they fill. + It is common to configure audit so that audit logs are stored on + a dedicated file system, in order to prevent interference between + the audit subsystem and other subsystems if the file system fills. - 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 field sets the system-wide default + preselection mask for attributable events. In the example above, + successful and failed login and logout events are audited for all + users. 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. - + percentage of free space for the file system where the audit trail + is stored. When this threshold is exceeded, a warning will be + generated. The above example sets the minimum free space to + twenty percent. + + The option specifies audit classes to + be audited for non-attributed events, such as the login process + and system daemons. 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. + administrator to specify further audit requirements for specific + users. + There is one line per user, along with a selection expression + which will be combined with the global . + + + The following example audit_user file + audits login/logout events and successful command execution for + the root user, and audits file creation and successful command + execution for the www user. + If used with the example audit_control file + above, the lo entry for root is redundant, + and login/logout events will also be audited for the www user. + + + root:lo,+ex:no +www:fc,+ex:no + - Event Audit Administration + Administering the Audit Subsystem - 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. + + Viewing and Reducing Audit Trails - 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: + 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. - &prompt.root; praudit /var/audit/AUDITFILE + For example, the praudit utility will dump + the entire contents of a specified audit log in plain text: - 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; praudit /var/audit/AUDITFILE - &prompt.root; auditreduce -e trhodes /var/audit/AUDITFILE | praudit + Where AUDITFILE is the audit log to + dump. 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 by the user - trhodes stored in the - AUDITFILE file. + &prompt.root; auditreduce -u trhodes /var/audit/AUDITFILE | praudit - There are several other options available for reading audit - records, see the aforementioned command's manual pages for - a more in depth explanation. + This will select all audit records produced for the user + trhodes stored in the + AUDITFILE file. + - Rotating Audit Log Files + Rotating Audit Trail Files - Due to 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 + Audit trails are written to only by the kernel, and managed only + by the audit daemon, 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. + 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. &prompt.root; audit -n If the auditd daemon is not currently - running, the previous command will fail and an error message - will be produced. + running, this 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. Delegating Audit Review Rights - By default, only the root user has the right to read system audit - logs. However, that right may be delegated to members of the - audit group, as the audit directory and audit - trail files are assigned to that group, and made group-readable. As + 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.