Solaris Auditing
Solaris auditing helps to detect potential security breaches by revealing suspicious or abnormal patterns of system usage. Solaris auditing also provides a means to trace suspect actions back to a particular user, thus serving as a deterrent. Users who know that their activities are being audited are less likely to attempt malicious activities. The CIS Solaris 10 Security Benchmark enabled and configured Solaris Auditing in a section titled “Enable Kernel Level Auditing”.
Audit Policy Configuration
In addition to selecting which events to audit, globally or for specific users, Solaris Auditing also supports a number of other configuration options. These configuration options are specified using the auditconfig program and stored in the /etc/security/audit_startup
file. A few of the most often used policy settings are listed in the following table. For more information on each of these options as well as how they can be set, see auditconfig(1M).
Audit Policy Variable | Description |
---|---|
ahlt | Halt the machine if an asynchronous audit event occurs that cannot be delivered because the audit queue has reached the high-water mark or because there are insufficient resources to construct an audit record. By default, this option is not set and audit records are dropped (when either of these conditions occurs) and a count is kept of the number of dropped records. This count can be queried using the auditstat(1M) command. |
arge | Include the execv(2) system call environment arguments to the audit record. This information is not included by default in Solaris, but it is enabled by the CIS item titled “Enable Kernel Level Auditing”. |
argv | Include the execv(2) system call parameter arguments to the audit record. This information is not included by default in Solaris, but it is enabled by the CIS item titled “Enable Kernel Level Auditing”. |
public | Audit public files. By default, read- type operations are not audited for certain files which meet public characteristics: owned by root, readable by all, and not writable by all. This option, when enabled, helps to reduce some of the non-security relevant events or “noise” commonly found in audit trails. |
seq | Include the sequence token as part of every audit record. By default, the sequence token is not included. The sequence token attaches a sequence number to every audit record. |
zonename | Include the zonename token as part of every audit record. By default, the zonename token is not included. The zonename token gives the name of the zone from which the audit record was generated. |
Audit Record Selection and Display
Once Solaris Auditing has been enabled, organizations can use the audit trails to better understand what actions are being taken on their systems. In particular, the commands auditreduce(1M) and praudit(1M) can be used to select and display events respectively.
For example, the following audit record shows that the user mchurchi successfully used the su command to access a root shell in the global zone on egmp02-01:
# auditreduce -u mchurchi -m AUE_su | praudit -s header,104,2,AUE_su,,egmp02-1,2007-09-23 15:29:00.248 -04:00 subject,mchurchi,root,mchurchi,mchurchi,mchrchui,692,2868335681,0 0 egmp02-01 text,success for user root return,success,0 zone,global
This same information can also be represented in XML in the Solaris 10 OS:
# auditreduce -u mchurchi -m AUE_su | praudit -x <?xml version='1.0' encoding='UTF-8' ?> <?xml-stylesheet type='text/xsl' href='file:///usr/share/lib/xml/style/adt_record.xsl.1' ?> <!DOCTYPE audit PUBLIC '-//Sun Microsystems, Inc.//DTD Audit V1//EN' 'file:///usr/share/lib/xml/dtd/adt_record.dtd.1'> <audit> <file iso8601="2007-09-23 15:29:00.000 -04:00"></file> <record version="2" event="su" host="egmp02-01" iso8601="2007-09-23 15:29:00.248 -04:00"> <subject audit-uid="mchurchi" uid="root" gid="mchurchi" ruid="mchurchi" rgid="mchurchi" pid="692" sid="2868335681" tid="0 0 egmp02-01"/> <text>success for user root</text> <return errval="success" retval="0"/> <zone name="global"/> </record> <file iso8601="2007-09-23 15:29:00.000 -04:00"></file> </audit>
Similarly, in the Solaris 10 OS, Solaris Auditing can be configured to forward audit events to syslog. Regardless of whether the use of syslog has been configured, audit events are always also recorded on the local system. When using the syslog plugin, the above audit event would be recorded as:
Sep 23 15:29:00 egmp02-01 audit: [ID 702911 audit.notice] su ok session 2868335681 by mchurchi as root:mchurchi in global from egmp02-01 text success for user root
Resources
For more information on Solaris Auditing, see:
- OpenSolaris Community Project: Auditing http://www.opensolaris.org/os/project/audit/
- Solaris 10 System Administrator Collection: Auditing and Solaris Zones http://docs.sun.com/app/docs/doc/816-4557/6maosrjqv?a=view
- Sun BluePrint: Enforcing the Two-Person Rule using RBAC in the Solaris 10 OS http://www.sun.com/blueprints/0805/819-3164.pdf
- Sun Blog: Defining your own audit class http://blogs.sun.com/martin/entry/defining_your_own_audit_class
- Sun Blog: Measuring the impact of auditing http://blogs.sun.com/martin/entry/measuring_the_impact_of_auditing
- Sun Blog: How system calls are audited http://blogs.sun.com/martin/entry/how_system_calls_are_audited
- Sun Blog: ZFS the perfect file system for audit trails http://blogs.sun.com/martin/entry/zfs_the_perfect_file_system
- Sun Blog: How to determine if there are audit records in a crash dump http://blogs.sun.com/martin/entry/how_to_determine_if_there
- Sun Blog: Adding auditing to your application http://blogs.sun.com/martin/entry/adding_auditing_to_your_application http://blogs.sun.com/martin/entry/adding_auditing_to_your_application2