This chapter presents procedures that are designed to help you set up and manage a Solaris environment that includes auditing. This chapter also includes instructions for administering the audit trail and for administering device allocation. This is a list of the task maps in this chapter.
The following task map shows the major tasks that are required to administer the BSM services.
Task |
Description |
For Instructions |
---|---|---|
Plan for auditing |
Configuration issues to consider and make decisions about, before you configure auditing. | |
Configure audit files |
Defines which events, classes, and users require auditing. | |
Configure auditing |
Configures each host so you can use auditing. | |
Manage audit records |
Merges and analyzes the audit data. | |
Manage device allocation |
Defines which devices should be accessed through the device allocation mechanism. |
Before you enable auditing on your network, you may want to edit the audit configuration files. Many of the following procedures require that you restart the service or reboot the local system. You should make as many of these changes as possible before you start the service.
The following task map describes the tasks in this section.
Task |
Description |
For Instructions |
---|---|---|
Change audit flags |
Defines the location of the audit directories and system-wide flags for the audit service. | |
Change audit characteristics for users |
Selects specific auditing for a user. | |
Change audit classes |
Selects which events, classes, and users require auditing. | |
Change audit events |
Adds new events to the auditing service. |
Audit flags are defined in the /etc/security/audit_control file. The audit flags select which classes of audit records are written to the audit log.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_control file.
# cp /etc/security/audit_control /etc/security/audit_control.save |
Add new entries to the audit_control file.
Each entry has the following format:
title:string |
title |
Defines the type of line. Options are dir:, flags:, minfree:, or naflags:. |
string |
Lists specific data that is associated with the line type |
Instruct the audit daemon to read the new audit_control file.
The audit daemon stores the information internally. To use the new information, either reboot the system or type the following command:
# audit -s |
Lines that start with dir: define which audit file systems can be used to store audit trail files. In this example, two additional locations for audit trail files are defined.
# cat /etc/security/audit_control dir:/etc/security/audit/host.1/files dir:/etc/security/audit/host.2/files dir:/var/audit flags: minfree:10 naflags:lo |
The flags line in the audit_control file defines which classes of events are audited for all users on the host. The classes are separated by commas, with no spaces. In this example, the events in the lo class are audited for all users.
# cat /etc/security/audit_control dir:/var/audit flags:lo minfree:10 naflags:lo |
The minfree line in the audit_control file defines the minimum free-space level for all audit file systems. In this example, the soft limit is set so that a warning is issued when only 10 percent of the file system is available.
# cat /etc/security/audit_control dir:/var/audit flags: minfree:10 naflags:lo |
The naflags: line in the audit_control file defines which classes of nonattributable events are audited for all users on the host. The classes are separated by commas, with no spaces. In this example, the na event class was added.
# cat /etc/security/audit_control dir:/var/audit flags: minfree:10 naflags:lo,na |
Definitions for each user can be stored in the /etc/security/audit_user file.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_user file.
# cp /etc/security/audit_user /etc/security/audit_user.save |
Add new entries to the audit_user file.
Each entry has the following format:
username:always:never
username |
Selects the name of the user to be audited |
always |
Selects the list of audit classes that should always be audited |
never |
Selects the list of audit classes that should never be audited |
You can specify multiple flags by separating the audit classes with commas. For more information about audit flags, see Audit Flags.
Make the new data available to the BSM service.
To use the new data, either reboot the system, or have the user log out and back in again.
This example shows an entry that causes audit records to be generated anytime the user sue accesses any programs in the login class (lo).
# grep sue /etc/security/audit_user sue:lo: |
If all the audit partitions are full, then it could be impossible to log in to a host. If all logins are audited, then the fact that the audit partitions are full would prevent anyone from completing a login. To avoid this situation, you can set up a special login that is not audited. This new login would allow you to log in to the host even if the audit partitions are full. Then, you could fix the problem with the full partitions. In this example, the user auditadm is defined so that no auditing takes place.
# grep auditadm /etc/security/audit_user auditadmin:no:yes |
The user login that is selected to serve as the audit admin login might need to be monitored in another way.
Audit classes are defined in the /etc/security/audit_class file.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_class file.
# cp /etc/security/audit_class /etc/security/audit_class.save |
Add new entries to the audit_class file.
Each entry has the following format:
0xnumber:name:description |
number |
Defines the unique audit class mask |
name |
Defines the two-letter name of the audit class |
description |
Defines the descriptive name of the audit class |
Make the new data available to the BSM service.
To use the new data, either reboot the system, or type the following command:
# auditconfig -conf |
In step 3, add an entry that resembles the following to set a new audit class called de:
0x00010000:de:device allocation |
Audit event definitions are stored in the /etc/security/audit_event file. A record is generated only after the event definition has been created and a user-level action generates the event.
Become superuser or assume an equivalent role.
(Optional) Save a backup copy of the audit_event file.
# cp /etc/security/audit_event /etc/security/audit_event.save |
Add new entries to the audit_event file.
Each entry has the following format:
number:name:description:classes
number |
Defines a unique audit event number, which must start after 32768. |
name |
Defines the unique audit event name. |
description |
Describes the audit event. Often includes the name of the man page for the audit event |
classes |
Selects the audit classes that include this event. |
Make the new data available to the BSM service.
To use the new data, either reboot the system, or type the following command:
# auditconfig -conf |
This example shows an entry that defines a new audit event for a local application.
# grep localapp /etc/security/audit_event 32769:aue_localapp:localapp(1):ap |
This section covers the tasks that are required to configure and enable the audit service.
The following task map describes the tasks that are required to configure auditing.
Task |
Description |
For Instructions |
---|---|---|
1. Plan for auditing |
Resolve configuration issues before you configure auditing. | |
2. Create audit partitions |
Creates the partitions for the audit files. | |
3. Create the audit_warn alias |
Defines who should get email warnings. | |
4. (Optional) Change audit policies |
Defines additional audit records or auditing conditions. | |
5. (Optional) Change the audit configuration files |
Selects which events, classes, and users require auditing. | |
6. Enable auditing |
Turns on auditing. | |
7. (Optional) Disable auditing |
Turns off auditing. | |
8. (Optional) Start device allocation |
Selects which removable media should be accessed in a more secure mode. |
The following procedure shows how to create partitions for auditing, as well as the corresponding file systems and directories. Skip steps as necessary, depending on if you already have an empty partition, or if you have already mounted an empty file system.
Become superuser or assume an equivalent role.
Determine the amount of disk space that is required.
Assign at least 200 Mbytes of disk space per host. However, the disk space requirements are based on how much auditing you perform. So, your requirements might be far greater than this figure. Remember to include a partition for a directory of last resort.
Create dedicated audit partitions, as needed.
This step is most easily done during server installation. You can also create the partitions on disks that have not yet been mounted on the server. For complete instructions on how to create the partitions, see “Creating a UFS File System” in System Administration Guide: Basic Administration.
newfs /dev/rdsk/cwtxdysz |
Where /dev/rdsk/cwtxdysz is the raw device name for the partition.
If the local host is to be audited, create an audit directory of last resort for it as well.
Create mount points for each new partition.
mkdir /var/audit/server-name.n |
Where server-name.n is the name of the server and a number that identifies each partition. The number is optional, but the number is useful when there are many audit directories.
Add entries to automatically mount the new partitions.
Add a line to the /etc/vfstab file that resembles the following:
/dev/dsk/cwtxdysz /dev/rdsk/cwtxdysz /var/audit/server-name.n ufs 2 yes |
(Optional) Remove the minimum free space threshold on each partition.
If you use the default configuration, a warning will be generated when the directory is 80 percent full, so there is no reason to reserve free space on the partition.
tunefs -m 0 /var/audit/server-name.n |
Mount the new audit partitions.
mount /var/audit/server-name.n |
Create audit directories on the new partitions.
mkdir /var/audit/server-name.n/files |
Correct the permissions on the mount points and new directories.
chmod -R 750 /var/audit/server-name.n/files |
(Optional) On a file server, define the file systems to be made available to other hosts.
Often, disk farms are installed to store the audit records. If an audit directory is to be used by several systems, then the directory must be shared through the NFS service. Add a entry resembling the following for each directory to the /etc/dfs/dfstab file.
share -F nfs /var/audit/server-name.n/files |
(Optional) On a file server, restart the NFS service.
If this command the first share command or set of share commands that you have initiated, it is probable that the NFS daemons are not running. The following commands kill the daemons and restart them. Refer to “Setting Up NFS Services” in System Administration Guide: Resource Management and Network Services for more information about the NFS service.
# /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start |
All systems that run the auditing service should have a local file system that can be used if no other file system is available. In this example, a file system is being added to a system named egret. Since this file system is only used locally, none of the steps for a file server are followed.
# newfs /dev/rdsk/c0t2d0 # mkdir /var/audit/egret # grep egret /etc/vfstab /dev/dsk/c0t2d0s1 /dev/rdsk/c0t2d0s1 /var/audit/egret ufs 2 yes - # tunefs -m 0 /var/audit/egret # mount /var/audit/egret # mkdir /var/audit/egret/files # chmod -R 750 /var/audit/egret/files |
In this example, a new file system is created on two new disks that are to be used by other systems in the network.
# newfs /dev/rdsk/c0t2d0 # newfs /dev/rdsk/c0t2d1 # mkdir /var/audit/egret.1 # mkdir /var/audit/egret.2 # grep egret /etc/vfstab /dev/dsk/c0t2d0s1 /dev/rdsk/c0t2d0s1 /var/audit/egret.1 ufs 2 yes - /dev/dsk/c0t2d1s1 /dev/rdsk/c0t2d1s1 /var/audit/egret.2 ufs 2 yes - # tunefs -m 0 /var/audit/egret.1 # tunefs -m 0 /var/audit/egret.2 # mount /var/audit/egret.1 # mount /var/audit/egret.2 # mkdir /var/audit/egret.1/files # mkdir /var/audit/egret.2/files # chmod -R 750 /var/audit/egret.1/files /var/audit/egret.2/files # grep egret /etc/dfs/dfstab share -F nfs /var/audit/egret.1/files share -F nfs /var/audit/egret.2/files # /etc/init.d/nfs.server stop # /etc/init.d/nfs.server start |
The audit_warn script generates mail to an alias called audit_warn. To send this mail to a valid email address, you can follow either of the following steps:
Become superuser or assume an equivalent role.
(Optional) Swap the audit_warn alias with another alias.
One option is to edit the audit_warn script and replace audit_warn with another alias. After you swap audit_warn for root, the line that sends the email message would resemble the following:
/usr/ucb/mail -s "$SUBJECT" root |
Ten lines in the script require this change.
(Optional) Redirect the audit_warn email to another alias.
The other option is to redirect the email in the /etc/mail/aliases file. In this case, you would add an alias similar to the following to the local /etc/mail/aliases file or to the mail_aliases database in the name space. The new entry would resemble the following if the email were to be redirected to the root alias:
audit_warn: root |
Audit policies determine the characteristics of the audit records for the local host. Audit policies are either enabled or disabled for a particular configuration. By default, all audit policies are disabled. You need to enable any audit policies that you want to use. For a description of each policy, see Audit Policies.
Become superuser or assume an equivalent role.
(Optional) Review the existing audit policies.
Ensure that you are aware of all the policies that are being used before you change any. The following command lists the enabled policies:
# auditconfig -lspolicy |
Enable or disable the audit policy.
auditconfig -setpolicy flagpolicyname |
flag |
A + enables the policy. A – disables the policy |
policyname |
Selects the policy to be enabled or disabled |
The policy is in effect until the next boot, or until the policy is modified by the auditconfig-setpolicy command.
The cnt policy can be set so that if the audit partitions become full, then processes are not blocked. The records are discarded when the partitions are full, but the system still functions even though the auditing process is not recording the events. The cnt policy should not be set if security is paramount, since unrecorded events can occur if the file system is full.
The following command enables the cnt policy:
# auditconfig -setpolicy +cnt |
For a secure site, you should enable the cnt policy in an appropriate startup file.
This task starts the auditing service. If the service has been configured, then rebooting the host also starts the service.
Become superuser or assume an equivalent role.
Bring the system into single-user mode.
# /etc/telinit 1 |
See the telinit(1M) man page for more information.
Run the script to configure the system to run auditing.
Go to the /etc/security directory, and execute the bsmconv script there. The script sets up a standard Solaris machine to run BSM after a reboot. See the bsmconv(1M) man page.
# cd /etc/security # ./bsmconv |
Bring the system into multiuser mode.
# /etc/telinit 6 |
The startup file /etc/security/audit_startup causes the audit daemon to run automatically when the system enters multiuser mode.
The bsmconv script adds a line to the /etc/system file that prevents users from aborting the system with the Stop-A keyboard sequence. To retain the ability to abort the system with the Stop-A keyboard sequence, you must comment out the line in the /etc/system file that reads: set abort_enable=0.
If BSM is no longer required at some point, you can disable it by running the bsmunconv command. See the bsmconv(1M) man page.
Become superuser or assume an equivalent role.
Bring the system into single-user mode.
# /etc/telinit 1 |
See the telinit(1M) man page for more information.
Run the script to disable auditing.
Change to the /etc/security directory, and execute the bsmunconv script there.
# cd /etc/security # ./bsmunconv |
Bring the system into multiuser mode.
# /etc/telinit 6 |
The bsmunconv script removes the line in the /etc/system file that allows users to abort the system with the Stop-A keyboard sequence. If you want to continue to prevent users from aborting the system with the Stop-A keyboard sequence after you run the bsmunconv script, you must reenter into the /etc/system file the line that reads: set abort_enable=0.
Managing the audit trail enables you to monitor the actions of users on your network. Auditing can generate large amounts of data. The following tasks show you how to work with all this data.
The following task map describes the tasks in this section.
Task |
Description |
For Instructions |
---|---|---|
Merge audit records |
Combines audit files from several machines into one audit trail. | |
Display audit record formats |
Displays the order of tokens for a particular audit event. | |
Prevent audit trail overflow |
Prevents the audit file systems from completely filling up. |
This task shows you how to merge all audit files in all the audit directories. Follow these steps when you want to analyze the contents of the audit trail.
Become superuser or assume an equivalent role.
Change directories to the primary audit directory.
# cd /etc/security/audit/server-name.1/files |
Moving to this directory places the merged file in this protected directory.
Merge the audit records.
# auditreduce > merged.log |
All directories that are listed in the dir: lines of the audit_control file on server-name are merged and placed in the file called merged.log.
To display the entire audit trail at once, pipe the output of the auditreduce command into the praudit command.
# auditreduce | praudit |
With a pipe to the lp command, the output goes to the printer.
# auditreduce | praudit | lp |
Use auditreduce with the -O option to combine several audit files into one file and to save them in a specified output file. auditreduce can do this type of combination and deletion automatically (see the -C and -D options in the auditreduce(1M) man page). However, it is often easier to select the files manually (perhaps with the find command) and use auditreduce to combine just the named set of files.
When used in this way, auditreduce merges all the records from its input files into a single output file. The input files should then be deleted. In addition, the output file should be kept in a directory that is named /etc/security/audit/server-name/files so that auditreduce can find it.
# auditreduce -O combined-filename |
The auditreduce command can also reduce the number of records in its output file by eliminating the less interesting records as it combines the input files. For example, you might use auditreduce to retain only the login and logout records in audit files that are over a month old. If you need to retrieve the complete audit trail, you could recover it from backup tapes.
# auditreduce -O daily.summary -b 19990413 -c lo; compress *daily.summary # mv *daily.summary /etc/security/summary.dir |
In the following example, the system administrator checks to see when user tamiko logged in and logged out on April 13, 1999, by requesting the lo event class. The short-form date is in the form yymmdd. The long form is described in the auditreduce(1M) man page.
# auditreduce -d 990413 -u tamiko -c lo | praudit |
In this example, login and logout messages for a particular day are selected from the audit trail and merged into a target file. The target file is written in a directory other than the normal audit root directory.
# auditreduce -c lo -d 990413 -O /usr/audit_summary/logins |
The -O option creates an audit file with 14-character timestamps for both the start-time and the end-time, with the suffix logins:
/usr/audit_summary/19990413000000.19990413235959.logins |
Occasionally, an audit daemon dies while its audit file is still open, or a server becomes inaccessible and forces the machine to switch to a new server. In such instances, an audit file remains with the string not_terminated as the end-time, even though the file is no longer used for audit records. When you find such a file, you can manually verify that the file is no longer in use and clean it up by specifying the name of the file with the correct options.
# audit -s 19990414121112.not_terminated.egret # auditreduce -O egret 19990413120429.not_terminated.egret |
The audit command checks the name of the current audit file. The auditreduce command creates a new audit file with the correct name and correct timestamps, with the correct suffix (egret), and copies all the records into it.
The following command displays the formats of all audit event records. This command operates on records in the audit_class, audit_event, and audit_record_attr files.
# bsmrecord -a |
In this example, the format of the audit record with an ID of 6152 is displayed.
# bsmrecord -i 6152 # login: terminal login program /usr/sbin/login see login(1) event ID 6152 AUE_login class lo (0x00001000) header-token subject-token text-token error message exit-token # |
If your security policy requires that all audit data be saved, do the following:
Set up a schedule to regularly archive audit files and to delete the archived audit files from the audit file system.
Manually archive audit files by backing them up on tape or by moving them to an archive file system.
Store context-sensitive information that will be needed to interpret audit records, along with the audit trail.
Keep records of which audit files are moved offline.
Store the archived tapes appropriately.
Reduce the volume of audit data that you store by creating summary files.
You can extract summary files from the audit trail by using options to auditreduce so that the summary files contain only records for certain specified types of audit events. For examples, see Example — Combining and Reducing Audit Files and Example — Copying Selected Records to a Single File.
You can use device allocation to decrease the security risk that is associated with various removable media.
The following task map describes the major steps that are required to define a new allocatable device.
Task |
Description |
For Instructions |
---|---|---|
1. Create or change an entry in the device_allocate file |
Defines which devices are controlled by the device-allocation mechanism. | |
2. Create a lock file |
Enables the device allocation mechanism to work on a specific device. | |
3. (Optional) Create a device-clean script |
Purges data from a physical device. | |
4. Allocate the device |
Adds a device to the device-allocation mechanism. | |
5. (Optional) Deallocate the device |
Removes a device from use. |
The lock files are zero-length files that are created in the /etc/security/dev directory. One file is created for each allocatable device. If no lock file exists for a device, the device cannot be allocated, so no one can access the device.
Become superuser or assume an equivalent role.
Obtain the device name for the device from its entry in the device_maps file by using the dminfo command.
See The device_maps File and the dminfo(1M) and device_maps(4) man pages. For example, the device name for device type st is st0. In the next step, you will use the device name as the name of the lock file.
Create an empty lock file for the device by using the touch command.
Use the device name for the file name in place of device-name.
# cd /etc/security/dev # touch device-name # chmod 600 device-name # chown bin device-name # chgrp bin device-name |
This procedure defines which devices can be used with the device allocation mechanism.
Become superuser or assume an equivalent role.
Determine which devices are listed in the /etc/security/device_allocate file.
Decide if there are devices that are not in the device_allocate file, yet should be made allocatable.
Edit the device_allocate file and add the new device.
Each entry should use the following format:
device-name;device-type;;;;program |
device-name |
Specifies the name of the device |
device-type |
Specifies the device type |
program |
Specifies the purge program to be run |
Become superuser or assume an equivalent role.
Use the allocate command with a device that is specified by device name.
sar1% allocate st0 |
You can also allocate a device by device type by using the -g option to the allocate command.
If the command cannot allocate the device, an error message is displayed in the console window. For a list of allocation error messages, see the allocate(1) man page.
sarl% allocate /dev/lp/chestnut |
Only the user who ran the allocate command can use the printer.
Deallocate a device by using the deallocate command followed by the device file name.
sar1% deallocate st0 |
Deallocation enables other users to allocate and use the device when you are finished.
To deallocate a printer that is named chestnut, type the following command:
# deallocate /dev/lp/chestnut |
Devices that a user has allocated are not automatically deallocated when the process terminates or when this user logs out. You most commonly need to use the following form of the deallocate command when a user forgets to deallocate a specific device. Then you force its deallocation, so that others users can allocate it.
# deallocate -F st0 |
You can deallocate all devices only at system initialization time.
# deallocate -I |