Chapter 4 Troubleshooting Auditing

Another auditing task is to handle audit anomalies as they occur. Typical tasks that audit analysts and system administrators face are discussed below.

• "Preventing Audit Trail Overflow"

• "Cleaning up an Open Audit File"

• "Using the sequence Token for Debugging"

• "Starting the Audit Daemon Manually"

• "Workstations are Being Audited Differently"

• "Finding Failed Login Attempts"

Preventing Audit Trail Overflow

When all audit file systems for a workstation fill up, the audit_warn script sends a message to the console that the hard limit has been exceeded on all audit file systems and also sends mail to the alias. By default, the audit daemon remains in a loop sleeping and checking for space until some space is freed. All auditable actions are suspended. The audit policy ahlt is in effect.

Site security policy may allow a different solution. There are other candidates: preventing overflow and keeping a count of dropped audit records.

If your security policy requires that overflow be prevented so that no audit data is ever lost, see "To Prevent Audit Trail Overflow by Planning Ahead".

---

Note -

The audit system can be configured to discard audit records upon overflow of the kernel audit buffer. Such a configuration does not constitute an evaluated configuration of the system, and the system should be configured to suspend upon overflow of the audit buffer.

---

If your security policy permits the loss of some audit data rather than suspending system activities due to audit trail overflow. In that case, you can set the auditconfig policy to drop or count records. See "To Handle an Audit Filesystem Overflow" for how to drop or count records.

If your security policy requires you to handle filesystem overflow by halting the affected workstation, you must enter the workstation in single-user mode. This is not a secure practice. See "To Handle an Audit Filesystem Overflow" for the procedure.

To Prevent Audit Trail Overflow by Planning Ahead

If your security policy requires that all audit data be saved, do the following:

1. Set up a schedule to regularly archive audit files and to delete the archived audit files from all audit file systems.

   The schedule must allow files to be deleted from the system before the hard limit of the system is reached. Scripts, including modified audit_warn scripts, can automatically move audit files to a separate disk before archiving.

2. Manually archive audit files by backing them up on tape or moving them to an archive file system.

3. Store context-sensitive information that will be needed to interpret audit records along with the audit trail.

   For example, the current list of users and passwords, the directory listings on the workstations, and other volatile information should be saved.

4. Keep records of what audit files are moved off line.

5. Store the archived tapes appropriately.

6. Reduce the volume of audit data you store by creating summary files.

   You can extract summary files from the audit trail using options to auditreduce, so that the summary files contain only records for certain specified types of audit events. An example of this would be a summary file containing only the audit records for all logins and logouts. See "The Audit Trail".

To Handle an Audit Filesystem Overflow

To set the audit policy that a count of audit records is kept when the audit file systems are full, as role secadmin, at label admin_low:

$ auditconfig -setpolicy +cnt

---

Caution -

To run auditing in an evaluated configuration, you cannot have the +cnt policy turned on. It must be turned off.

---

To set the audit policy that the workstation is shut down when its audit file systems are full:

$ auditconfig -setpolicy +ahlt

To set one of the above policies permanently, enter the command in the audit_startup(1M) script. See "To Set Audit Policy Permanently" for how to edit the script.

---

Note -

On a distributed system, the same audit policy should be applied to all workstations.

---

Cleaning up an Open Audit File

Occasionally, if an audit daemon dies while its audit file is still open, or a server becomes inaccessible and forces the workstation to switch to a new server, an audit file remains in which the end-time in the file name remains the string not_terminated, even though the file is no longer used for audit records.

The auditreduce(1M) command processes files marked not_terminated, but because such files may contain incomplete records at the end, future processing may generate errors. To avoid errors, clean the incomplete file with the -O option of auditreduce. This creates a new file containing all the records that were in the old one, but with a proper file name time stamp. This operation loses the previous file pointer that's kept at the beginning of each audit file.

To Clean Up an Open Audit File

