Solaris Audit Support

The Solaris operating environment supports auditing of system events, such as file access, process operations and network activity. With auditing enabled, the system provides an audit trail of selected events in the form of a log file, which can be monitored to detect unauthorized use of the system. Auditing in the Solaris operating environment is provided by the Basic Security Module (BSM). Refer to the Solaris documentation for information about configuring BSM.

To generate audit records for Secure Shell connections

  1. Verify that the Secure Shell (SSH) audit events are mapped to the correct audit class. The following line in the /etc/security/audit_event file defines that all Secure Shell events will belong to the login/logout class of events:

    6172:AUE_ssh:login - ssh:lo

    NOTE:If you are running Solaris 8, this entry does not exist, but must be added manually.

  2. Edit the /etc/security/audit_control file, which lets you define a system-wide audit setting for all users. Add the login/logout event class to the flags: section:

    flags:lo
  3. (Optional) If some users need special audit settings, or you want to remove auditing for only some users, you can edit the /etc/security/audit_user file. The entries are of the following form:

    user:always_audit-flags:never_audit_flags

    For example, the following entry in the /etc/security/audit_user file disables auditing for a user ‘joe’:

    joe::lo

To view the audit log

  1. Locate the audit log in:

    /var/audit

  2. Use the praudit command to read the binary file format:

    praudit audit_file

The audit entry for the Secure Shell login/logout events tells which user attempted to log in or out, from which host, and whether the connection succeeded or not.

Example 1

An entry for a user ‘joe’, logging on from host sphinx.company.com:

header,94,2,login - ssh,,Tue May 13 10:49:44 2010, + 863 msec
subject,joe,joe,other,joe,other,7763,7763,0 2805 sphinx.company.com
text,sshd login joe on /dev/pts/4
return,success,0

In this case, the user successfully logged on to the system, and was given a Secure Shell terminal session on /dev/pts/4.

Example 2

For Secure Shell logins not requiring a terminal session, such as remote commands or file transfers with scp or sftp, the terminal or tty number is replaced by the command the server executes on behalf of the user. For example:

header,116,2,login - ssh,,Tue May 13 10:49:58 2010, + 361 msec
subject,joe,joe,other,joe,other,7774,7774,0 2806 sphinx.company.com
text,sshd login joe on (no tty)
text,remote command: sftp
return,success,0

Example 3

An example of a failed login attempt:

header,81,2,AUE_ssh,,Tue May 13 11:22:51 2003, + 462 msec
subject,joe,joe,other,joe,other,8006,8006,0 0 sphinx.company.com
text,invalid password
return,failure: Interrupted system call,-1