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.

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.
- You add an event to this file if you have included code to log that event in an application program (using the auditwrite or auditlog subroutine) or in a kernel extension (using the audit_svcstart, audit_svcbcopy, and audit_svcfinis kernel services).
- Ensure that formatting instructions for any new audit events are included in the /etc/security/audit/events file. These specifications enable the auditpr command to write an audit trail when it formats audit records.
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.
Assign the audit classes to the individual users and assign audit events to the files (objects) that you want to audit, as follows:
- To assign audit classes to an individual user, add a line to the users stanza of the /etc/security/audit/config file. To assign audit classes to a user, you can use the chuser command.
- To assign audit events to an object (data or executable file), add a stanza for that file to the /etc/security/audit/objects file.
- You can also specify default audit classes for new users by editing /usr/lib/security/mkuser.default. This file holds user attributes that will be used when generating new user IDs. For example, use the general audit class for all new user IDs, as follows:
```
user:
    auditclasses = general
    pgrp = staff
    groups = staff
    shell = /usr/bin/ksh
    home = /home/$USER
```
  To get all audit events, specify the ALL class. When doing so on even a moderately busy systrem, a huge amount of data will be generated. It is typically more practical to limit the number of events that are recorded.
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:
- To configure BIN collection:
  1. Enable the BIN mode collection by setting binmode = on in the start stanza.
  2. Edit the binmode stanza to configure the bins and trail, and specify the path of the file containing the binmode back-end processing commands. The default file for back-end commands is the /etc/security/audit/bincmds file.
  3. Make sure that the audit bins are large enough for your needs and set the freespace parameter accordingly to get an alert if the file system is filling up.
  4. Include the shell commands that process the audit bins in an audit pipe in the /etc/security/audit/bincmds file.
- To configure STREAM collection
  1. Enable the STREAM mode collection by setting streammode = on in the start stanza.
  2. Edit the streammode stanza to specify the path to the file containing the streammode processing commands. The default file containing this information is the /etc/security/audit/streamcmds file.
  3. Include the shell commands that process the stream records in an audit pipe in the /etc/security/audit/streamcmds file.
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.
Use the audit query command to see which events and objects are audited.
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:

Engaging in activities in the Trusted Computing Base
Authenticating users
Accessing the system
Changing the configuration of the system
Circumventing the auditing system
Initializing the system
Installing programs
Modifying accounts
Transferring information into or out of the system

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:

classes:
    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:

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
```
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 &
```

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:

start:
        binmode = off
        streammode = on

stream:
        cmds = /etc/security/audit/streamcmds

classes:
        filemon = FILE_write

users:
        root = filemon
        afx = filemon
        ...

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:

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
```
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
```

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.

start:
        binmode = on
        streammode = off

bin:
        cmds = /etc/security/audit/bincmds
        trail = /audit/trail
        bin1 = /audit/bin1
        bin2 = /audit/bin2
        binsize = 100000
        freespace = 100000

classes:
        custom = FILE_Write,PROC_SetUser,AUD_Bin_Def,AUD_Lost_Rec,USER_SU, \
                 PASSWORD_Change,CRON_JobAdd,AT_JobAdd,USER_Login,PORT_Locked

users:
        root = custom
        afx = custom
        ...

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:
```
user:
    auditclasses = custom
    pgrp = staff
    groups = staff
    shell = /usr/bin/ksh
    home = /home/$USER
```
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.
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.