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 auditing service
or reboot the local system to read changed configuration files after the auditing
service has been enabled. However, the recommended practice is to customize your audit
configuration as much as possible before you start the auditing 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.
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.
- 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.
- (Optional) Save a backup copy of the audit_control file.
# cp /etc/security/audit_control /etc/security/audit_control.orig
- 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. The dir line can be repeated.
For explanations of the keywords, see the following examples. For an example of a plugin entry, see How to Configure syslog Audit Logs
- value
Specifies data that is associated with the line type.
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
class are audited for all users.
# audit_control file
dir:/var/audit
flags:lo
minfree:20
naflags:lo
To see which events are in the lo class, read the audit_event
file. You can also use the bsmrecord command, as shown in Example 30-25.
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
dir:/var/audit
flags:lo
minfree:20
naflags:lo,na
Example 30-3 Specifying the Location of Binary Audit Data
The dir lines in the audit_control file list which audit file systems
to use for binary audit data. In this example, three locations for binary
audit data are defined.
# audit_control file
#
# Primary audit directory - NFS-mounted from audit server
dir:/var/audit/egret.1/files
#
# Secondary audit directory - NFS-mounted from audit server
dir:/var/audit/egret.2/files
#
# Directory of last resort local directory
dir:/var/audit
flags:lo
minfree:20
naflags:lo,na
plugin:
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.
# audit_control file
#
dir:/var/audit/examplehost.1/files
dir:/var/audit/examplehost.2/files
dir:/var/audit/localhost/files
flags:lo
minfree:10
naflags:lo,na
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 auditing service to collect only binary audit data, or
you can instruct the auditing service to collect binary data and text
data. In the following procedure, you collect binary audit data and text audit
data. The collected text audit data is a subset of the binary data.
Before You Begin
Preselected audit classes must be specified on the flags line or the naflags
line of the audit_control file. The text data is a subset of the
preselected binary data.
- 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.
- (Optional) Save a backup copy of the audit_control file.
# cp /etc/security/audit_control /etc/security/audit_control.save
- Add a plugin entry.
Plugins in the auditing service implement binary output and syslog output of audit data.
The binary plugin is not specified. The syslog plugin must be specified. For
more information, see auditd Daemon.
A plugin entry has the following format:
plugin:name=value; p_flags=classes
- value
Lists the name of the plugin to use. Currently, the only valid value is the audit_syslog.so.1 plugin.
- classes
Lists a subset of the audit classes that are specified in the flags line and the naflags line.
For more information about the plugin value, see the audit_syslog(5) man page.
- 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
Text logs should not be stored where the binary audit files are
stored. The auditreduce command assumes that all files in an audit partition are binary
audit files.
- Create the log file.
# touch /var/adm/auditlog
- Refresh the configuration information for the syslog service.
# svcadm refresh system/system-log
- Regularly archive the syslog log files.
The auditing 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_control file
dir:/var/audit/host.1/files
dir:/var/audit/host.2/files
dir:/var/audit/localhost/files
flags:lo,ss
minfree:10
naflags:lo,na
plugin:name=audit_syslog.so.1; p_flags=-lo,-na,-ss
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 plugin entry instructs
the syslog utility to collect only failed logins, failed nonattributable events, and failed
changes of system state.
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
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 name service database is
used. To calculate the user's final audit preselection mask, see Process Audit Characteristics.
- 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.
- (Optional) Save a backup copy of the audit_user database.
# cp /etc/security/audit_user /etc/security/audit_user.orig
- 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-7 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
minfree:10
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-8 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:
minfree:10
naflags:
The audit_user file preselects two audit classes for four users:
# audit_user file
jdoe:lo,pf
kdoe:lo,pf
pdoe:lo,pf
sdoe:lo,pf
The following audit_control file protects the system from 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:
minfree:10
naflags:lo
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.
- 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.
- (Optional) Save a backup copy of the audit_class file.
# cp /etc/security/audit_class /etc/security/audit_class.orig
- 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-9 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:
0x01000000:pf:profile command
The entry creates a new audit class that is called pf. Example 30-10
populates the new audit class.
Troubleshooting
If you have customized the audit_class database, 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.
- 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.
- (Optional) Save a backup copy of the audit_event file.
# cp /etc/security/audit_event /etc/security/audit_event.orig
- 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-10 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-9. 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
0x01000000: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_syslog.so.1; p_flags=-lo,-pf
Example 30-11 Auditing the Use of setuid Programs
This example creates a class to hold events that monitor calls to
the setuid and setgid programs. The audit_control entries audit all successful invocations
of the 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
...
flags:lo,+st
plugin:name=audit_syslog.so.1; p_flags=-lo,+st
