[ Bottom of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]

Security Guide

Setting Up Auditing

The following procedure is an overview of the steps you must take to set up an auditing subsystem. For more specific information, refer to the configuration files noted in these steps.

  1. Select system activities (events) to audit from the list in the /etc/security/audit/events file. If you have added new audit events to applications or kernel extensions, you need to edit the file to add the new events.
  2. Group your selected audit events into sets of similar items called audit classes. Define these audit classes in the classes stanza of the /etc/security/audit/config file.
  3. Assign the audit classes to the individual users and assign audit events to the files (objects) that you want to audit, as follows:
  4. In the /etc/security/audit/config file, configure the type of data collection that you want using BIN collection, STREAM collection, or both methods. Make sure that audit data does not compete with other data about file space by using a separate file system for audit data. This ensures that there is enough space for the audit data. Configure the type of data collection as follows:
  5. When you have finished making any necessary changes to the configuration files, you are ready to use the audit start command to enable the audit subsystem.
  6. Use the audit query command to see which events and objects are audited.
  7. Use the audit shutdown command to deactivate the audit subsystem again.

Selecting Audit Events

The purpose of an audit is to detect activities that might compromise the security of your system. When performed by an unauthorized user, the following activities violate system security and are candidates for an audit:

The audit system does not have a default set of events to be audited. You have to select events or event classes according to your needs.

To audit an activity, you must identify the command or process that initiates the audit event and ensure that the event is listed in the /etc/security/audit/events file for your system. Then you must add the event either to an appropriate class in the /etc/security/audit/config file, or to an object stanza in the /etc/security/audit/objects file. See the /etc/security/audit/events file on your system for the list of audit events and trail formatting instructions. For a description of how audit event formats are written and used, see the auditpr command.

After you have selected the events to audit, you must combine similar events into audit classes. Audit classes are then assigned to users.

Selecting Audit Classes

You can facilitate the assignment of audit events to users by combining similar events into audit classes. These audit classes are defined in the classes stanza of the /etc/security/audit/config file.

Some typical audit classes might be as follows:

general Events that alter the state of the system and change user authentication. Audit attempts to circumvent system access controls.
objects Write access to security configuration files.
kernel Events in the kernel class are generated by the process management functions of the kernel.

An example of a stanza in the /etc/security/audit/config file is as follows:

    general = USER_SU,PASSWORD_Change,FILE_Unlink,FILE_Link,FILE_Rename
    system = USER_Change,GROUP_Change,USER_Create,GROUP_Create
    init = USER_Login,USER_Logout

Selecting an Audit Data-Collection Method

Your selection of a data-collection method depends on how you intend to use the audit data. If you need long-term storage of a large amount of data, select BIN collection. If you want to process the data as it is collected, select STREAM collection. If you need both long-term storage and immediate processing, select both methods.

Bin collection Allows storage of a large audit trail for a long time. Audit records are written to a file that serves as a temporary bin. After the file is filled, the data is processed by the auditbin daemon while the audit subsystem writes to the other bin file, and records are written to an audit trail file for storage.
Stream collection Allows processing of audit data as it is collected. Audit records are written into a circular buffer within the kernel, and are retrieved by reading /dev/audit. The audit records can be displayed, printed to provide a paper audit trail, or converted into bin records by the auditcat command.

Example of Real-Time File Modification Monitoring

The following example can be used to monitor file access to critical files in real time:

  1. Set up a list of critical files to be monitored for changes, for example all files in /etc and configure them for FILE_Write events in the objects file:
    find /etc -type f | awk '{printf("%s:\n\tw = FILE_Write\n\n",$1)}' >> /etc/security/audit/objects
  2. Set up stream auditing to list all file writes. (This example lists all file writes to the console, but in a production environment you might want to have a backend that sends the events into an Intrusion Detection System.) The /etc/security/audit/streamcmds file is similar to the following:
    /usr/sbin/auditstream | /usr/sbin/auditselect -e "event == FILE_Write" |
    auditpr  -hhelpPRtTc -v > /dev/console &
  3. Set up STREAM mode auditing in /etc/security/audit/config, add a class for the file write events and configure all users that should be audited with that class:
            binmode = off
            streammode = on
            cmds = /etc/security/audit/streamcmds
            filemon = FILE_write
            root = filemon
            afx = filemon
  4. Now run audit start. All FILE_Write events are displayed on the console.

Example of a Generic Audit Log Scenario

In this example, assume that a system administrator wants to use the audit subsystem to monitor a large multi-user server system. No direct integration into an IDS is performed, all audit records will be inspected manually for irregularities. Only a few essential audit events are recorded, to keep the amount of generated data to a manageable size.

The audit events that are considered for event detection are the following:

FILE_Write We want to know about file writes to configuraion files, so this event will be used with all files in the /etc tree.
PROC_SetUserIDs All changes of user ids
AUD_Bin_Def Audit bin configuration
USER_SU The su command
PASSWORD_Change passwd command
AUD_Lost_Rec Notification in case there where lost records
CRON_JobAdd new cron jobs
AT_JobAdd new at jobs
USER_Login All logins
PORT_Locked All locks on terminals because of too many invalid attempts

The following is an example of how to generate a generic audit log:

  1. Set up a list of critical files to be monitored for changes, such as, all files in /etc and configure them for FILE_Write events in the objectsfile as follows:
    find /etc -type f | awk '{printf("%s:\n\tw = FILE_Write\n\n",$1)}' >> /etc/security/audit/objects
  2. Use the auditcat command to set up BIN mode auditing. The /etc/security/audit/bincmds file is similar to the following:
    /usr/sbin/auditcat -p -o $trail $bin
  3. Edit the /etc/security/audit/config file and add a class for the events we have interest. List all existing users and specify the custom class for them.
            binmode = on
            streammode = off
            cmds = /etc/security/audit/bincmds
            trail = /audit/trail
            bin1 = /audit/bin1
            bin2 = /audit/bin2
            binsize = 100000
            freespace = 100000
            custom = FILE_Write,PROC_SetUser,AUD_Bin_Def,AUD_Lost_Rec,USER_SU, \
            root = custom
            afx = custom
  4. Add the custom audit class to the /usr/lib/security/mkuser.default file, so that new IDs will automatically have the right audit call associated:
        auditclasses = custom
        pgrp = staff
        groups = staff
        shell = /usr/bin/ksh
        home = /home/$USER
  5. Create a new file system named /audit using SMIT or the crfs command. It should be large enough to hold the two bins and a large audit trail.
  6. Now run audit startand look at /audit: You should see the two bin files and an empty trail file initially. After you have used the system for a while, you should have audit records in the trail file which can be read with
    auditpr  -hhelpPRtTc -v | more

This example uses only a few events. To see all events, you could specify the classname ALL for all users. Ths will generate large amounts of data. You might want to add all events related to user changes and pivilege changes to your custom class.

[ Top of Page | Previous Page | Next Page | Contents | Index | Library Home | Legal | Search ]