1. As role admin, at label admin_high check the /etc/security/audit_data file to determine the current process number of the audit daemon.

   If that process is still running, and if the file name in audit_data(4) is the same as the file in question, do not clean the file.

2. Issue the command auditreduce with the -O (capital o) option.

3. Provide the workstation name as the argument to -O, and the incomplete file name. To delete the original record, use the -D option.

   $ auditreduce -O workstation 19970413120429.not_terminated.workstation

   This creates a new audit file with the correct name, cleans up pointers to other files, and copies all the records to the new file. The end-time is the time when the command was executed; the correct suffix is workstation, explicitly specified.

4. If you did not use the -D option, verify that the new file contains the original file's records, then delete the original file.

   $ ls -l 19970413120429*.workstation $ rm 19970413120429.not_terminated*

Using the sequence Token for Debugging

When an audit trail created from merging records from several workstations appears to have the records listed out of order, you can debug the audit trail discrepancies using the sequence token. Since the sequence token is not recorded by default, the security administrator adds it to the audit policy. The audit policy must be set identically on all workstations contributing to the audit trail.

When the audit trail has been debugged, the security administrator removes the token.

To Add the sequence Token to the Audit Record

1. To add the seq audit policy dynamically, as role secadmin, at label admin_low, on the command line:

   $ auditconfig -setpolicy +seq $ auditconfig -getpolicy slabel, seq

2. To add the seq audit policy permanently, as role secadmin at label admin_low, in the audit_startup file:

   ---

      #!/bin/sh
   auditconfig -setpolicy +slabel,seq

   ---

To Prevent the sequence Token from Being Part of Audit Records

1. To remove the seq audit policy dynamically, on the command line, as role secadmin at label admin_low:

   $ auditconfig -setpolicy -seq $ auditconfig -getpolicy slabel

2. To remove the seq audit policy from the audit_startup file, as role secadmin at label admin_low:

   ---

      #!/bin/sh
   auditconfig -setpolicy +slabel

   ---

Starting the Audit Daemon Manually

On a distributed system, if many workstations have lost their audit daemon, bring up the audit daemons in order.

As role secadmin, execute the command /usr/sbin/auditd in an admin_high shell on the audit administration server, then on the audit servers, and finally on the audit clients.

$ /usr/sbin/auditd

If you are unfamiliar with creating an admin_high shell, see "To Create an Admin_High Workspace".

Workstations are Being Audited Differently

If you change audit configuration files on one workstation and fail to copy the files to the other workstations on the network, the workstations will be audited differently. Therefore,

1. As role secadmin, at label admin_low, copy the audit configuration files from a central location to every workstation.

   Follow the procedure in "To Distribute Audit Configuration Files".

2. Check that the audit class mappings for attributable and nonattributable events match the kernel cache.

To Set Audit Class Mappings for Attributable Events

1. First, as role secadmin at label admin_low, check to see if the kernel preselection mask matches the class mappings in the flags: field of the audit_control(4) file by issuing the command:

   $ auditconfig -chkconf

2. If the runtime class mappings differ from the kernel cache, issue the command:

   $ auditconfig -conf

To Set Audit Class Mappings for Non-Attributable Audit Events

1. First, as role secadmin at label admin_low, check to see if the kernel preselection mask matches the nonattributable events in the naflags: field of the audit_control(4) file by issuing the command:

   $ auditconfig -getkmask

2. If they differ, issue the command:

   $ auditconfig -setkmaskac

Finding Failed Login Attempts

As role admin at label admin_high, enter -lo as the value of the -c option to auditreduce(1M).

$ auditreduce -c -lo -O /usr/audit_summary/logins_failed

The value "-lo" is the audit flag for failed (-) login (audit class lo) attempts. The command produces a binary file in the /usr/audit_summary directory with all failed login attempts on the distributed system. The /usr/audit_summary directory is labeled admin_high.

---

/usr/audit_summary/19970313120429.19970613120415.logins_failed

---

---

Note -

This command works only if the security administrator has preselected failed logins for the workstation, distributed system, or users.

---