Chapter 30 Managing Solaris Auditing (Tasks)

This chapter presents procedures to help you set up and manage a Solaris system that is audited. This chapter also includes instructions for administering the audit trail. The following is a list of the information in this chapter.

• Solaris Auditing (Task Map)

• Configuring Audit Files (Task Map)

• Configuring and Enabling the Audit Service (Task Map)

• Managing Audit Records (Task Map)

• Troubleshooting Solaris Auditing (Task Map)

For an overview of the audit service, see Chapter 28, Solaris Auditing (Overview). For planning suggestions, see Chapter 29, Planning for Solaris Auditing. For reference information, see Chapter 31, Solaris Auditing (Reference).

Solaris Auditing (Task Map)

The following task map points to the major tasks that are required to manage auditing. The tasks are ordered.

Configuring Audit Files (Task Map)

The following task map points to the procedures for configuring files to customize auditing at your site. Most of the tasks are optional.

Configuring Audit Files (Tasks)

Before you enable auditing on your network, you can customize the audit configuration files for your site auditing requirements. You can also restart the audit service or reboot the local system to read changed configuration files after the audit service has been enabled. However, the recommended practice is to customize your audit configuration as much as possible before you start the audit service.

If you have implemented zones, you can choose to audit all zones from the global zone. To differentiate between zones in the audit output, you can set the zonename policy option. Alternatively, to audit non-global zones individually, you can set the perzone policy in the global zone and customize the audit configuration files in the non-global zones. For an overview, see Auditing and Solaris Zones. For planning, see How to Plan Auditing in Zones. For procedures, see Configuring the Audit Service in Zones (Tasks).

How to Modify the audit_control File

The /etc/security/audit_control file configures system-wide auditing. The file determines which events are audited, when audit warnings are issued, and the location of the audit files.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_control file.

   # cp /etc/security/audit_control /etc/security/audit_control.orig

3. Modify the audit_control file for your site.

   Each entry has the following format:

   keyword:value

   keyword

   Defines the type of line. The types are dir, flags, minfree, naflags, and plugin. In the Solaris 10 release, the dir and minfree lines are deprecated.

   For explanations of the keywords, see the following examples.

   value

   Specifies data that is associated with the line type.

   ---

   Note –

   To specify the locations of audit directories, use the p_dir attribute to the audit_binfile.so plugin. To specify the minimum free space, use the p_minfree attribute.

   ---

4. (Optional) Verify the syntax of the file.

   # audit -v /etc/security/audit_control syntax ok

Example 30–1 Preselecting Audit Classes for All Users

The flags line in the audit_control file defines which classes of attributable events are audited for all users on the system. The classes are separated by commas. White space is allowed. In this example, the events in the lo and ap classes are audited for all users.

## audit_control file
flags:lo,ap
naflags:lo
plugin:name=...

To see which events are assigned to a class, read the audit_event file. You can also use the bsmrecord command, as shown in Example 30–27.

Example 30–2 Preselecting Nonattributable Events

In this example, all events in the na class, and all login events that are not attributable, are audited.

## audit_control file
flags:lo
naflags:lo,na
plugin:name=...

Example 30–3 Specifying the Location of Binary Audit Data

The p_dir flag to the audit_binfile.so plugin lists which audit file systems to use for binary audit data. In this example, three locations for binary audit data are defined. The directories are listed in order from the primary directory to the directory of last resort. The plugin line does not contain a line break.

## audit_control file
##
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/egret.1/files,
/var/audit/egret.2/files,/var/audit

To set up file systems to hold audit binary audit data, see How to Create Partitions for Audit Files.

Example 30–4 Changing the Soft Limit for Warnings

In this example, the minimum free-space level for all audit file systems is set so that a warning is issued when only 10 percent of the file system is available.

The plugin line does not contain a line break.

## audit_control file
#
flags:lo
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/examplehost.1/files,
/var/audit/examplehost.2/files,/var/audit/localhost/files; p_minfree=10

The audit_warn alias receives the warning. To set up the alias, see How to Configure the audit_warn Email Alias.

How to Configure syslog Audit Logs

You can instruct the audit service to copy some or all of the collected audit records in the audit queue to syslog. In the following procedure, you save binary audit data and text audit data. The collected text audit data is a subset of the binary data.

Before You Begin

You must preselect audit classes. Preselected audit classes are specified in the flags line and the naflags line of the audit_control file. You can also preselect classes for individual users in the audit_user file and dynamically add audit classes with the auditconfig command.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_control file.

   # cp /etc/security/audit_control /etc/security/audit_control.save

3. Add an audit_syslog.so plugin entry.

   ## audit_control file flags:lo,ss naflags:lo,na plugin:name=audit_binfile.so;p_dir=/var/audit; p_minfree=20; plugin:name=audit_syslog.so;p_flags=+lo,-ss

   A plugin entry has the following format:

   plugin:name=name; qsize=max-queued-records;p_*=value

   • name=name – Lists the name of the plugin. The valid values are audit_binfile.so and audit_syslog.so.

   • qsize=max-queued-records – Specifies the maximum number of records to queue for audit data that is being sent to the plugin. This attribute is optional.

   • p_*=value – Specifies plugin-specific attributes. The audit_syslog.so plugin accepts p_flags. The audit_binfile.so plugin accepts p_dir, p_minfree and p_fsize. The p_fsize attribute was introduced in Solaris 10 10/08.

   For more information about the plugin-specific attributes, see the OBJECT ATTRIBUTES section of the audit_binfile(5) and audit_syslog(5) man pages.

4. Add an audit.notice entry to the syslog.conf file.

   The entry includes the location of the log file.

   # cat /etc/syslog.conf … audit.notice /var/adm/auditlog

   Do not store text logs where the binary audit files are stored. The auditreduce command, which reads binary audit files, assumes that all files in an audit partition are binary audit files.

5. Create the log file.

   # touch /var/adm/auditlog

6. Refresh the configuration information for the syslog service.

   # svcadm refresh system/system-log

7. Regularly archive the syslog log files.

   The audit service can generate extensive output. To manage the logs, see the logadm(1M) man page.

Example 30–5 Specifying Audit Classes for syslog Output

In the following example, the syslog utility collects a subset of the preselected audit classes.

## audit_user file
jdoe:pf

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit/host.1/files,
/var/audit/host.2/files,/var/audit/localhost/files; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-na,-ss,+pf

The flags and naflags entries instruct the system to collect all login/logout, nonattributable, and change of system state audit records in binary format. The audit_syslog.so plugin entry instructs the syslog utility to collect only failed logins, failed nonattributable events, and failed changes of system state. For the jdoe user, the binary audit record includes all uses of a profile-aware shell. The syslog utility collects successful profile-aware commands. The pf class is created in Example 30–10.

Example 30–6 Putting syslog Audit Records on a Remote System

You can change the audit.notice entry in the syslog.conf file to point to a remote system. In this example, the name of the local system is example1. The remote system is remote1.

example1 # cat /etc/syslog.conf
…
audit.notice       @remote1

The audit.notice entry in the syslog.conf file on the remote1 system points to the log file.

remote1 # cat /etc/syslog.conf
…
audit.notice       /var/adm/auditlog

Example 30–7 Using Plugins in the audit_control File

The preferred method for specifying non-flags information in the audit_control file is to use the plugin entry. In this example, the audit flags are selected, then the plugin information is listed.

## audit_control file
flags:lo,ss
naflags:lo,na
plugin:name=audit_binfile.so;p_minfree=10; p_dir=/var/audit
plugin:name=audit_syslog.so; p_flags=+lo

How to Change a User's Audit Characteristics

