Before you can actually start generating audit logs and process them, configure the audit daemon itself. Configure how it is started in the /etc/sysconfig/auditd configuration file and configure how the audit system functions once the daemon has been started in /etc/auditd.conf.
The most important configuration parameters in /etc/sysconfig/auditd are:
AUDITD_LANG="en_US" AUDITD_DISABLE_CONTEXTS="no"
The locale information used by audit. The default setting is en_US. Setting it to none would remove all locale information from audit's environment.
Disable system call auditing by default. Set to no for full audit functionality including file and directory watches and system call auditing.
The /etc/auditd.conf configuration file determines how the audit system functions once the daemon has been started. For most use cases, the default settings shipped with SUSE Linux Enterprise should suffice. For CAPP environments, most of these parameters need tweaking. The following list briefly introduces the parameters available:
log_file = /var/log/audit/audit.log log_format = RAW priority_boost = 3 flush = INCREMENTAL freq = 20 num_logs = 4 dispatcher = /usr/sbin/audispd disp_qos = lossy max_log_file = 5 max_log_file_action = ROTATE space_left = 75 space_left_action = SYSLOG action_mail_acct = root admin_space_left = 50 admin_space_left_action = SUSPEND disk_full_action = SUSPEND disk_error_action = SUSPEND
Depending on whether you want your environment to satisfy the
requirements of CAPP, you need to be extra restrictive when configuring the
audit daemon. Where you need to use particular settings to meet the CAPP
requirements, a CAPP Environment
note tells you how
to adjust the configuration.
log_file specifies the location where the audit logs should be stored. log_format determines how the audit information is written to disk. Possible values for log_format are raw (messages are stored just as the kernel sends them) or nolog (messages are discarded and not written to disk). The data sent to the audit dispatcher is not affected if you use the nolog mode. The default setting is raw and you should keep it if you want to be able to create reports and queries against the audit logs using the aureport and ausearch tools.
NOTE: CAPP Environment
In a CAPP environment, have the audit log reside on its own partition. By doing so, you can be sure that the space detection of the audit daemon is accurate and that you do not have other processes consuming this space.
Determine how much of a priority boost the audit daemon should get. Possible values are 0 to 3, with 3 assigning the highest priority. The values given here translate to negative nice values, as in 3 to -3 to increase the priority.
Specifies whether, how, and how often the audit logs should be written to disk. Valid values for flush are none, incremental, data, and sync. none tells the audit daemon not to make any special effort to write the audit data to disk. incremental tells the audit daemon to explicitly flush the data to disk. A frequency must be specified if incremental is used. A freq value of 20 tells the audit daemon to request the kernel to flush the data to disk after every 20 records. The data option keeps the data portion of the disk file in sync at all times while the sync option takes care of both metadata and data.
NOTE: CAPP Environment
In a CAPP environment, make sure that the audit trail is always fully up to date and complete. Therefore, use sync or data with the flush parameter.
Specify the number of log files to keep if you have given rotate as the max_log_file_action. Possible values range from 0 to 99. A value less than 2 means that the log files are not rotated at all. As you increase the number of files to rotate, you increase the amount of work required of the audit daemon. While doing this rotation, auditd cannot always service new data that is arriving from the kernel as quickly, which can result in a backlog condition (triggering auditd to react according to the failure flag, described in Section 1.3, Controlling the Audit System Using auditctl). In this situation, increasing the backlog limit is recommended. Do so by changing the value of the -b parameter in the /etc/audit.rules file.
The dispatcher is started by the audit daemon during its start. The audit daemon relays the audit messages to the application specified in dispatcher. This application must be a highly trusted one, because it needs to run as root. disp_qos determines whether you allow for lossy or lossless communication between the audit daemon and the dispatcher. If you choose lossy, the audit daemon might discard some audit messages when the message queue is full. These events still get written to disk if log_format is set to raw, but they might not get through to the dispatcher. If you choose lossless the audit logging to disk is blocked until there is an empty spot in the message queue. The default value is lossy.
max_log_file takes a numerical value that specifies the maximum file size in megabytes the log file can reach before a configurable action is triggered. The action to be taken is specified in max_log_file_action. Possible values for max_log_file_action are ignore, syslog, suspend, rotate, and keep_logs. ignore tells the audit daemon to do nothing once the size limit is reached, syslog tells it to issue a warning and send it to syslog, and suspend causes the audit daemon to stop writing logs to disk leaving the daemon itself still alive. rotate triggers log rotation using the num_logs setting. keep_logs also triggers log rotation, but does not use the num_log setting, so always keeps all logs.
NOTE: CAPP Environment
To keep a complete audit trail in CAPP environments, the keep_logs option should be used. If using a separate partition to hold your audit logs, adjust max_log_file and max_log_file_action to use the entire space available on that partition.
Specify an e-mail address or alias to which any alert messages should be sent. The default setting is root, but you can enter any local or remote account as long as e-mail and the network are properly configured on your system and /usr/lib/sendmail exists.
space_left takes a numerical value in megabytes of remaining disk space that triggers a configurable action by the audit daemon. The action is specified in space_left_action. Possible values for this parameter are ignore, syslog, email, suspend, single, and halt. ignore tells the audit daemon to ignore the warning and do nothing, syslog has it issue a warning to syslog, and email sends an e-mail to the account specified under action_mail_acct. suspend tells the audit daemon to stop writing to disk but remain alive while single triggers the system to be brought down to single user mode. halt triggers a full shutdown of the system.
NOTE: CAPP Environment
Make sure that space_left is set to a value that gives the administrator enough time to react to the alert and allows him to free enough disk space for the audit daemon to continue to work. Freeing disk space would involve calling aureport -t and archiving the oldest logs on a separate archiving partition or resource. The actual value for space_left depends on the size of your deployment. Set space_left_action to email.
admin_space_left takes a numerical value in megabytes of remaining disk space. The system is already running low on disk space when this limit is reached and the administrator has one last chance to react to this alert and free disk space for the audit logs. The value of admin_space_left should be lower than the value for space_left. The values for admin_space_left_action are the same as for space_left_action.
NOTE: CAPP Environment
Set admin_space_left to a value that would just allow the administrator's actions to be recorded. The action should be set to single or halt.
Specify which action to take when the system runs out of disk space for the audit logs. The possible values are the same as for space_left_action.
NOTE: CAPP Environment
As the disk_full_action is triggered when there is absolutely no more room for any audit logs, you should bring the system down to single-user mode (single) or shut it down completely (halt).
Specify which action to take when the audit daemon encounters any kind of disk error while writing the logs to disk or rotating the logs. The possible value are the same as for space_left_action.
NOTE: CAPP Environment
Use syslog, single, or halt depending on your site's policies regarding the handling of any kind of hardware failure.
Once the daemon configuration in /etc/sysconfig/auditd and /etc/auditd.conf is complete, the next step is to focus on controlling the amount of auditing the daemon does and to assign sufficient resources and limits to the daemon so it can operate smoothly.