diff --git a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml index 72e9edbc4a..14916991cf 100644 --- a/en_US.ISO8859-1/books/handbook/audit/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/audit/chapter.sgml @@ -1,530 +1,530 @@ Tom Rhodes Written by Kernel Event Auditing Synopsis AUDIT Kernel Event Auditing MAC The &os; 6.0 operating system release has included support for Event Auditing based on the &posix;.1e draft and the &sun; BSM implementation. Event auditing permits the selective logging of security-relevant system events for the purposes of system analysis, system monitoring, and security evaluation. 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 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. class: A class specifies the category different actions the system are placed in. For example, use of &man.login.1; could be placed in a class. event: An event could be considered an action taken on the system. Creating a file would be an event. record: A record is a log or a note about a specific action. 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 should have been 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. A user name does not need to appear in here. audit_warn - A shell script used by auditd to form warning messages. If these files do not exist, for whatever reason, they can be installed easily by issuing the following commands: &prompt.root; cd /usr/src/contrib/bsm/etc && make install 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;. - tfm - I HAVE NO CLUE! 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 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,ad,-all,^-fa,^-fc,^-cl minfree:20 naflags:lo The is used to set the default directory where audit logs are stored. The is used to set the system-wide defaults. The current setting, audits all system &man.login.1; and &man.logout.1; actions, all administrator actions, all failed events in the system, and finally disable 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 flags to be considered non attributable; i.e.: classes of events which cannot be attributed to a specific user on the system. This can be overridden with the audit_user configuration file. The <filename>audit_user</filename> File The audit_user permits the administrator to map audit specific events to directly to users. This adds a finer-grained control mechanism for all 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 from the auditd daemon 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 or auditreduce utilities. There are two utilities because of different requirements. For example, the praudit 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 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 Manually rotating audit log files will cause great havoc within the system. Therefore, adding a line to &man.newsyslog.conf.5; will provide no usefulness. So how are the logs to be rotated? Sending the appropriate flag to the audit utility will shut down event auditing and safely rotate. The following command should handle everything for an 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 - /etc/crontab. + new /etc/crontab.