Definitions for each user are stored in the audit_user database. These definitions modify, for the specified user, the preselected classes in the audit_control file. The nsswitch.conf file determines if a local file or if a naming service database is used. To calculate the user's final audit preselection mask, see Process Audit Characteristics.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_user database.

   # cp /etc/security/audit_user /etc/security/audit_user.orig

3. Add new entries to the audit_user database.

   In the local database, each entry has the following format:

   username:always-audit:never-audit

   username

   Selects the name of the user to be audited.

   always-audit

   Selects the list of audit classes that should always be audited for the specified user.

   never-audit

   Selects the list of audit classes that should never be audited for the specified user.

   You can specify multiple classes by separating the audit classes with commas.

   The audit_user entries are in effect at the user's next login.

Example 30–8 Changing Which Events Are Audited for One User

In this example, the audit_control file contains the preselected audit classes for the system:

## audit_control file
…
flags:lo,ss
naflags:lo,na

The audit_user file shows an exception. When the user jdoe uses a profile shell, that use is audited:

## audit_user file
jdoe:pf

The audit preselection mask for jdoe is a combination of the audit_user settings with the audit_control settings. The auditconfig -getaudit command shows the preselection mask for jdoe:

# auditconfig -getaudit
audit id = jdoe(1234567)
process preselection mask = ss,pf,lo(0x13000,0x13000)
terminal id (maj,min,host) = 242,511,example1(192.168.160.171)
audit session id = 2138517656

Example 30–9 Auditing Users Only, Not the System

In this example, the login and role activities of four users only are audited on this system. The audit_control file does not preselect audit classes for the system.

## audit_control file
…
flags:
naflags:

The audit_user file preselects two audit classes for four users, as follows:

## audit_user file
jdoe:lo,pf
kdoe:lo,pf
pdoe:lo,pf
sdoe:lo,pf

The following audit_control file records unwarranted intrusion. In combination with the audit_user file, this file protects the system more than the first audit_control file in this example.

## audit_control file
…
flags:
naflags:lo
plugin:name=...

How to Add an Audit Class

When you create your own audit class, you can place into it just those audit events that you want to audit for your site. When you add the class on one system, you should copy the change to all systems that are being audited.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_class file.

   # cp /etc/security/audit_class /etc/security/audit_class.orig

3. Add new entries to the audit_class file.

   Each entry has the following format:

   0xnumber:name:description

   0x

   Identifies number as hexadecimal.

   number

   Defines the unique audit class mask.

   name

   Defines the letter name of the audit class.

   description

   Defines the descriptive name of the audit class.

   The entry must be unique in the file. Do not use existing audit class masks.

Example 30–10 Creating a New Audit Class

This example creates a class to hold a small set of audit events. The added entry to the audit_class file is as follows:

0x10000000:pf:profile command

The entry creates a new audit class that is called pf. Example 30–11 populates the new audit class.

Troubleshooting

If you have customized the audit_class file, make sure that any modifications to audit_user are consistent with the new audit classes. Errors occur when the audit classes in audit_user are not a subset of the audit_class database.

How to Change an Audit Event's Class Membership

You might want to change an audit event's class membership to reduce the size of an existing audit class, or to place the event in a class of its own. When you reconfigure audit event-class mappings on one system, you should copy the change to all systems that are being audited.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_event file.

   # cp /etc/security/audit_event /etc/security/audit_event.orig

3. Change the class to which particular events belong by changing the class-list of the events.

   Each entry has the following format:

   number:name:description:class-list

   number

   Is the audit event ID.

   name

   Is the name of the audit event.

   description

   Typically, the system call or executable that triggers the creation of an audit record.

   class-list

   Is a comma-separated list of audit classes.

Example 30–11 Mapping Existing Audit Events to a New Class

This example maps an existing audit event to the new class that was created in Example 30–10. In the audit_control file, the binary audit record captures successes and failures of events in the pf class. The syslog audit log contains only failures of events in the pf class.

# grep pf | /etc/security/audit_class
0x10000000:pf:profile command
# vi /etc/security/audit_event
6180:AUE_prof_cmd:profile command:ua,as,pf
# vi audit_control
...
flags:lo,pf
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,-pf

Example 30–12 Auditing the Use of setuid Programs

This example creates a class to hold events that monitor calls to the setuid and setgid programs. The binary audit record captures successes and failures of events in the lo and na classes, and the successes of events in the st class. The syslog audit log contains only successes of events in the st class.

# vi /etc/security/audit_class
0x00000800:st:setuid class
# vi /etc/security/audit_event
26:AUE_SETGROUPS:setgroups(2):st
27:AUE_SETPGRP:setpgrp(2):st
40:AUE_SETREUID:setreuid(2):st
41:AUE_SETREGID:setregid(2):st
214:AUE_SETEGID:setegid(2):st
215:AUE_SETEUID:seteuid(2):st

# vi audit_control
## audit_control file
flags:lo,+st
naflags:lo,na
plugin:name=audit_binfile.so; p_dir=/var/audit; p_minfree=10
plugin:name=audit_syslog.so; p_flags=-lo,+st

Configuring and Enabling the Audit Service (Task Map)

The following task map points to procedures for configuring and enabling the audit service. The tasks are ordered.

Configuring and Enabling the Audit Service (Tasks)

After the configuration files have been set up for your site, you need to set up disk space for your audit files. You also need to set up other attributes of the audit service, and then enable the service. This section also contains procedures to refresh the audit service when you change configuration settings.

When a non-global zone is installed, you can choose to audit the zone exactly as the global zone is being audited. Alternatively, to audit the non-global zone individually, you can modify the audit configuration files in the non-global zone. To customize audit configuration files, see Configuring Audit Files (Task Map).

How to Create Partitions for Audit Files

The following procedure shows how to create partitions for audit files, 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.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Determine the amount of disk space that is required.

   Assign at least 200 Mbytes of disk space per host. However, how much auditing you require dictates the disk space requirements. So, your disk space requirements might be far greater than this figure. Remember to include a local partition for a directory of last resort.

3. 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 Chapter 11, Administering Disks (Tasks), in System Administration Guide: Devices and File Systems.

   # newfs /dev/rdsk/cwtxdysz

   where /dev/rdsk/cwtxdysz is the raw device name for the partition.

   If the local host is to be audited, also create an audit directory of last resort for the local host.

4. Create mount points for each new partition.

   # mkdir /var/audit/server-name.n

   where server-name.n is the name of the server plus a number that identifies each partition. The number is optional, but the number is useful when there are many audit directories.

5. 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

6. (Optional) Remove the minimum free space threshold on each partition.

   If you use the default configuration, a warning is generated when the directory is 80 percent full. The warning removes the reason to reserve free space on the partition.

   # tunefs -m 0 /var/audit/server-name.n

7. Mount the new audit partitions.

   # mount /var/audit/server-name.n

8. Create audit directories on the new partitions.

   # mkdir /var/audit/server-name.n/files

9. Correct the permissions on the mount points and new directories.

   # chmod -R 750 /var/audit/server-name.n/files

10. 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 an entry that resembles the following for each directory to the /etc/dfs/dfstab file:

    share -F nfs /var/audit/server-name.n/files

11. On a file server, restart the NFS service.

    If this command is the first share command or set of share commands that you have initiated, the NFS daemons might not be running.

    • If the NFS service is offline, enable the service.

      % svcs \*nfs\* disabled Nov_02 svc:/network/nfs/rquota:default offline Nov_02 svc:/network/nfs/server:default # svcadm enable network/nfs/server

    • If the NFS service is running, restart the service.

      % svcs \*nfs\* online Nov_02 svc:/network/nfs/client:default online Nov_02 svc:/network/nfs/server:default # svcadm restart network/nfs/server

    For more information about the NFS service, refer to Setting Up NFS Services in System Administration Guide: Network Services. For information on managing persistent services, see Chapter 18, Managing Services (Overview), in System Administration Guide: Basic Administration and the smf(5) man page.

