Written by J. Moellenkamp
on 
Reading time: 4 minutes
English

Less known Solaris features: Auditing

One of the less known features in Solaris is the Auditing. Auditing solves an important problem: What happens on my system, and whodunnit. When something strange happens on your system or you recognize, that you are not the only one who owns your system, it´s a good thing to have some logs for analysis. The nice thing about the auditing in Solaris: It´s quite simple to activate. In the this article i will give you a short overview to enable and use the auditing in Solaris. This feature is really old, it´s in Solaris for since the last century but nevertheless it´s a less known Solaris feature. Some terms
There are some special terms in auditing. I want to give you a short definition of them as i have to use them in this article. I´ve copied this definitions from the manual for Solaris Auditing.

Configuring basic auditing
You have to search for a place in your filesystem. It´s a good practice to use an own filesystem, as auditing will eat away your filesystem space until there is nothing left and this is a bad idea for the root file system. But in this example i will omit this step. At first login as root. Okay, you need a place to store the audit logs. It´s important to change the rights of the directory to assure only root can access it.

mkdir /var/audit/aragorn-sol<br />
chmod -R 750 /var/audit/aragorn-sol

Then go to to /etc/security and edit the file /etc/security/audit_control. This file controls where what classes of information are logged and where you write the log. For example: The lo is the audit class for all events in regard of logins and logoffs:

dir:/var/audit/aragorn-sol<br />
flags:lo<br />
minfree:20<br />
naflags:lo

Okay, configuration is done.But let´s have another look the file /etc/security/audit_startup. The commands in this script control the audit policies and thus the behaviour of the logging and the amount of informations in the log records:

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

The second line is the most interesting. Without this line the system would stop user interaction when the system is unable to log. You would deactivate this behaviour, when logging is more important than system availability. For the moment we don´t change this file. Start the auditing
Now activate auditing. You have to reboot after the activation.

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

Two short checks … auditd runs …

# svcs | grep "auditd"<br />
online         23:30:03 svc:/system/auditd:default

… and the system starts to gather audit logs

<br />
# ls -la<br />
total 6<br />
drwxr-x---   2 root     root         512 Feb  1 23:30 .<br />
drwxr-xr-x   3 root     sys          512 Feb  1 23:18 ..<br />
-rw-r-----   1 root     root         255 Feb  1 23:33 20080201223003.not_terminated.aragorn-sol<br />

Okay, now you have completed the configuration. The system has started to write audit logs. Managing the audit logs
Audit logs grows infinitly. To the maximum filesize in the used filesystem or the end of disk capacity … whatever occurs first. It´s a good practice to checkpoint the audit logs in a regular interval. It´s quite simple:

audit -n

With this command the actual file gets closed and a new one gets opened.

# cd /var/audit/aragorn-sol/<br />
# ls -l<br />
total 24<br />
-rw-r-----   1 root     root         684 Feb  1 23:55 20080201223003.20080201225549.aragorn-sol<br />
-rw-r-----   1 root     root         571 Feb  2 00:06 20080201225549.20080201230639.aragorn-sol<br />
-rw-r-----   1 root     root        2279 Feb  2 00:10 20080201230834.20080201231010.aragorn-sol<br />
-rw-r-----   1 root     root         755 Feb  2 00:12 20080201231010.20080201231245.aragorn-sol<br />
-rw-r-----   1 root     root        4274 Feb  2 08:36 20080201231245.20080202073624.aragorn-sol<br />
-rw-r-----   1 root     root         200 Feb  2 08:36 20080202073624.not_terminated.aragorn-sol

Analysing the audit trails
It doesn´t make sense to create audit logs without looking at them. You can´t look directly at them as this file are binary ones. You need to command to analyse the audit log. One to extract the data out of the log files based on certain rules and one command to translate it into an human readable format.
You use the auditreduce command for the first step, and the praudit command for the second one.

# cd /var/audit/aragorn-sol<br />
auditreduce * | praudit -s

This sequence of commands translate all you audit logs into an human readable form. I´ve cut out some of the lines for an example:

header,69,2,AUE_ssh,,localhost,2008-02-01 23:49:17.687 +01:00<br />
subject,jmoekamp,jmoekamp,other,jmoekamp,other,720,3447782834,6969 5632 10.211.55.2<br />
return,success,0<br />
header,77,2,AUE_su,,localhost,2008-02-01 23:49:55.336 +01:00<br />
subject,jmoekamp,root,other,jmoekamp,other,729,3447782834,6969 5632 10.211.55.2<br />
text,root<br />
return,failure,Authentication failed<br />
header,69,2,AUE_su,,localhost,2008-02-01 23:50:11.311 +01:00<br />
subject,jmoekamp,root,root,root,root,730,3447782834,6969 5632 10.211.55.2<br />
return,success,0

What tells this snippet to you: I´ve logged into my system as the user jmoekamp, tried to assume root privileges, failed the first time (due wrong password), tried it again and succeeded. More auditing
Sometimes it´s important to know what users have done on you system. For example: Which programs has been executed. With Solaris auditing it´s really easy to collect this information. At first you have to configure auditing to collect this kind of information:

dir:/var/audit/aragorn-sol<br />
flags:lo,ex<br />
minfree:20<br />
naflags:lo,ex

The ex audit class matches to all events in system in regard to the execution of a program. This tells the auditing subsystem to log all execve() system calls. But you have to signal this change to the audit subsystem to start the auditing of this events. With audit -s you notify the audit daemon to read the /etc/security/audit_control file again.

header,113,2,AUE_EXECVE,,localhost,2008-02-02 00:10:00.623 +01:00<br />
path,/usr/bin/ls<br />
attribute,100555,root,bin,26738688,1380,0<br />
subject,jmoekamp,root,root,root,root,652,2040289354,12921 71168 10.211.55.2<br />
return,success,0

But this configuration only logs the path of the command, not the command line parameters. You have to configure to log this information. You remember: The audit policy controls the kind of information in the audit logs. Thus we have to modify the audit policy. With the command auditconfig -setpolicy +argv you change the policy. You don´t have to activate it, it´s immediately effective:

header,124,2,AUE_EXECVE,,localhost,2008-02-02 00:12:49.560 +01:00<br />
path,/usr/bin/ls<br />
attribute,100555,root,bin,26738688,1380,0<br />
exec_args,2,ls,-l<br />
subject,jmoekamp,root,root,root,root,665,2040289354,12921 71168 10.211.55.2<br />
return,success,0

To make this behaviour persistent, you have add the auditconfig -setpolicy +argv to the file
Want to learn more?
This is only a really short introduction to the topic. You will find the documentation for this feature at docs.sun.com: Part VII Solaris Auditing of System Administration Guide: Security Services is a good place to start.