Auditing : The Ugly Duckling of Computers

by Phil Cox
<pcc@ntsinc.com>

Phil is a member of the Computer Incident Advisory Capability (CIAC) for the Department of Energy. He also consults and writes on issues bridging the gap between UNIX and Windows NT.

Auditing is an often overlooked portion of system administration, both in the UNIX and Windows NT world. At least 80% (maybe 95%) of the sites I work with do not utilize the auditing functionality of their systems. In this article I discuss what I consider the minimal amount of auditing that would be of benefit in troubleshooting or security tracking. I then give specific recommendations for Solaris 2.X and Windows NT 4.0.

Most people I talk with cite "resources," both human and computer, as the reason they have not yet implemented auditing. They say that computer resource usage, such as disk, processor, and memory, is extensive, and that the time resource for their staff to maintain the system as well as review the data is not worth the hassle. I understand this mindset. My first experience (1991) with C2 auditing on SunOS was daunting. The log files filled up so fast that I could not maintain them adequately, never mind that I never got a chance actually to look through the logs for information. After about two weeks, I just shut it off and wrote the experience off as "proper motivation, but ignorance of reality." The following is a good introduction into practical settings for auditing, with specifics for Windows NT 4.0 and Solaris 2.X.

Minimal Auditing Requirements

With all the reasons we have for why we don't and why we should audit, there needs to be a starting place. Many people ask me, "What should I be auditing?" To answer this, I have compiled a general list of "auditing categories" that I feel is a good minimal starting point:

• all successful and unsuccessful login and logout events
• all modifications to system specific files (config files, system binaries, and libraries)
• all administrative actions (user adds, host changes, password changes, etc.)
• all system type events (reboots, eeprom changes, etc.)

This set gives you a very good, though not complete, picture of your system at any given point in time. You will find it invaluable in troubleshooting, as well as incident handling.

Setting Up Auditing: The Specifics for Windows NT

First you must "enable" auditing. There are two different types of auditing in Windows NT: system level and file/directory level. The "system level" is what I am most concerned with. To set system level auditing, open the "User Manager" tool. While in the User Manager select "Policies->Audit->Audit These Events." Then set the following policy:

Logon and Logoff: success and failure

File and Object Access: none (see Auditing Files and Directories)

Use of User Rights: none

User and Group Management: success and failure

Security Policy Changes: success and failure

Restart, Shutdown, and System: success and failure

Process Tracking: none

Auditing Files and Directories

Auditing files and directories allows you to track their usage. For a particular file or directory, you can specify which groups or users and which actions to audit. You can audit both successful and failed actions. To audit files and directories, you must set the audit policy to audit file and object access. You can select the following file and directory events to audit:

Read: display of filenames, attributes, permissions, contents, and owner

Write: creation of subdirectories and files, changes to attributes, change incontents, and display of permissions and owner

Execute: display of attributes, permissions, and owner; execution of file andchanging to subdirectories

Delete: deletion of file or directory

Change Permissions: changes to permissions

Take Ownership: changes to ownership

You will have to determine which directories and files are to be audited on your system, but a good option is to audit "Write" attempts to files in the %systemroot\system32 folder. To do this, you would select the "Properties" option on the folder, then "Security->Auditing->Add." Then add "Everyone" and select "Write : success and failure," do "replace on existing files," do not "replace on existing subdirectories."

Viewing the Audit Events

You can use the "Event Viewer" for viewing audit events, or there are several third party reporting packages available. I am investigating the EventLog module for Win32 Perl. I have heard a lot of good comments on it, but have not used it extensively.

Setting Up Auditing: The Specifics for Solaris 2.X

The auditing package that comes with Solaris is part of the BSM (Basic Security Module) package. The audit daemon auditd is the process that performs the auditing on Solaris systems. It is started by default if the /etc/security/audit_startup file exists. The actions that can be audited are defined in the /etc/security/audit_event file. This file can be customized, but it is very in-depth and beyond the scope of this article (the answerbook has a very good description of the whole process and files involved).

Audit flags indicate which classes of events to audit. Systemwide defaults are listed in /etc/security/audit_control. This file is very important and is the basis for the rest of the discussion. This file is similar to the "User Manager->Polices->Audit" setup in NT; it controls will be audited on the system and what will not. Set up improperly, and you will either have too much information or too little. A man on audit_classes(4) will give you a large amount of information. In standing with my initial recommendations, here is an audit_control file to start with:

dir:/etc/security/audit
flags:lo,ad,-fm,-fc,-nt
naflags:lo,ad
minfree:10

Let's see what this means. The first line defines the directory for the audit files to be placed. This location must have adequate space; if it fills up it will lock you out.[1] You can have more than one dirflag in the file, and they will be used in the order specified. The second line is for events attributable to a user, and tells us the following: (see the audit_event file for list of actions that fall into a class):

lo ­ all login and logout events

ad ­ all administrative actions

-fm ­ all failed change of object attributes (chmod, flock, etc.)

-fc ­ all failed creation of objects

-nt ­ all failed Network events (This may be noisy)

The third line is for events that are not attributable to a specific user. The fourth line tells us the minimum free in the dir files before we get a warning message from the audit system. The audit -s command will cause the auditd to reread this file after editing.