Example 30–13 Creating an Audit Directory of Last Resort

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 that is named egret. Because this file system is only used locally, none of the steps for a file server are necessary.

# 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

Example 30–14 Creating New Audit Partitions

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
# svcadm enable network/nfs/server

Example 30–15 Creating ZFS Audit Partitions

In this example, the administrator runs the script command after the ZFS audit partitions are created. The following is the output of the command:

# zpool create auditf mirror c0t4d0 c0t5d0
# zfs create -o mountpoint=/audit auditf/audit
# zfs create auditf/audit/noddy
# zfs create auditf/audit/noddy/files
# zfs create auditf/audit/blinken
# zfs create auditf/audit/blinken/files
# zfs set devices=off auditf/audit
# zfs set exec=off auditf/audit
# zfs set setuid=off auditf/audit
# zfs set sharenfs=on auditf/audit
# share
-               /audit/blinken/files   rw   ""
-               /audit/noddy   rw   ""
-               /audit/blinken   rw   ""
-               /audit/noddy/files   rw   ""
-               /audit   rw   ""
# ^D
script done on Fri Apr 10 10:10:20 2009

The administrator then views the mounts from the remote system, remotesys.

# dfshares remotesys
RESOURCE                             SERVER ACCESS    TRANSPORT
remotesys:/audit/blinken/files       remotesys  -         -
remotesys:/audit/noddy               remotesys  -         -
remotesys:/audit/blinken             remotesys  -         -
remotesys:/audit/noddy/files         remotesys  -         -
remotesys:/audit                     remotesys  -         -

Finally, the administrator mounts the /audit file system on /var/audit.

# mount remotesys:/audit /var/audit
# ls /var/audit
blinken  noddy 

How to Configure the audit_warn Email Alias

The audit_warn script generates mail to an email alias that is called audit_warn. To send this mail to a valid email address, you can follow one of the options that are described in Step 2:

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. Configure the audit_warn email alias.

   Choose one of the following options:

   • OPTION 1 – Replace the audit_warn email alias with another email account in the audit_warn script.

     Change the email alias in the following line of the script:

     ADDRESS=audit_warn # standard alias for audit alerts

   • OPTION 2 – Redirect the audit_warn email to another mail account.

     In this case, you would add the audit_warn email alias to the appropriate mail aliases file. You could add the alias 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 root mail account was made a member of the audit_warn email alias:

     audit_warn: root

How to Configure Audit Policy

Audit policy determines the characteristics of the audit records for the local host. When auditing is enabled, the contents of the /etc/security/audit_startup file determine the audit policy.

You can inspect and change the current audit policy options with the auditconfig command. You can also modify the policy options to the auditconfig command in the audit_startup script to make permanent audit policy changes.

1. Assume a role that includes the Audit Control profile, or become superuser.

   To create a role that includes the Audit Control profile and to assign the role to a user, see Configuring RBAC (Task Map).

2. Review the audit policy.

   Before auditing is enabled, the contents of the audit_startup file determine the audit policy:

   #! /bin/sh ... /usr/bin/echo "Starting BSM services." /usr/sbin/auditconfig -setpolicy +cnt Counts rather than drops records /usr/sbin/auditconfig -conf Configures event-class mappings /usr/sbin/auditconfig -aconf Configures nonattributable events

3. View the available policy options.

   $ auditconfig -lspolicy

   ---

   Note –

   The perzone and ahlt policy options can be set only in the global zone.

   ---

4. Enable or disable selected audit policy options.

   # auditconfig -setpolicy prefixpolicy

   prefix

   A prefix value of + enables the policy option. A prefix value of - disables the policy option.

   policy

   Selects the policy to be enabled or to be disabled.

   The policy is in effect until the next boot, or until the policy is modified by the auditconfig -setpolicy command.

   For a description of each policy option, see Determining Audit Policy.

Example 30–16 Setting the cnt and ahlt Audit Policy Options

In this example, the cnt policy is disabled, and the ahlt policy is enabled. With these settings, system use is halted when the audit partitions are full and an asynchronous event occurs. When a synchronous event occurs, the process that created the thread hangs. These settings are appropriate when security is more important than availability.

The following audit_startup entries disable the cnt policy option and enable the ahlt policy option across reboots:

# cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy -cnt	
/usr/sbin/auditconfig -setpolicy +ahlt

Example 30–17 Setting the seq Audit Policy Temporarily

In this example, the auditd daemon is running and the ahlt audit policy has been set. The seq audit policy is added to the current policy. The seq policy adds a sequence token to every audit record. This is useful for debugging the auditing service when audit records are corrupted, or when records are being dropped.

The + prefix adds the seq option to the audit policy, rather than replaces the current audit policy with seq. The auditconfig command puts the policy in effect until the next invocation of the command, or until the next boot.

$ auditconfig -setpolicy +seq
$ auditconfig -getpolicy
audit policies = ahlt,seq	

Example 30–18 Setting the perzone Audit Policy

In this example, the perzone audit policy is set in the audit_startup script in the global zone. When a zone boots, the non-global zone collects audit records according to the audit configuration settings in its zone.

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +perzone
/usr/sbin/auditconfig -setpolicy +cnt

Example 30–19 Changing an Audit Policy

In this example, the audit daemon is running and audit policy has been set. The auditconfig command changes the ahlt and cnt policies for the duration of the session. With these settings, audit records are dropped, but counted, when the audit file system is full. For restrictions on setting the ahlt policy, see Step 3.

$ auditconfig -setpolicy +cnt
$ auditconfig -setpolicy -ahlt
$ auditconfig -getpolicy
audit policies = cnt,seq

When the changes are put in the audit_startup file, the policies are permanently in effect:

$ cat /etc/security/audit_startup
#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate -Is
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
/usr/sbin/auditconfig -setpolicy +cnt

The -ahlt option does not have to be specified in the file, because the ahlt policy option is disabled by default. This setting is appropriate when availability is more important than the security that audit records provide.

How to Enable the Audit Service

This procedure enables the audit service for all zones. To start the audit daemon in a non-global zone, see Example 30–20.

When auditing is configured securely, the system is in single-user mode until auditing is enabled. You can also enable auditing in multiuser mode.

Before You Begin

You should perform this procedure as superuser after completing the following tasks:

• Planning – Planning Solaris Auditing (Task Map)

• Customizing audit files – Configuring Audit Files (Task Map)

• Setting up audit partitions – How to Create Partitions for Audit Files

• Setting up audit warning messages – How to Configure the audit_warn Email Alias

• Setting audit policy – How to Configure Audit Policy

Host name translation must be working correctly for auditing to function. The hosts database in the naming services must be correctly configured and functioning.

For configuration of the hosts database, see the nsswitch.conf(4) and netconfig(4) man pages. For additional information, see the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) or the System Administration Guide: Naming and Directory Services (NIS+).

1. Run the script that enables the audit service.

   Go to the /etc/security directory, and execute the bsmconv script there.

   # cd /etc/security # ./bsmconv This script is used to enable the Basic Security Module (BSM). Shall we continue with the conversion now? [y/n] y bsmconv: INFO: checking startup file. bsmconv: INFO: turning on audit module. bsmconv: INFO: initializing device allocation. The Basic Security Module is ready. If there were any errors, please fix them now. Configure BSM by editing files located in /etc/security. Reboot this system now to come up with BSM enabled.

   For the effects of the script, see the bsmconv(1M) man page.

