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.
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.
- Audit events: A security-related system action that is audited. For ease of selection, events are grouped into audit classes.
- Audit Class: A grouping of audit events. Audit classes provide a way to select a group of events to be audited.
- Audit policy: A set of auditing options that you can enable or disable at your site. These options include whether to record certain kinds of audit data. The options also include whether to suspend auditable actions when the audit trail is full.
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.
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:
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:
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.
Two short checks … auditd runs …
… and the system starts to gather audit logs
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:
With this command the actual file gets closed and a new one gets opened.
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.
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:
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.
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:
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.
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:
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.