Auditing in Solaris

 

One of the main principles of security is accountability. There are some problems associated with accountability, such as the difficulty in determining the security relevance of each user action. Another problem is searching through the collected data to find meaningful information.

 


An administrator who records selected events in the audit trail and monitors the audit logs is more likely to discover suspicious activity, and thereby prevent a system from being compromised. Additionally, an administrator can review the audit logs to determine what events transpired during an attack.

 

Auditing for Solaris OE merely provides a security conscious administrator one more tool to counter malicious intent.

 

Auditing Goals

 

The primary goal of auditing is recording user actions to detect malicious intent. Auditing may also act as a deterrent—for example, a malicious user may not take certain actions knowing that those actions will be recorded.

 

The secondary goal of auditing is to avoid performance degradation. The more audit events recorded, the greater the load on the system. By minimizing extraneous audit events, the impact on the CPU and I/O subsystems will be reduced.

 

Many computer installations have attempted to implement auditing, however, it is generally enabled as an afterthought. An administrator examines the list of audit events and picks those that appear relevant, but frequently doesn’t test whether this set of events produces comprehensive and useful information. Alternatively, when an integrated solution is delivered to a customer, the last thing to be enabled is auditing, and that is usually performed as the integration team is leaving the building.

 

Enabling Auditing

 

Auditing is not enabled by default in standard Solaris OE installations from CD or JumpStart™ software; it has to be explicitly enabled.

 

audit_class

 

An audit class is a group of audit events. All audit classes are defined in the /etc/security/audit_class file. All audit events are assigned to audit classes in the/etc/security/audit_event file. Audit classes are recorded in the audit trail if they are turned on globally in the audit_control file, or are assigned to a specific user in the audit_user database.

 

These audit classes are used by the audit_control, audit_user, and audit_event files, as well as in the audit mask

 

Audit Classes and Events

 

Login or Logout (lo)

 

This audit class captures all attempts (failed or successful) to login to the system.
The following is the list of audit events that map to this audit class:

    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
    6213:AUE_admin_authenticate:adminsuite access:lo

 

This audit class should almost always be selected by any site that implements auditing because the audit class records both the start and end of user interactions with the system.

 

To audit these classes for administrators, modify the audit_user file.

 

In the following example, the site has created three roles, sysadm, auditadm, and netadm. These roles and the root account are audited for the exec and lo classes:

 

## audit_user file
root:lo,ex:no
sysadm:lo,ex:no
auditadm:lo,ex:no
netadm:lo,ex:no

 

To audit these classes for all users, modify the audit_control file.

 

## audit_control file
flags:lo,ex
naflags:lo

 

Non-attribute (na)

 

This audit class captures non-attributable audit events. Notice the audit events that
map to this class:

    113:AUE_SYSTEMBOOT:system booted:na
    153:AUE_ENTERPROM:enter prom:na
    154:AUE_EXITPROM:exit prom:na
    6151:AUE_inetd_connect:inetd:na
    6156:AUE_mountd_mount:mount:na
    6157:AUE_mountd_umount:unmount:na

 

All sites should have an audit record of when a system was booted, and also whenever anyone enters the PROM mode. Mounting and unmounting of file systems should also be recorded. All sites should also record connections to the inetd. The inetd provides access to system services, and should be monitored.

 

Administrative (ad)

 