2. Reboot the system.

   # reboot

   The startup file /etc/security/audit_startup causes the auditd daemon to run automatically when the system enters multiuser mode.

   Another effect of the script is to turn on device allocation. To configure device allocation, see Managing Device Allocation (Task Map).

Example 30–20 Enabling Auditing in a Non-Global Zone

In the following example, the global zone administrator turned on perzone policy after auditing was enabled in the global zone and after the non-global zone had booted. The zone administrator of the non-global zone has configured the audit files for the zone, and then starts the audit daemon in the zone.

zone1# svcadm enable svc:/system/auditd

How to Disable the Audit Service

If the audit service is no longer required at some point, this procedure returns the system to the system state before auditing was enabled. If non-global zones are being audited, their audit service is also disabled.

This command also disables device allocation. Do not run this command if you want to be able to allocate devices. To disable auditing and retain device allocation, see Example 30–21.

1. Become superuser and bring the system into single-user mode.

   % su Password: <Type root password> # init S

   For more information, see the init(1M) man page.

2. Run the script to disable auditing.

   Change to the /etc/security directory, and execute the bsmunconv script.

   # cd /etc/security # ./bsmunconv

   Another effect of the script is to disable device allocation.

   For information on the full effect of the bsmunconv script, see the bsmconv(1M) man page.

3. Bring the system into multiuser mode.

   # init 6

Example 30–21 Disabling Auditing and Keeping Device Allocation

In this example, the audit service stops collecting records, but device allocation continues to work. All values from the flags, naflags, and plugin entries in the audit_control file are removed, as are all user entries in the audit_user file.

## audit_control file
flags:
naflags:

## audit_user file

The auditd daemon runs, but no audit records are kept.

Example 30–22 Disabling Auditing on a Per-Zone Basis

In this example, the audit service stops running in zone1 where the audit service is disabled. Device allocation continues to work. When this command is run in the global zone, and the perzone audit policy is not set, auditing is disabled for all zones, not just the global zone.

zone1 # audit -t

How to Update the Audit Service

This procedure restarts the auditd daemon when you have made changes to audit configuration files after the daemon has been running.

1. Assume a role that includes the Audit Control rights profile, or become superuser.

   To create a role that includes the Audit Control rights profile and assign the role to a user, see Configuring RBAC (Task Map).

2. Choose the appropriate command.

   • If you modify the naflags line in the audit_control file, change the kernel mask for nonattributable events.

     $ /usr/sbin/auditconfig -aconf

     You can also reboot.

   • If you modify other lines in the audit_control file, reread the audit_control file.

     The audit daemon stores information from the audit_control file internally. To use the new information, either reboot the system or instruct the audit daemon to read the modified file.

     $ /usr/sbin/audit -s

     ---

     Note –

     Audit records are generated based on the audit preselection mask that is associated with each process. Executing audit -s does not change the masks in existing processes. To change the preselection mask for an existing process, you must restart the process. You can also reboot.

     ---

     The audit -s command causes the audit daemon to re-read the directory and minfree values from the audit_control file. The command changes the generation of the preselection mask for processes spawned by subsequent logins.

   • If you modify the audit_event file or the audit_class file while the audit daemon is running, refresh the audit service.

     Read the modified event-class mappings into the system, and ensure that each user who uses the machine is correctly audited.

     $ auditconfig -conf $ auditconfig -setumask auid classes

     auid

     Is the user ID.

     classes

     Are the preselected audit classes.

     For an example, see How to Modify a User's Preselection Mask.

   • To change audit policy on a running system, see Example 30–17.

Example 30–23 Restarting the Audit Daemon

In this example, the system is brought down to single-user mode, then back up to multiuser mode. When the system is brought into multiuser mode, modified audit configuration files are read into the system.

# init S
# init 6

Configuring the Audit Service in Zones (Tasks)

The audit service audits the entire system, including audit events in zones. A system that has installed non-global zones can audit all zones identically, or can control auditing per zone. For background, see Auditing on a System With Zones. To plan, see How to Plan Auditing in Zones.

How to Configure All Zones Identically for Auditing

This procedure enables audits every zone identically. This method requires the least computer overhead and administrative resources.

1. Configure the global zone for auditing.

   1. Complete the tasks in Configuring Audit Files (Task Map).

   2. Complete the tasks in Configuring and Enabling the Audit Service (Task Map), with the following exceptions.

      • Do not enable perzone audit policy.

      • Do not enable the audit service. You enable the audit service after you have configured the non-global zones for auditing.

2. Copy the audit configuration files from the global zone to every non-global zone.

   Copy any of the following files that you have edited: audit_class, audit_control, audit_event, audit_user. Do not copy audit_startup or audit_warn. You do not have to copy files that you have not edited.

   You have two options. As superuser, you can copy the files, or loopback mount the files. The non-global zone must be running.

   • Copy the files.

     1. From the global zone, list the /etc/security directory in the non-global zone.

        # ls /zone/zonename/etc/security/

     2. Copy the audit configuration files to the zone's /etc/security directory.

        # cp /etc/security/audit-file /zone/zonename/etc/security/audit-file

        Later, if you modify an audit configuration file in the global zone, you re-copy the file to the non-global zones.

   • Loopback mount the configuration files.

     1. From the global zone, halt the non-global zone.

        # zoneadm -z non-global-zone halt

     2. Create a read-only loopback mount for every audit configuration file that you modified in the global zone.

        # zonecfg -z non-global-zone add fs set special=/etc/security/audit-file set dir=/etc/security/audit-file set type=lofs add options [ro,nodevices,nosetuid] end exit

     3. To make the changes effective, boot the non-global zone.

        # zoneadm -z non-global-zone boot

        You can also reboot the system.

        Later, if you modify an audit configuration file in the global zone, you reboot the system to refresh the loopback-mounted files in the non-global zones.

Example 30–24 Loopback Mounting Audit Configuration Files

In this example, the system administrator has modified the audit_class, audit_event, audit_control, audit_user, audit_startup, and audit_warn files.

The audit_startup and audit_warn files are read in the global zone only, so do not have to be loopback mounted into the non-global zones.

On this system, machine1, the administrator has created two non-global zones, machine1–webserver and machine1–appserver. The administrator has finished customizing the audit configuration files. If the administrator later modifies the files, the system will be rebooted to make the changes effective.

# zoneadm -z machine1-webserver halt
# zoneadm -z machine1-appserver halt
# zonecfg -z machine1-webserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_event
    set dir=/etc/security/audit_event
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 add fs
    set special=/etc/security/audit_control
    set dir=/etc/security/audit_control
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end 
add fs
    set special=/etc/security/audit_user
    set dir=/etc/security/audit_user
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
 exit
# zonecfg -z machine1-appserver 
 add fs
    set special=/etc/security/audit_class
    set dir=/etc/security/audit_class
    set type=lofs
    add options [ro,nodevices,nosetuid]
    end
...
 exit

When the zones are rebooted, the audit configuration files are read-only in the zones.

How to Configure Per-Zone Auditing

This procedure enables separate zone administrators to control the audit service in their zone. For the complete list of policy options, see the auditconfig(1M) man page.

1. In the global zone, configure auditing, but do not enable the audit service.

   1. Complete the tasks in Configuring Audit Files (Task Map).

   2. Complete the tasks in Configuring and Enabling the Audit Service (Task Map), with the following exceptions.

      • Add the perzone audit policy. For an example, see Example 30–18.

      • Do not enable the audit service. You enable the audit service after the non-global zones are configured for auditing.

