test

SunSHIELD Basic Security Module Guide

Learning About the Audit Trail

This section describes where audit files are stored, how they are named, and how to manage audit file storage throughout a distributed system.

The audit trail is created when the audit daemon, auditd, is started, and is closed when a new audit trail file is created, or when the audit daemon is terminated. The audit trail may consist of audit files in several audit directories, or an audit directory may contain several audit trails.

Most often the audit directories will be separate audit file system partitions. Even though they can be included in other file systems, this is not recommended.

As a rule, locate primary audit directories in dedicated audit file systems mounted on separate partitions. Normally, all audit file systems are subdirectories of /etc/security/audit. These should be dedicated audit file systems to ensure that normal use of the partition is not interrupted, if the audit directories become filled with audit files.

Even though you can physically locate audit directories within other file systems that are not dedicated to auditing, do not do this except for directories of last resort. Directories of last resort are directories where audit files are written only when there is no other suitable directory available. One other scenario where locating audit directories outside of dedicated audit file systems could be acceptable is in a software development environment where auditing is optional, and where it is more important to make full use of disk space than to keep an audit trail. Putting audit directories within other file systems would never be acceptable in a security-conscious production environment.

A diskfull machine should have at least one local audit directory, which it can use as a directory of last resort, if unable to communicate with the audit server.

Mount audit directories with the read-write (rw) option. When mounting audit directories remotely (using NFS software), also use the intr option.

List the audit file systems on the audit server where they reside. The export list should include all machines in the configuration.

More About the Audit Files

Each audit file is a self-contained collection of records; the file's name identifies the time span during which the records were generated and the machine that generated them.

Audit File Naming

Audit files that are complete have names of the following form: 


start-time.finish-time.machine

where start-time is the time of the first audit record in the audit file, finish-time is the time of the last record, and machine is the name of the machine that generated the file. An example of these names can be found in "Example of a Closed Audit File Name".

If the audit log file is still active, it has a name of the following form: 


start-time.not_terminated.machine

How Audit File Names Are Used

The file name time stamps are used by auditreduce to locate files containing records for the specific time range that has been requested; this is important because there may be a month's supply or more of audit files on line, and searching them all for records generated in the last 24 hours would be unacceptably expensive.

Time-Stamp Format and Interpretation

The start-time and end-time are time stamps with one-second resolution; they are specified in Greenwich mean time. The format is four digits for the year, followed by two for each month, day, hour, minute, and second, as shown below. 


YYYYMMDDHHMMSS

The time stamps are in GMT to ensure that they will sort in proper order even across a daylight savings time boundary. Because they are in GMT, the date and hour must be translated to the current time zone to be meaningful; beware of this whenever manipulating these files with standard file commands rather than with auditreduce.

Example of a File Name for a Still-Active File

The format of a file name of a still-active file is shown below: 


YYYYMMDDHHMMSS.not_terminated.hostname

Here is an example: 


19900327225243.not_terminated.lazy

The audit log files are named by the beginning date, so the example above was started in 1990, on March 27, at 10:52:43 p.m, GMT. The not_terminated in the file name means either that the file is still active or that auditd was unexpectedly interrupted. The name lazy at the end is the host name whose audit data is being collected.

Example of a Closed Audit File Name

The format of the name of a closed audit log file is shown below: 


YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname

Here is an example: 


19900320005243.19900327225351.lazy

The example above was started in 1990, on March 20, at 12:52:43 a.m., GMT. The file was closed March 27, at 10:53:51 p.m., GMT. The name lazy at the end is the host name of the machine whose audit data is being collected.

Whenever auditd is unexpectedly interrupted, the audit file open at the time gets the not_terminated end file name time stamp. Also, when a machine is writing to a remotely mounted audit file and the file server crashes or becomes inaccessible, the not_terminated end time stamp remains in the current file's name. The audit daemon opens a new audit file and keeps the old name intact.

Handling Nonactive Files Marked not_terminated

The auditreduce 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 files of any incomplete records. Before cleaning the files, make sure that auditd is not currently writing to the files you want to clean. To check, look at the audit_data file to determine the current process number of auditd. If that process is still running, and if the file name in audit_data is the same as the file in question, do not clean the file.

