When
Ideally daily; at least weekly, depending on your audit policy.
Why
Taking the mystery and confusion out of reading audit logs makes it easier to understand what's happening on the system.
Strategy
This issue provides insight into Unix auditing using the Sun Solaris flavor. There are three types of auditing organic to Solaris: ASET, C2 and BSM. Reading or executing any of these privileged files requires administrator access; any commands listed assume an administrator's prompt.
The Automated Security Enhancement Tool (ASET) is a set of administrative utilities that improve system security by warning of potential security problems, allowing administrators to check system files settings, both attributes (permissions, ownership, etc.) and content. You can specify low, medium or high security levels. See asetenv and asetmasters for more info.
C2 Audit: Many Unix systems allow the admin to enable auditing called "C2 audit," because it's logging the form specified by Department of Defense regulations to meet C2 level of trust. C2 auditing generally means assigning an audit ID to each group of related processes at login, and thereafter related system calls performed by every process are logged with that audit ID. There is no accepted standard for the logging format; C2-style logging can have different formats, controls and locations. C2 audit is useless without interpretation and reduction tools, and these weren't usually available, paving the way for Basic Security Module.
Solaris uses BSM for auditing, enabled by starting the audit daemon (auditd). The /etc/security directory contains subdirectories with audit files related to audit control. Auditd collects data and writes it to records, forming audit files. BSM is easy to use, but many admins erroneously assume it's automatically running. To check, type ps -ef and look for auditd. If not, research bsmconv.
The audit daemon runs as root, always looking for a place to put audit records because auditd is not audited; if it was it would cause an endless loop. Note that only one audit daemon may run. Attempting to start another throws an error, and the new one exits.
The audit_warn script runs whenever the daemon switches audit directories or encounters difficulty (such as no free space), sending a message to an alias and the console; customize audit_warn to suit your policy. Wherever you log the files, the directory needs sufficient free space remaining; if there is none, the daemon stops processing audit records, and they accumulate within the kernel until all processes generating audit records are suspended. To keep audit files manageable, set up a cron job that periodically saves audit files to another system, then deletes them off the server that generated them, so your audit policy is enforced.
--Audit files that are complete have names using: start-time.finish-time.machine (i.e., time of the first audit record in the file; time of the last; name of the machine generating the file.) The exact format is: YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname, for example: "20020610020543.20020617225351.SERVER01" indicates the log file on Server01 was started June 10th, 2002 at 5 minutes after 2 am, and closed itself successfully on June 17th, 2002 at 10:53 pm.
--If the audit log file is still active or is interrupted, it uses the form: start-time.not_terminated.machine. For example "20020627225244.not_terminated.SERVER01" indicates the file was opened June 27th, 2002 at 10:52 pm, but never "finished."
The two main commands used in BSM are auditreduce, which merges audit records from input files, even across networks, and praudit, which makes it readable and lets the admin select all or separate events to audit. praudit doesn't interpret or group information. To read the audit file, enter auditreduce | praudit.
More information
Audit trail management for Solaris 8 is at: http://docs.sun.com/db/doc/805-8121/6j7kril2s?a=view, for the commands or files listed here listed, look them up using your favorite man page reference guide. Other key words: audit.log, audit flags, auditconfig, audit_control, audit_user, preselection mask, minfree.
About the author
Shelley Bard, CISSP, CISM, is a senior security network engineer with Verizon Federal Network Systems (FNS). An information security professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to mailto:securityplanner@infosecuritymag.com.
Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.
Last week: Who's afraid of auditing?