2. In each non-global zone, configure the audit files.

   ---

   Note –

   If you are planning to disable auditing in the non-global zone, you can skip this step. To disable auditing, see Example 30–25.

   ---

   1. Complete the tasks in Configuring Audit Files (Task Map).

   2. Follow the procedures that are described in Configuring and Enabling the Audit Service (Task Map).

   3. Do not configure system-wide audit settings.

      Specifically, do not add the perzone or ahlt policy to the non-global zone's audit_startup file. And do not run the bsmconv command from the non-global zone.

   4. Enable auditing in your zone.

      When the global zone reboots after auditing is configured, auditing is automatically enabled in your zone.

      If the global zone administrator activates the perzone audit policy after the system is booted, individual zone administrators must enable auditing. For details, see Example 30–20.

3. In the global zone, enable the audit service.

   For the procedure, see How to Enable the Audit Service.

Example 30–25 Disabling Auditing in a Non-Global Zone

This example works if the global zone has set the perzone audit policy. The zone administrator of the noaudit zone disables auditing for that zone. Because the administrator planned to disable auditing, she did not edit the audit configuration files.

noauditzone # svcadm disable svc:/system/auditd

Managing Audit Records (Task Map)

The following task map points to procedures for selecting, analyzing, and managing audit records.

Managing Audit Records

By managing the audit trail, you can 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.

How to Display Audit Record Formats

To write scripts that can find the audit data that you want, you need to know the order of tokens in an audit event. The bsmrecord command displays the audit event number, audit class, selection mask, and record format of an audit event.

1. Put the format of all audit event records in an HTML file.

   The -a option lists all audit event record formats. The -h option puts the list in HTML format that can be displayed in a browser.

   % bsmrecord -a -h > audit.events.html

   When you display the *html file in a browser, use the browser's Find tool to find specific records.

   For more information, see the bsmrecord(1M) man page.

Example 30–26 Displaying the Audit Record Formats of a Program

In this example, the format of all audit records that are generated by the login program are displayed. The login programs include rlogin, telnet, newgrp, role login to the Solaris Management Console, and Solaris Secure Shell.

% bsmrecord -p login
login: logout
  program     various              See login(1)
  event ID    6153                 AUE_logout
…

newgrp
  program     newgrp               See newgrp login
  event ID    6212                 AUE_newgrp_login
…

rlogin
  program     /usr/sbin/login      See login(1) - rlogin
  event ID    6155                 AUE_rlogin
…

SMC: role login
  program     SMC server           See role login
  event ID    6173                 AUE_role_login
…

/usr/lib/ssh/sshd
  program     /usr/lib/ssh/sshd    See login - ssh
  event ID    6172                 AUE_ssh
…

telnet login
  program     /usr/sbin/login      See login(1) - telnet
  event ID    6154                 AUE_telnet
  …

Example 30–27 Displaying the Audit Record Formats of an Audit Class

In this example, the format of all audit records in the fd class are displayed.

% bsmrecord -c fd

rmdir
  system call rmdir                See rmdir(2)
  event ID    48                   AUE_RMDIR
  class       fd                   (0x00000020)
      header
      path
      [attribute]
      subject
      [use_of_privilege]
      return

unlink
  system call unlink               See unlink(2)
  event ID    6                    AUE_UNLINK
  …

unlinkat
  system call unlinkat             See openat(2)
  event ID    286                  AUE_UNLINKAT
  …

How to Merge Audit Files From the Audit Trail

By merging all audit files in all the audit directories, you can analyze the contents of the entire audit trail. The auditreduce command merges all the records from its input files into a single output file. The input files can then be deleted. When the output file is placed in a directory that is named /etc/security/audit/server-name/files, the auditreduce command can find the output file without your specifying the full path.

This procedure applies only to binary audit records.

1. Assume a role that includes the Audit Review profile, or become superuser.

   The System Administrator role includes the Audit Review profile. You can also create a separate role that includes the Audit Review profile. To create a role and assign the role to a user, see Configuring RBAC (Task Map).

2. Create a directory for storing merged audit files.

   # mkdir audit-trail-directory

3. Limit access to the directory.

   # chmod 700 audit-trail-directory # ls -la audit-trail-directory drwx------ 3 root sys 512 May 12 11:47 . drwxr-xr-x 4 root sys 1024 May 12 12:47 ..

4. Merge the audit records in the audit trail.

   Change directories to the audit-trail-directory and merge the audit records into a file with a named suffix. All directories that are listed in the dir lines of the audit_control file on the local system are merged.

   # cd audit-trail-directory # auditreduce -Uppercase-option -O suffix

   The uppercase options to the auditreduce command manipulate files in the audit trail. The uppercase options include the following:

   -A

   Selects all of the files in the audit trail.

   -C

   Selects complete files only. This option ignores files with the suffix not_terminated.

   -M

   Selects files with a particular suffix. The suffix can be a machine name, or it can be a suffix that you have specified for a summary file.

   -O

   Creates an audit file with 14-character timestamps for both the start time and the end time, with the suffix suffix in the current directory.

Example 30–28 Copying Audit Files to a Summary File

In the following example, the System Administrator role, sysadmin, copies all files from the audit trail into a merged file.

$ whoami
sysadmin
$ mkdir /var/audit/audit_summary.dir
$ chmod 700 /var/audit/audit_summary.dir
$ cd /var/audit/audit_summary.dir
$ auditreduce -A -O All
$ ls *All
20030827183214.20030827215318.All

In the following example, only complete files are copied from the audit trail into a merged file.

$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O Complete
$ ls *Complete
20030827183214.20030827214217.Complete

In the following example, only complete files are copied from the example1 machine into a merged file.

$ cd /var/audit/audit_summary.dir
$ auditreduce -M example1 -O example1summ
$ ls *summ
20030827183214.20030827214217.example1summ

Example 30–29 Moving Audit Files to a Summary File

The -D option to the auditreduce command deletes an audit file when you copy it to another location. In the following example, the complete audit files from one system are copied to the summary directory for later examination.

$ cd /var/audit/audit_summary.dir
$ auditreduce -C -O daily_example1 -D example1
$ ls *example1
20030827183214.20030827214217.daily_example1

The audit files from the example1 system that were the input to the *daily_example1 file are removed when this command successfully completes.

How to Select Audit Events From the Audit Trail

You can filter audit records for examination. For the complete list of filtering options, see the auditreduce(1M) man page.

1. Assume a role that includes the Audit Review profile, or become superuser.

   The System Administrator role includes the Audit Review profile. You can also create a separate role that includes the Audit Review profile. To create a role and assign the role to a user, see Configuring RBAC (Task Map).

2. Select the kinds of records that you want from the audit trail, or from a specified audit file.

   auditreduce -lowercase-option argument [optional-file]

   argument

   Specific argument that a lowercase option requires. For example, the -c option requires an argument of an audit class, such as ua.

   -d

   Selects all of the events on a particular date. The date format for argument is yyymmdd. Other date options, -b and -a, select events before and after a particular date.

   -u

   Selects all of the events attributable to a particular user. The argument is a user name. Another user option, -e, selects all of the events attributable to an effective user ID.

   -c

   Selects all of the events in a preselected audit class. The argument is an audit class name.

   -m

   Selects all of the instances of a particular audit event. The argument is an audit event.

   optional-file

   Is the name of an audit file.

Example 30–30 Combining and Reducing Audit Files

The auditreduce command can eliminate the less interesting records as it combines the input files. For example, you might use the auditreduce command 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 the trail from backup media.

# cd /var/audit/audit_summary.dir
# auditreduce -O lo.summary -b 20030827 -c lo; compress *lo.summary

Example 30–31 Copying na Audit Records to a Summary File

In this example, all the records of nonattributable audit events in the audit trail are collected into one file.