This audit class is for administrative actions, which can cover a variety of actions. The following is the audit events that map to this audit class:

    9:AUE_MKNOD:mknod(2):ad
    12:AUE_UMOUNT:umount(2) – old version:ad
    18:AUE_ACCT:acct(2):ad
    20:AUE_REBOOT:reboot(2):ad
    28:AUE_SWAPON:swapon(2):ad
    29:AUE_SETHOSTNAME:sethostname(2):ad
    37:AUE_SETTIMEOFDAY:settimeofday(2):ad
    50:AUE_ADJTIME:adjtime(2):ad
    53:AUE_NFS_SVC:nfs_svc(2):ad
    56:AUE_UNMOUNT:unmount(2):ad
    57:AUE_ASYNC_DAEMON:async_daemon(2):ad
    59:AUE_SETDOMAINNAME:setdomainname(2):ad
    60:AUE_QUOTACTL:quotactl(2):ad
    61:AUE_EXPORTFS:exportfs(2):ad
    62:AUE_MOUNT:mount(2):ad
    114:AUE_ASYNC_DAEMON_EXIT:async_daemon(2) exited:ad
    115:AUE_NFSSVC_EXIT:nfssvc(2) exited:ad
    131:AUE_SETAUID:setauid(2):ad
    133:AUE_SETAUDIT:setaudit(2):ad
    135:AUE_SETUSERAUDIT:setuseraudit(2):ad
    136:AUE_AUDITSVC:auditsvc(2):ad
    140:AUE_AUDITON_STERMID:auditon(2) – SETTERMID command:ad
    142:AUE_AUDITON_SPOLICY:auditon(2) – SPOLICY command:ad
    144:AUE_AUDITON_SESTATE:auditon(2) – SESTATE command:ad
    146:AUE_AUDITON_SQCTRL:auditon(2) – SQCTRL command:ad
    148:AUE_SETKERNSTATE:setkernstate(2):ad
    150:AUE_AUDITSTAT:auditstat(2):ad
    201:AUE_STIME:old stime(2):ad
    222:AUE_AUDITON_SETKMASK:auditon(2) – set kernel mask:ad
    226:AUE_AUDITON_SETSTAT:auditon(2) – reset audit statistics:ad
    227:AUE_AUDITON_SETUMASK:auditon(2) – set mask per uid:ad
    228:AUE_AUDITON_SETSMASK:auditon(2) – set mask per session ID:ad
    230:AUE_AUDITON_SETCOND:auditon(2) – set audit state:ad
    232:AUE_AUDITON_SETCLASS:auditon(2) – set event class:ad
    233:AUE_UTSSYS:utssys(2) – fusers:ad
    243:AUE_MODLOAD:modctl(2) – load module:ad
    244:AUE_MODUNLOAD:modctl(2) – unload module:ad
    245:AUE_MODCONFIG:modctl(2) – configure module:ad
    246:AUE_MODADDMAJ:modctl(2) – bind module:ad
    262:AUE_P_ONLINE:p_online(2):ad
    263:AUE_PROCESSOR_BIND:processor_bind(2):ad
    266:AUE_SETAUDIT_ADDR:setaudit_addr(2):ad
    268:AUE_UMOUNT2:umount2(2):ad
    6144:AUE_at_create:at-create atjob:ad
    6145:AUE_at_delete:at-delete atjob (at or atrm):ad
    6146:AUE_at_perm:at-permission:ad
    6147:AUE_cron_invoke:cron-invoke:ad
    6148:AUE_crontab_create:crontab-crontab created:ad
    6149:AUE_crontab_delete:crontab-crontab deleted:ad
    6150:AUE_crontab_perm:crontab-permisson:ad
    6160:AUE_halt_solaris:halt(1m):ad
    6161:AUE_reboot_solaris:reboot(1m):ad
    6166:AUE_init_solaris:init(1m):ad
    6167:AUE_uadmin_solaris:uadmin(1m):ad
    6168:AUE_shutdown_solaris:shutdown(1b):ad
    6169:AUE_poweroff_solaris:poweroff(1m):ad
    6170:AUE_crontab_mod:crontab-modify:ad
    6200:AUE_allocate_succ:allocate-device success:ad
    6201:AUE_allocate_fail:allocate-device failure:ad
    6202:AUE_deallocate_succ:deallocate-device success:ad
    6203:AUE_deallocate_fail:deallocate-device failure:ad
    6205:AUE_listdevice_succ:allocate-list devices success:ad
    6206:AUE_listdevice_fail:allocate-list devices failure:ad
    6207:AUE_create_user:create user:ad
    6208:AUE_modify_user:modify user:ad
    6209:AUE_delete_user:delete user:ad
    6210:AUE_disable_user:disable user:ad
    6211:AUE_enable_user:enable user:ad

 

While obtaining audit information is considered a privileged action, information from the following audit events does not provide anything adequately meaningful. In addition, some of these events are generated frequently. The following events should be excluded at most sites:

 

    130:AUE_GETAUID:getauid(2):no
    132:AUE_GETAUDIT:getaudit(2):no
    134:AUE_GETUSERAUDIT:getuseraudit(2):no
    139:AUE_AUDITON_GTERMID:auditon(2) – GETTERMID command:no
    141:AUE_AUDITON_GPOLICY:auditon(2) – GPOLICY command:no
    143:AUE_AUDITON_GESTATE:auditon(2) – GESTATE command:no
    145:AUE_AUDITON_GQCTRL:auditon(2) – GQCTRL command:no
    147:AUE_GETKERNSTATE:getkernstate(2):no
    149:AUE_GETPORTAUDIT:getportaudit(2):no
    221:AUE_AUDITON_GETKMASK:auditon(2) – get kernel mask:no
    223:AUE_AUDITON_GETCWD:auditon(2) – get cwd:no
    224:AUE_AUDITON_GETCAR:auditon(2) – get car:no
    225:AUE_AUDITON_GETSTAT:auditon(2) – get audit statistics:no
    229:AUE_AUDITON_GETCOND:auditon(2) – get audit state:no
    231:AUE_AUDITON_GETCLASS:auditon(2) – get event class:no
    267:AUE_GETAUDIT_ADDR:getaudit_addr(2):no

 

Summary

 

No system is foolproof. Enabling auditing will not prevent intrusions, nor will auditing necessarily provide details on the attacks used. An attacker could turn off all audit flags in the audit mask, or turn off auditing entirely while removing the audit trail. Auditing enables an administrator to detect probes and attacks, and assists in taking appropriate action and prevent future attacks.

 

Good auditing practice is an ongoing process, not a state. Findings from the audit review process should include not only the detection of possible attacks, but also information that enables an administrator to decide which events should and should not be recorded.

 

Implementing the recommendations made in this article provides a comprehensive auditing environment for Solaris 8 OE systems. However, this article should only be the starting point in the development of appropriate auditing processes and procedures.

 

The above article is an extract from:
William Osser, Alex Noordergraaf, Auditing in the Solaris 8 Operating Environment

Click to access audit_config.pdf

Comments are closed.