The other file of interest is the /etc/security/audit_user. This file allows more specific auditing of individual users. If specified, the flags in this file are combined with the global flags in audit_control to provide a more granular auditing ability.

Keeping Solaris Audit Files Manageable

To keep audit file manageable, a cron job can be set up to periodically rotate the audit files. The audit -n command will checkpoint the logs. This process closes the current audit log and opens another. Then you can process the just closed audit file. Figure 1 is a rudimentary script that will process the just closed audit log. Figure 2 is a script to store and rotate audit logs created during the auditreduce portion, a simple modification of the newsyslog script.

Audit maintenance on Solaris has a steep learning curve, but it flattens out pretty quickly. The best documentation is in the answerbook. It is specific and very descriptive. I recommend that anyone not strongly familiar with Solaris auditing read it before you implement the system.

Conclusion

Now that my primary job is helping those unfortunate individuals or sites with security incidents, I see the errors in not taking the time in 1991 to "finish the job." In an incident, if you don't have good logs (i.e., auditing), you'd better have good luck. The chances of figuring out what happened without good auditing are few and far between. If you take one thing from this article, make it this: Take the time, learn your systems, and set up auditing that is adequateand appropriate for your systems.

In the next issue, I will discuss central management of UNIX and NT audit files.

Note

[1] If all audit directories fill, either the "cnt" policy must be enabled, or an "audit" account that is not subject to auditable events must exist. See the "Administering Auditing" in the Basic Security Module Answerbook.

Figure 1: A rudimentary script

#!/bin/csh
# Checkpoint the logs so we can reduce them
/usr/sbin/audit -n

# Setup path to search for modified files in,
# ~ says to ignore this file or directory
# excluding /dev/might be too permissive,
# but it generates a lot of
# "noise" otherwise

srch_path="/usr/sbin,/sbin,~/etc/uucp,\
~/etc/syslog.pid,/etc,/usr/bin,/usr/lib,\
/usr/openwin/lib,/usr/openwin/bin,\
~/dev,~/devices,/kernel"

# get the hostname
host='uname -n'

# Want to be able to clobber /tmp/foo
# if already exists
unset noclobber

# Setup the header in the file echo
"$host Login/out event" > /tmp/foo
echo " " >> /tmp/foo
echo " " >> /tmp/foo

# Use auditreduce to get the information,
# and praudit to clean it up.
# Will give us a listing of all
# login/logout events.
/usr/sbin/auditreduce -C -c lo |
       /usr/sbin/praudit >> /tmp/foo

echo "=============================" >> /tmp/foo

echo "$host Prom event" >> /tmp/foo
echo " " >> /tmp/foo
echo " " >> /tmp/foo

# Will give all events associated
# with PROM events
/usr/sbin/auditreduce -C -m AUE_EXITPROM |
      /usr/sbin/praudit >> /tmp/foo
echo "=============================" >> /tmp/foo

echo "$host Boot event" >> /tmp/foo
echo " " >> /tmp/foo
echo " " >> /tmp/foo
# Will list all events associated
# with system boot
/usr/sbin/auditreduce -C -m AUE_SYSTEMBOOT |
 /usr/sbin/praudit >> /tmp/foo

echo "=============================" >> /tmp/foo

echo "$host File Mod event" >> /tmp/foo
echo " " >> /tmp/foo
echo " " >> /tmp/foo
# Will list all File modification
# events for file in $srch_path
/usr/sbin/auditreduce -C -c fm -o path=$srch_path |
 /usr/sbin/praudit | grep ^path |
  sort | uniq>> /tmp/foo

echo "=============================" >> /tmp/foo

echo "$host Admin event" >> /tmp/foo
echo " " >> /tmp/foo
echo " " >> /tmp/foo
echo " " >> /tmp/foo
# Will list all administrative events
/usr/sbin/auditreduce -C -c ad -o path=$srch_path |
  /usr/sbin/praudit >> /tmp/foo

# Mail the file to the person watching audit logs
/bin/mail logwatcher@audithost.ntsinc.com < /tmp/foo
rm /tmp/foo

#!/bin/sh

# location of audit log files
cd /etc/security/audit
# Tar all files matching the pattern,
# not Y2K compliant :)
/usr/sbin/tar cf tarfile 19*.199*
# then remove the individual file to save space
/bin/rm 19*.199*

LOG=tarfile
test -f $LOG.Z.6 && mv $LOG.Z.6 $LOG.Z.7
test -f $LOG.Z.5 && mv $LOG.Z.5 $LOG.Z.6
test -f $LOG.Z.4 && mv $LOG.Z.4 $LOG.Z.5
test -f $LOG.Z.3 && mv $LOG.Z.3 $LOG.Z.4
test -f $LOG.Z.2 && mv $LOG.Z.2 $LOG.Z.3
test -f $LOG.Z.1 && mv $LOG.Z.1 $LOG.Z.2
test -f $LOG.Z.0 && mv $LOG.Z.0 $LOG.Z.1
mv $LOG.Z  $LOG.Z.0
# compress the new tar file to save space
/usr/bin/compress tarfile