$ whoami
sysadmin
$ cd /var/audit/audit_summary.dir
$ auditreduce -c na -O nasumm
$ ls *nasumm
20030827183214.20030827215318.nasumm

The merged nasumm audit file is time stamped with the beginning and ending date of the na records.

Example 30–32 Finding Audit Events in a Specified Audit File

You can select audit files manually to search just the named set of files. For example, you can further process the *nasumm file in the previous example to find system boot events. To do so, you would specify the file name as the final argument to the auditreduce command.

$ auditreduce -m 113 -O systemboot 20030827183214.20030827215318.nasumm
20030827183214.20030827183214.systemboot

The 20030827183214.20030827183214.systemboot file contains only system boot audit events.

Example 30–33 Copying One User's Audit Records to a Summary File

In this example, the records in the audit trail that contain the name of a particular user are merged. The -e option finds the effective user. The -u option finds the audit user.

$ cd /var/audit/audit_summary.dir
$ auditreduce -e tamiko -O tamiko

You can look for specific events in this file. In the following example, what time the user logged in and out on Sept 7, 2003, your time, is checked. Only those files with the user's name as the file suffix are checked. The short form of the date is yyyymmdd.

# auditreduce -M tamiko -O tamikolo -d 20030907 -u tamiko -c lo

Example 30–34 Copying Selected Records to a Single File

In this example, login and logout messages for a particular day are selected from the audit trail. The messages are merged into a target file. The target file is written in a directory other than the normal audit root directory.

# auditreduce -c lo -d 20030827 -O /var/audit/audit_summary.dir/logins
# ls /var/audit/audit_summary.dir/*logins
/var/audit/audit_summary.dir/20030827183936.20030827232326.logins

How to View the Contents of Binary Audit Files

The praudit command enables you to view the contents of binary audit files. You can pipe the output from the auditreduce command, or you can read a particular audit file. The -x option is useful for further processing.

1. Assume a role that includes the Audit Review profile, or become superuser.

   The System Administrator role includes the Audit Review profile. You can also create a separate role that includes the Audit Review profile. To create a role and assign the role to a user, see Configuring RBAC (Task Map).

2. Use one of the following praudit commands to produce the output that is best for your purposes.

   The following examples show praudit output from the same audit event. Audit policy has been set to include the sequence and trailer tokens.

   • The praudit -s command displays audit records in a short format, one token per line. Use the -l option to place each record on one line.

     $ auditreduce -c lo | praudit -s header,101,2,AUE_rlogin,,example1,2003-10-13 11:23:31.050 -07:00 subject,jdoe,jdoe,staff,jdoe,staff,749,749,195 1234 server1 text,successful login return,success,0 sequence,1298

   • The praudit -r command displays audit records in their raw format, one token per line. Use the -l option to place each record on one line.

     $ auditreduce -c lo | praudit -r 21,101,2,6155,0x0000,192.168.60.83,1062021202,64408258 36,2026700,2026700,10,2026700,10,749,749,195 1234 192.168.60.17 40,successful login 39,0,0 47,1298

   • The praudit -x command displays audit records in XML format, one token per line. Use the -l option to place the XML output for one record on one line.

     $ auditreduce -c lo | praudit -x <record version="2" event="login - rlogin" host="example1" time="Wed Aug 27 14:53:22 PDT 2003" msec="64"> <subject audit-uid="jdoe" uid="jdoe" gid="staff" ruid="jdoe" rgid="staff" pid="749" sid="749" tid="195 1234 server1"/> <text>successful login</text> <return errval="success" retval="0"/> <sequence seq-num="1298"/> </record>

Example 30–35 Printing the Entire Audit Trail

With a pipe to the lp command, the output for the entire audit trail goes to the printer. The printer should have limited access.

# auditreduce | praudit | lp -d example.protected.printer

Example 30–36 Viewing a Specific Audit File

In this example, a summary login file is examined in a terminal window.

# cd /var/audit/audit_summary.dir/logins
# praudit 20030827183936.20030827232326.logins | more

Example 30–37 Putting Audit Records in XML Format

In this example, the audit records are converted to XML format.

# praudit -x 20030827183214.20030827215318.logins > 20030827.logins.xml

The *xml file can be displayed in a browser. The contents of the file can be operated on by a script to extract the relevant information.

Troubleshooting

A message similar to the following indicates that you do not have enough privilege to use the praudit command:

praudit: Can't assign 20090408164827.20090408171614.example1 to stdin.

How to Clean Up a not_terminated Audit File

Occasionally, an audit daemon exits 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 timestamp, even though the file is no longer used for audit records. Use the auditreduce -O command to give the file the correct timestamp.

1. List the files with the not_terminated string on your audit file system in order of creation.

   # ls -R1t audit-directory*/files/* | grep not_terminated

   -R

   Lists files in subdirectories.

   -t

   Lists files from most recent to oldest.

   -1

   Lists the files in one column.

2. Clean up the old not_terminated file.

   Specify the name of the old file to the auditreduce -O command.

   # auditreduce -O system-name old-not-terminated-file

3. Remove the old not_terminated file.

   # rm system-name old-not-terminated-file

Example 30–38 Cleaning Up Closed not_terminated Audit Files

In the following example, not_terminated files are found, renamed, then the originals are removed.

ls -R1t */files/* | grep not_terminated
…/egret.1/20030908162220.not_terminated.egret
…/egret.1/20030827215359.not_terminated.egret
# cd */files/egret.1
# auditreduce -O egret 20030908162220.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Input (old) audit file
20030827215359.not_terminated.egret
# rm 20030827215359.not_terminated.egret
# ls -1t
20030908162220.not_terminated.egret Current audit file
20030827230920.20030830000909.egret Cleaned up audit file

The start timestamp on the new file reflects the time of the first audit event in the not_terminated file. The end timestamp reflects the time of the last audit event in the file.

How to Prevent Audit Trail Overflow

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

1. Set up a schedule to regularly archive audit files.

   Archive audit files by backing up the files to offline media. You can also move the files to an archive file system.

   If you are collecting text audit logs with the syslog utility, archive the text logs. For more information, see the logadm(1M) man page.

2. Set up a schedule to delete the archived audit files from the audit file system.

3. Save and store auxiliary information.

   Archive information that is necessary to interpret audit records along with the audit trail.

4. Keep records of which audit files have been archived.

5. Store the archived media appropriately.

6. 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 the auditreduce command. The summary files contain only records for specified types of audit events. To extract summary files, see Example 30–30 and Example 30–34.

Troubleshooting Solaris Auditing (Tasks)

This section covers various Solaris auditing error messages, preferences, and the auditing that is provided by other tools. These procedures can help you record the audit events that you require at your site.

Troubleshooting Solaris Auditing (Task Map)

The following task map points to procedures for troubleshooting Solaris auditing.

How to Determine That Solaris Auditing Is Running

If you believe that auditing has been activated, but no audit records are in your primary audit directory, try the following.

Before You Begin

You have correctly configured the hosts database in your naming service and it is functioning. To debug naming service problems, see the following:

• nsswitch.conf(4) man page

• System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

• System Administration Guide: Naming and Directory Services (NIS+)