You can clean a 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.

Or you can write a program to read through the file, locate the last record, rename the file, and clear out any incomplete records. A program can also keep the previous file pointer intact and determine which file to use next.

How to Create Audit Partitions and Export Them

  1. Assign at least one primary audit directory to each machine.

    The primary audit directory is the directory where a machine places its audit files under normal conditions.

  2. Assign at least one secondary audit directory to each machine that is located on a different audit file server than the primary directory.

    The secondary audit directory is where a machine places audit files if the primary directory is full or inaccessible, because of network failure, NFS server crash, or some other reason.

  3. On every diskfull machine create a local audit directory of last resort (preferably a dedicated audit file system) that is used when the network is inaccessible or the primary and secondary directories are unusable.

  4. Spread the directories used as primary and secondary destinations evenly over the set of audit servers in the system.

  5. Create audit file systems according to the requirements discussed in this section.

    The /etc/security directory contains subdirectories with all the audit files and also contains several other files related to audit control. Because the /etc/security directory contains the per-machine audit_data file, which must be available for successful startup of the audit daemon at boot time, the /etc/security directory must be part of the root file system.

    The audit post-selection tools look in directories under /etc/security/audit by default. For this reason, the path name of the mount point for the first audit file system on an audit server is in the form: /etc/security/audit/server-name (where server-name is the name of the audit server). If more than one audit partition is on an audit server, the name of the second mount point is: /etc/security/audit/server-name.1, the third is /etc/security/audit/server-name.2, and so forth.

    For example, the names of the audit file systems available on the audit server winken are /etc/security/audit/winken and /etc/security/audit/winken.1.

    On the audit server, each audit file system must also have a subdirectory named files. This files subdirectory is where the audit files are located and where the auditreduce commands looks for them. For example, the audit file system on audit server winken should have a files subdirectory whose full path name is: /etc/security/audit/winken/files.

    You should make sure that the local audit_control file on each machine tells the audit daemon to put the audit files in the files subdirectory. Here is the dir: line for the audit_control file on a machine mounting the audit file system from eagle:

    dir: /etc/security/audit/eagle/files

    The extra level of hierarchy is required to prevent a machine's local root file system from filling with audit files when (for whatever reason) the /etc/security/audit/server-name[.suffix] directory is not available on the audit server. Because the files subdirectory is present on the audit server and there should be no files subdirectory on any of the clients, audit files cannot be created unintentionally in the local mount-point directory if the mount fails.

    Make sure that each audit directory contains nothing except audit files.

  6. Assign the required permissions to the audit file systems.

    The permissions that must appear on the /etc/security/audit/server-name directory and the files directory that must be created beneath it on the audit server are shown in Table 2-5.

    Table 2-5 Audit File Permissions

    Owner 

    Group 

    Permissions 

    root 

    staff 

    2750 

Example audit_control File Entries

When you add the dir: entries in the audit_control file, make sure the full path down to the files subdirectory is specified. The following example shows an audit_control file dir: entry for the server blinken, which will be storing its audit files on its own local disk. 


# cat /etc/security/audit_control
dir:/etc/security/audit/blinken.1/files
dir:/etc/security/audit/blinken.2/files

How to Configure Auditing

The following steps are included here to provide an overview of what is required to set up audit directories and specify which audit classes will be audited.

  1. Format and partition the disks to create the dedicated audit partitions.

    A rule of thumb is to assign 100 MBytes of space for each machine that will be on the distributed system; but remember that the disk space requirements at your site will be based on how much auditing you perform and may be far greater than this figure per machine.

  2. Assign the audit file systems to the dedicated partitions.

    Each diskfull machine should have a backup audit directory on the local machine in case its NFS-mounted audit file systems are not available.

  3. While each machine is in single-user mode, run tunefs -m 0 on each dedicated audit partition to reduce reserved file system space to 0 percent.

    A reserved space percentage (called the minfree limit) is specified for audit partitions in the audit_control file. The default is 20 percent, and this percentage is tunable. Because this value is set by each site in the audit_control file, you should remove the automatically reserved file system space that is set aside by default for all file systems.

  4. Set the required permissions on each of the audit directories on the audit servers, and make a subdirectory in each audit directory called files.

    Use chown and chmod to assign each audit directory and each files subdirectory the required permissions.

  5. If using audit servers, export the audit directories with the /etc/dfs/dfstab file.

  6. Create the audit_control file entries for all the audit directories in the audit_control file on each machine, specifying the files subdirectory.

  7. On each audit client, create the entries for the audit file systems in the /etc/vfstab file.

  8. On each audit client, create the mount point directories and use chmod and chown to set the correct permissions.

