Auditing

Someone recently asked on the opensolaris-help forum if it was possible to log ssh events into his OpenSolaris box. I provided a brief answer on how to use the OpenSolaris audit feature to track this information, but I thought a more thorough introduction to auditing may be warranted.

Determining What to Audit

Probably the most difficult part to auditing is figuring out what information you want to track. In the case of the forum post, it was very clear - ssh attempts, successful or unsuccessful, into the box. You have to be careful what you chose, because auditing can generate copious amounts of data.

Everything that occurs in OpenSolaris is associated with an event, and the types of events that can be audited are grouped into classes. The classes are defined in /etc/security/audit_class:

no:invalid class
fr:file read
fw:file write
fa:file attribute access
fm:file attribute modify
fc:file create
fd:file delete
cl:file close
nt:network
ip:ipc
na:non-attribute
lo:login or logout
ap:application
cy:cryptographic
ss:change system state
as:system-wide administration
ua:user administration
am:administrative (meta-class)
aa:audit utilization
ad:old administrative (meta-class)
ps:process start/stop
pm:process modify
pc:process (meta-class)
xp:X - privileged/administrative operations
xc:X - object create/destroy
xs:X - operations that always silently fail, if bad
xx:X - all X events (meta-class)
io:ioctl
ex:exec
ot:other
all:all classes (meta-class)

So, for example, if you just wanted to audit every time a file was deleted, you would configure to audit the fd class. For our example, we want the lo class, for logins and logouts of the system.

The actually system events that map to the audit classes are defined in /etc/security/audit_event, of which there are over 500 unique system events. A given event can map to one or more audit classes. The events that map to lo are as follows:

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
6228:AUE_su_logout:su logout:lo
6229:AUE_role_logout:role logout:lo
6244:AUE_smbd_session:smbd(1m) session setup:lo
6245:AUE_smbd_logoff:smbd(1m) session logoff:lo
9101:AUE_ClientConnect:client connection to x server:lo
9102:AUE_ClientDisconnect:client disconn. from x server:lo

Configuring the Audit

The classes you decide to audit are configured in /etc/security/audit_control. Below is the default content of the audit_control file: 

dir:/var/audit
flags:
minfree:20
naflags:lo

The default audit directory is /var/audit. You may wish to change this to another location, like an NFS mount to another server. We specify the classes we wish to audit with the flags property, so we will add lo to our file as follows:

dir:/var/audit
flags:lo
minfree:20
naflags:lo

The minfree property is the percentage of free space required before an audit warning script is invoked, which will generally be configured to send somebody an e-mail. See the audit_warn(1M) man page for how to work with the audit warning script.

The naflags (non-attributable flags) property is for events that cannot be attributed to a particular user, which is mainly programs that are launched during system boot.

Turning on the Audit

Turning on the audit requires running /etc/security/bsmconv and rebooting the machine:

bleonard@os200906:~$ pfexec /etc/security/bsmconv
This script is used to enable Solaris Auditing and device allocation.
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.

Solaris Auditing and device allocation is ready.
If there were any errors, please fix them now.
Configure Solaris Auditing and device allocation by editing files
located in /etc/security.
Reboot this system now to come up with auditing and device allocation enabled.
bleonard@os200906:~$ pfexec reboot

After reboot you'll have a single file in /var/audit:

bleonard@os200906:~$ ls /var/audit
20100621202538.not_terminated.os200906

To view the contents of the file, you need to use the print audit trail file utility, praudit:

bleonard@os200906:~$ pfexec praudit /var/audit/20100621202538.not_terminated.os200906 > audit.txt
bleonard@os200906:~$ cat audit.txt 
file,2010-06-21 16:25:38.984 -04:00,
header,44,2,system booted,na,2010-06-21 16:23:25.458 -04:00
text,booting kernel
header,69,2,login - local,,localhost,2010-06-21 16:27:25.183 -04:00
subject,bleonard,bleonard,staff,bleonard,staff,477,3112795690,0 0 localhost
return,success,0
header,69,2,login - local,,localhost,2010-06-21 16:28:24.881 -04:00
subject,bleonard,bleonard,staff,bleonard,staff,615,3530634311,0 0 localhost
return,success,

However, the audit trail data can also be extracted as XML and then converted to HTML for even better formatting:

bleonard@os200906:~$ pfexec praudit -x /var/audit/20100621202538.not_terminated.os200906 > audit.xml
bleonard@os200906:~$ xsltproc audit.xml > audit.html

Then just view the file in Firefox:

bleonard@os200906:~$ firefox audit.html &
[1] 1919

You can see in this short audit trail that I logged into OpenSolaris at 4:28 PM on Monday June 21st.

Modifying the Audit

If you decide you want to audit additional events, simply add those events to the audit_control file. For example, auditing executed commands is pretty popular audit option. Executed commands can be captured by adding the ex class.

dir:/var/audit
flags:lo,ex
minfree:20
naflags:lo

The audit_control file is read when a user logs in to the system. If we look at the audit configuration at this point, we'll see that we are still only auditing the lo class:

bleonard@os200906:~$ pfexec auditconfig -getaudit
audit id = bleonard(101)
process preselection mask = lo(0x1000,0x1000)
terminal id (maj,min,host) = 0,0,localhost(127.0.0.1)
audit session id = 3530634311