1. Determine that auditing is running.

   • Verify that the c2audit kernel module is loaded.

     # modinfo | grep c2audit

     No listing indicates that auditing is not running. The following listing indicates that auditing is running:

     40 132ce90 14230 186 1 c2audit (C2 system call)

   • Verify that the audit daemon is running.

     Verify the status of the auditd service. The following listing indicates that auditing is not running:

     # svcs -x auditd svc:/system/auditd:default (Solaris audit daemon) State: disabled since Fri Aug 14 19:02:35 2009 Reason: Disabled by an administrator. See: http://sun.com/msg/SMF-8000-05 See: auditd(1M) See: audit(1M) Impact: This service is not running.

     The following listing indicates that the audit service is running:

     # svcs auditd STATE STIME FMRI online 10:10:10 svc:/system/auditd:default

   • Verify the current audit condition.

     The following listing indicates that auditing is not running:

     # auditconfig -getcond auditconfig: auditon(2) failed. auditconfig: error = Operation not supported(48)

     The following listing indicates that auditing is running:

     # auditconfig -getcond audit condition = auditing

   If the audit service is not running, enable it. For the procedure, see How to Enable the Audit Service.

2. Verify the syntax of the audit_control file.

   # audit -v /etc/security/audit_control audit: audit_control must have either a valid "dir:" entry or a valid "plugin:" entry with "p_dir:" specified.

   Correct the errors. The message syntax ok indicates that the file is syntactically correct.

3. Verify that the audit_control file has valid values for the flags and naflags keywords.

   # grep flags /etc/security/audit_control flags:lo naflags:na,lp

   Supply valid values if the audit_control file has invalid values. In the preceding example, lp is an invalid class.

4. Verify that the audit_user file has valid values for every user.

   # tail audit_user ... # User Level Audit User File # # File Format # # username:always:never # root:lo:no admin:lp:no

   Supply valid values if the audit_user file contains invalid values. In the preceding example, lp is an invalid class.

5. If you created a customized audit class, verify that you assigned events to the class.

   For example, the following audit_control file contains a class that Oracle Solaris software did not deliver:

   # grep flags /etc/security/audit_control flags:lo,pf naflags:na,lo

   For a description of creating the pf class, see How to Add an Audit Class.

   1. Verify that the class is defined in the audit_class file.

      The audit class mask must be unique.

      # grep pf /etc/security/audit_class 0x10000000:pf:profile command

      If the class is not defined, define it. Otherwise, remove the class from the audit_control and audit_user files.

   2. Verify that events have been assigned to the class.

      # grep pf /etc/security/audit_event 6180:AUE_prof_cmd:profile command:ua,as,pf

      If events are not assigned to the class, assign the appropriate events to this class.

6. If the previous steps did not indicate a problem, review the system log files, /var/adm/messages and /var/log/syslog.

   1. Locate and fix the problems.

   2. Then, if the audit service is running, restart it.

      # audit -s

   3. If the audit service is not running, enable it.

      For the procedure, see How to Enable the Audit Service.

How to Lessen the Volume of Audit Records That Are Produced

After you have determined which events must be audited at your site, use the following suggestions to create manageable audit files.

1. Use the default audit policy.

   Specifically, avoid adding events and audit tokens to the audit trail. The following policies affect the size of the audit trail.

   • arge policy – Adds environment variables to exec audit events.

   • argv policy – Adds command parameters to exec audit events.

   • public policy – If file events are being audited, adds an event to the audit trail every time an auditable event happens to a public file. File classes include fa, fc, fd, fm, fr, fw, and cl. For the definition of a public file, see Audit Terminology and Concepts.

   • path policy – Adds a path token to audit events that include an optional path token.

   • group policy – Adds a group token to audit events that include an optional newgroups token.

   • seq policy – Adds a sequence token to every audit event.

   • trail policy – Adds a trailer token to every audit event.

   • windata_down policy – On a system that is configured with Trusted Extensions, adds events when information in a labeled window is downgraded.

   • windata_up policy – On a system that is configured with Trusted Extensions, adds events when information in a labeled window is upgraded.

   • zonename policy – Adds the zone name to every audit event. If the global zone is the only configured zone, adds zone, global to every audit event.

   The following audit record shows the use of the ls command. The ex class is being audited and the default policy is in use:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

   The following is the same record when all policies are turned on:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls attribute,100555,root,bin,136,432,0 exec_args,1,ls exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root,PATH=/u sr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific path,/lib/ld.so.1 attribute,100755,root,bin,136,4289,0 subject,jdoe,root,root,root,root,1401,737,0 0 mach1 group,root,other,bin,sys,adm,uucp,mail,tty,lp,nuucp,daemon return,success,0 zone,global sequence,313540 trailer,375

2. Use the audit_syslog.so plugin to send some audit events to syslog.

   This strategy works only if you are not required to keep binary records of the audit events that you send to the syslog logs. By using the auditreduce command, you can then strip the binary files of these records, thus reducing the size of the binary files.

3. Use the audit_user file to audit events for specific users and roles.

   Reduce the amount of auditing for all users by reducing the number of audit classes in the audit_control file. In the audit_user file, add audit classes for specific users and roles.

4. Create your own customized audit class.

   You can create audit classes at your site. Into these classes, put all the audit events that you need to monitor. For the procedure, see How to Add an Audit Class.

   ---

   Note –

   If you modify existing audit class assignments, your modifications might be lost when you upgrade to a newer version of the Solaris OS. Carefully review the install logs.

   ---

How to Audit All Commands by Users

As part of site security policy, some sites require audit records of all commands that are run by the root user or by administrative roles. Some sites also require audit records of all commands that are run by users.

1. Audit the lo and ex classes.

   The ex class audits all calls to the exec() and execve() functions. The lo class audits logins, logouts, and screen locks. The following ouput lists all the events in the ex and lo classes.

   7:AUE_EXEC:exec(2):ps,ex 23:AUE_EXECVE:execve(2):ps,ex ... 6152:AUE_login:login - local:lo 6153:AUE_logout:logout:lo 6154:AUE_telnet:login - telnet:lo 6155:AUE_rlogin:login - rlogin:lo 6158:AUE_rshd:rsh access:lo 6159:AUE_su:su:lo 6162:AUE_rexecd:rexecd:lo 6163:AUE_passwd:passwd:lo 6164:AUE_rexd:rexd:lo 6165:AUE_ftpd:ftp access:lo 6171:AUE_ftpd_logout:ftp logout:lo 6172:AUE_ssh:login - ssh:lo 6173:AUE_role_login:role login:lo 6212:AUE_newgrp_login:newgrp login:lo 6213:AUE_admin_authenticate:admin login:lo 6221:AUE_screenlock:screenlock - lock:lo 6222:AUE_screenunlock:screenlock - unlock:lo 6227:AUE_zlogin:login - zlogin:lo

   • To audit these classes for administrators, modify the audit_user file.

     In the following example, the site has created three roles, sysadm, auditadm, and netadm. These roles and the root account are audited for the exec and lo classes:

     ## audit_user file root:lo,ex:no sysadm:lo,ex:no auditadm:lo,ex:no netadm:lo,ex:no

   • To audit the lo class for non-attributable events, modify the audit_control file.

     ## audit_control file ... naflags:lo ...

   • To audit these classes for all users, modify the audit_control file.

     ## audit_control file flags:lo,ex naflags:lo ...

     The output appears similar to the following:

     header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

2. To record the arguments to commands, set the argv policy.

   ## audit_startup script ... auditconfig -setpolicy +argv ...

   The exec_args token records the command arguments:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls exec_args,1,ls subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

3. To record the environment in which the command is run, set the arge policy.

   ## audit_startup script ... auditconfig -setpolicy +arge ...

   The exec_env token records the command environment:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root, PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

4. To record the arguments and the command environment, set both policies.

   ## audit_startup script ... auditconfig -setpolicy +argv auditconfig -setpolicy +arge ...

   The output appears similar to the following:

   header,375,2,execve(2),,mach1,2009-08-06 11:19:57.388 -07:00 path,/usr/bin/ls exec_args,1,ls exec_env,9,HOME=/,HZ=,LANG=C,LOGNAME=root,MAIL=/var/mail/root, PATH=/usr/sbin:/usr/bin,SHELL=/sbin/sh,TERM=xterm,TZ=US/Pacific subject,jdoe,root,root,root,root,1401,737,0 0 mach1 return,success,0