How to Plan Audit Configuration

First, plan for audit trail storage.

  1. In the /etc/security/audit_class file, define the classes needed at your site.

    If the default classes are suitable, you do not need to define new ones. See the audit_class(4) man page.

  2. Set up event-to-class mapping in /etc/security/audit_event.

    This step is not needed if the default mapping suits your site's needs. See the audit_event(4) man page.

  3. Determine how much auditing your site needs to do.

    Balance your site's security needs against the availability of disk space for audit trail storage.

    See "Controlling Audit Costs", "Auditing Efficiently", and "Learning About the Audit Trail" for guidance on how to reduce storage requirements while still maintaining site security as well as how to design audit storage.

  4. Determine which machines will be audit servers and which will be clients of the audit servers.

  5. Determine the names and locations of audit file systems.

  6. Plan which machines will use which audit file systems on the audit servers.

After dealing with storage, decide who and what to audit.

  1. Determine which audit classes you want to be audited system-wide and which flags to use to select the audit classes.

  2. Determine if some users will be audited more than others, then decide which flags to use to modify user's audit characteristics.

    See "Process Audit Characteristics".

  3. Determine the minimum free space (minfree), also called the soft limit, that should be on an audit file system before a warning is sent.

    When the amount of space available goes below the minfree percentage, the audit daemon switches to the next suitable audit file system and send a notice that the soft limit has been exceeded. (What makes an audit file system suitable is defined in "What Makes a Directory Suitable".)

    A certain amount of auditing is configured by default on each machine. The default audit_control file contains the lines shown in Table 2-6, which set the audit directory as /var/audit, one system-wide audit flag (lo), a minfree threshold of 20 percent, and one nonattributable flag.

    Table 2-6 audit_control File Entries
    dir:/var/audit
flags:lo
minfree:20
naflags:ad

  4. Edit the /etc/security/audit_control file.

    1. Specify which audit file systems to use for audit trail storage on this machine.

      Make a dir: entry for each audit directory available to the current machine. See "Learning About the Audit Trail" for how to set up the audit directory scheme for the distributed system.

    2. Specify the system-wide audit flags that will apply to all users' processes in the flags: field.

      The system-wide audit flags in the flags: field will apply to all users' processes, and you should set the flag the same on every machine.

    3. Change the minfree percentage, if desired, to reduce or enlarge the audit threshold.

    4. Specify the naflags: that will apply to events that cannot be attributed to a particular user.

  5. Use auditconfig to modify the audit policy if modification is desired.

    See the auditconfig(1M) man page or "The auditconfig Command". The policy variable is a dynamic kernel variable, so its value is not saved when the system is brought down. Therefore, you should set the desired policy using the appropriate startup script.

  6. Set the cnt policy or set up an audit administration account.

    In the event of an audit trail overflow, either the cnt policy must be enabled, which allows further system functioning, or an account must be available that can work without being audited. To set up such an account:

    1. In the /etc/passwd file, add the following entry.


      audit::0:1::/:/sbin/sh
      Note -

      This entry must be placed below the entry for the root user for processes owned by root to function properly.

    2. To add a corresponding entry into the /etc/shadow file, type the following.


      # pwconv
pwconv: WARNING user audit has no password

      The password for the audit account will be established in Step d.

    3. In the /etc/security/audit_user file, add the following entry to turn off auditing for the account.


      audit:no:all

    4. Set a password for the new account using passwd.


      # passwd audit

      Remember that actions taken through this account are not audited. To protect system integrity, choose a password that is not easily compromised. This example uses an account name of audit. Choose a name more appropriate for your site if you set up such an account.