However, if we ssh into the machine, the audit configuration changes are picked up:

bleonard@os200906:~$ ssh -X bleonard@os200906
The authenticity of host 'os200906 (127.0.0.1)' can't be established.
RSA key fingerprint is 6c:c7:63:7f:dc:1f:33:1e:94:ee:eb:24:23:de:8f:90.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'os200906' (RSA) to the list of known hosts.
Password: 
Last login: Mon Jun 21 16:28:24 2010
Sun Microsystems Inc.   SunOS 5.11      snv_111b        November 2008
bleonard@os200906:~$ pfexec auditconfig -getaudit
audit id = bleonard(101)
process preselection mask = ex,lo(0x40001000,0x40001000)
terminal id (maj,min,host) = 12324,202240,localhost(127.0.0.1)
audit session id = 3339125594
So now run a command like zfs list -t all, and extract the audit trail again.


In the 3rd entry you can see /sbin/zfs was executed. What's also interesting is that in the first entry on the page you can see /usr/sbin/auditconfig was called. This is how our audit changes got picked up when we logged into the machine.

Audit Policy

In addition to the events that are selected for audit, you can also control the amount of data collected per audit event by setting an audit policy. The policy settings can be set dynamically using the auditconfig command, or permanently by setting the policy in the /etc/security/audit_startup file. One popular audit policy to set is +argv, which will include the arguments passed to any executed commands when auditing exec events.

For example, in the ZFS audit record above, we know that user bleonard executed a zfs command, but that's the extent of it. Did he take a snapshot, make a clone, export data...?

Turn on exec() arguments as follows:

bleonard@os200906:~$ pfexec auditconfig -setpolicy +argv

To permanently enable the +argv policy, add the command to audit_startup:

/usr/sbin/auditconfig -setpolicy +argv
Then run the command zfs list -t all again and regenerate the audit report:


Here we can see that EXEC_ARGS are now part of the audit trail and that the arguments list, -t and all were passed to zfs.

Stopping the Audit

The audit service is managed by SMF:

bleonard@os200906:~$ svcs -l auditd
fmri         svc:/system/auditd:default
name         Solaris audit daemon
enabled      true
state        online
next_state   none
state_time   Mon Jun 21 16:25:41 2010
logfile      /var/svc/log/system-auditd:default.log
restarter    svc:/system/svc/restarter:default
contract_id  73 
dependency   require_all/none svc:/system/filesystem/local (online)
dependency   require_all/none svc:/milestone/name-services (online)
dependency   require_all/none svc:/system/system-log (online)

So to stop it, simply:

bleonard@os200906:~$ svcadm disable auditd

Stopping the audit service will also terminate the log. When it's started again a new log file will get created.

Audit Review Script

Here's a convenience script to extract and display the audit records in HTML. After launching Firefox it refreshes the underlying HTML file every 10 seconds, so a browser refresh will show the latest records:

bleonard@os200906:~$ cat showauditlive
pfexec praudit -x /var/audit/\*not_term\* > audit.xml
xsltproc audit.xml > audit.html
firefox audit.html &
while [ true ]; do
        pfexec praudit -x /var/audit/\*not_term\* > audit.xml
        xsltproc audit.xml > audit.html
        sleep 10
done

This article just touched the surface of what's possible with auditing. For a more thorough discussion of auditing see the Solaris Auditing section of the System Administration Guide: Security Services.

Comments:

Worth mentioning that it can seriously impact server performance too. Worth benchmarking performance beforehand and comparing afterwards.

Posted by Matt Smith on June 22, 2010 at 11:16 AM GMT #

Good point Matt, thanks. Certainly when auditing the ev class. The lo class should not have an effect.

Posted by Brian Leonard on June 22, 2010 at 11:23 AM GMT #

Great post as usual Brian. You may want to check the following ARC case -

http://arc.opensolaris.org/caselog/PSARC/2009/354/

which indicates that bsmconv/unconv is obsolete and audit(1) and svc:/system/auditd:default and a reboot is no longer required.

Posted by Glynn Foster on June 22, 2010 at 02:44 PM GMT #

Yeah, thanks for mentioning that Glynn. Glenn Faden had told me about this. The changes appear to have gone into build 136:

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6192139

I'm still on build 111b :-).

Posted by Brian Leonard on June 23, 2010 at 07:49 AM GMT #

I wanted to audit su login and logout. I have done all the necessary configuration,however su_logout is not appearing in the audit log file. Please advise.

audit_event:
6172:AUE_ssh:login - ssh:lo
.
.
.
6228:AUE_su_logout:su logout:lo

audit_control:

dir:/var/audit
flags:lo
minfree:20
naflags:lo

audit_startup:

/usr/bin/echo "Starting BSM services."
/usr/sbin/auditconfig -setpolicy +cnt
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf

Thank you,
Raj

Posted by Raj on July 28, 2010 at 10:39 AM GMT #

vimp

Posted by veryimpauditingusers for solaris10 on November 14, 2010 at 11:10 PM GMT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

The Observatory is a blog for users of Oracle Solaris. Tune in here for tips, tricks and more as we explore the Solaris operating system from Oracle.

Connect with Oracle Solaris:


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
20
21
22
23
24
25
26
27
28
29
30
   
       
Today