How to Find Audit Records of Changes to Specific Files

If your goal is to log file writes against a limited number of files, such as /etc/passwd and the files in the /etc/default directory, you use the auditreduce command to locate the files.

1. Audit the fw class.

   Adding the class to the audit_user file generates fewer records than adding the class to the audit_control file.

   • Add the fw class to the audit_user file.

     ## audit_user file root:fw:no sysadm:fw:no auditadm:fw:no netadm:fw:no

   • Add the fw class to the audit_control file.

     ## audit_control file flags:lo,fw ...

2. To find the audit records for specific files, use the auditreduce command.

   # /usr/sbin/auditreduce -o file=/etc/passwd,/etc/default -O filechg

   The auditreduce command searches the audit trail for all instances of the file argument. The command creates a binary file with the suffix filechg which contains all records that include the pathnames of the files of interest. See the auditreduce(1M) man page for the syntax of the -o file=pathname option.

3. To read the filechg file, use the praudit command.

   # /usr/sbin/praudit *filechg

How to Modify a User's Preselection Mask

If you modify the audit_control or audit_user file, the preselection mask of users who are already logged in does not change. You must force the preselection mask to change.

Before You Begin

You enabled auditing, users logged in, and then you changed the value of flags or naflags in the audit_control file. You want the users who are already logged in to be audited for these newly selected audit classes.

1. Update the preselection mask of users who are already logged in.

   You have two options. You can terminate the existing sessions or use the auditconfig command to update the users' preselection masks.

   • Terminate the users' existing sessions.

     Users can log out and log back in, or the administrator can manually terminate (kill) active sessions. The new sessions will inherit the new preselection mask. However, terminating users could be impractical.

   • Dynamically change each user's preselection mask.

     Assume that the flags attribute in the audit_control file was changed from lo to lo,ex.

     1. Determine the user's audit ID and audit session ID.

        First, find all regular users. In the following example, the administrator finds all processes that are not owned by root, daemon, or lp:

        # /usr/bin/pgrep -v -u root,daemon,lp | more .. 3941 3948 3949 10640 ...

        Then, use one of the user's processes to find the user's audit ID:

        # auditconfig -getpinfo 3941 audit id = jdoe(1002) process preselection mask = lo(0x1000,0x1000) terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234) audit session id = 713

        Note that the user's preselection mask includes the lo class and does not include the newly added ex class.

     The user's audit ID is 1002. The user's audit session ID is 713.

2. Change the user's preselection mask

   Use one of the following two methods:

   • Use the user's audit session ID to change the user's preselection mask.

     # /usr/sbin/auditconfig -setsmask lo,ex 713

   • Use the user's audit ID to change the user's preselection mask.

     # /usr/sbin/auditconfig -setumask lo,ex 1002

3. Verify that the preselection mask has changed.

   # auditconfig -getpinfo 3941 audit id = jdoe(1002) process preselection mask = ex,lo(0x40001000,0x40001000) terminal id (maj,min,host) = 9426,65559,mach1(192.168.123.234) audit session id = 713

How to Prevent the Auditing of Certain Events

For maintenance purposes, sometimes a site wants to prevent audit events from being audited.

1. Change the class of the event to the no class.

   For example, events 26 and 27 belong to the pm class.

   ## audit_event file ... 25:AUE_VFORK:vfork(2):ps 26:AUE_SETGROUPS:setgroups(2):pm 27:AUE_SETPGRP:setpgrp(2):pm 28:AUE_SWAPON:swapon(2):no ...

   Change these events to the no class.

   ## audit_event file ... 25:AUE_VFORK:vfork(2):ps 26:AUE_SETGROUPS:setgroups(2):no 27:AUE_SETPGRP:setpgrp(2):no 28:AUE_SWAPON:swapon(2):no ...

   If the pm class is currently being audited, existing sessions will still audit events 26 and 27. To stop these events from being audited, you must update the users' preselection masks.

   ---

   Caution –

   Never comment out events in the audit_event file. This file is used by the praudit command to read binary audit files. Archived audit files might contain events that are listed in the file.

   ---

2. To update the preselection masks of users, follow the instructions in How to Modify a User's Preselection Mask.

How to Limit the Size of Binary Audit Files

Binary audit files grow without limit. For ease of archiving and searching, you might want to limit the size. You can also create smaller binary files from the original file.

1. Starting in the Solaris 10 10/08 release, use the p_fsize attribute to limit the size of individual binary audit files.

   The p_fsize attribute to the audit_binfile.so plugin enables you to limit the size of an audit file. The default value is zero (0), which allows the file to grow without limit. The value is specified in bytes, from 512,000 to 2,147,483,647. When the specified size is reached, the current audit file is closed and a new file is opened.

   In the following example, you limit the size of and audit file to 1Mbyte:

   plugin:name=audit_binfile.so; p_dir:/var/audit; p_fsize=1024000

2. Use the auditreduce command to select records and write those records to a file for further analysis.

   The auditreduce -lowercase options find specific records.

   The auditreduce -Uppercase options write your selections to a file. For more information, see the auditreduce(1M) man page.

How to Audit Logins From Other OSes

The Solaris OS can audit all logins, independent of source.

1. Audit the lo class for attributable and for non-attributable events.

   This class audits logins, logouts, and screen locks.

   ## audit_control file flags:lo naflags:lo ...

   ---

   Note –

   To audit ssh logins, your Solaris system must be running the Solaris ssh daemon. This daemon is modified for Solaris auditing. For more information, see Solaris Secure Shell and the OpenSSH Project.

   ---

How to Audit FTP and SFTP File Transfers

The FTP service creates logs of its file transfers. The SFTP service, which runs under the SSH protocol, can be audited by Solaris auditing. Logins to both services can be audited by Solaris auditing.

1. To log commands and file transfers of the FTP service, see the ftpaccess(4) man page.

   For the available logging options, read the “Logging Capabilities” section. In particular, the log commands and log transfers options might provide useful logs.

2. To log sftp file transfers, perform one or both of the following:

   • Audit file-reads.

     File transfers over an SSH connection use the sftp command. These transfers can be recorded by using the +fr audit flag. To audit failed sftp file transfers, audit the -fr audit flag.

     The following output is from a successful sftp session:

     header,138,2,open(2) - read,,ma2,2009-08-25 14:48:58.770 -07:00 path,/home/jdoe/vpn_connect attribute,100644,jdoe,staff,391,437,0 subject,jdoe,jdoe,staff,jdoe,staff,4444,120289379,8457 65558 ma1 return,success,6

   • Use the verbose option to the sftp command.

     The -v option can be repeated up to three times.

     # sftp -vvv [ other options ] hostname

3. To record access to the FTP and SFTP services, audit the lo class.

   As the following output indicates, logging in to and out of the ftpd daemon generates audit records.

   % bsmrecord -c lo | more ... in.ftpd program /usr/sbin/in.ftpd See ftp access event ID 6165 AUE_ftpd class lo (0x00001000) header subject [text] error message return in.ftpd program /usr/sbin/in.ftpd See ftp logout event ID 6171 AUE_ftpd_logout class lo (0x00001000) header subject return ...

   The SSH login records all accesses to the sftp command.

   ... /usr/lib/ssh/sshd program /usr/lib/ssh/sshd See login - ssh event ID 6172 AUE_ssh class lo (0x00001000) header subject [text] error message return