Audit Planning

Auditing can be an overwhelming task, with several components that may require some preparation. Sun Microsystems has published guidelines that highlight the issues related to auditing as preinstallation points to consider. These issues range from determining who and what to audit and where to store audit records, to what to do with the audit files after they are generated.

What to Audit  Auditing can be a daunting undertaking when monitoring a large group of users and systems, or even for a small group of very active systems. Deciding who and what to audit should be carefully planned to allow for available storage space—whether it be local or on a remote storage system. Therefore, it's important that you plan efficiently. After deciding which systems require auditing, be sure to plan for primary and secondary audit directories for each audited system, and determine where to place them. Then create a visual diagram containing each audit directory and map them to their respective systems to get an overall picture, as illustrated in Figure 5-1.

Figure 5-1: Mapping audited systems to preconfigured audit directories

Under normal conditions, the audit files for a system are placed in the primary audit directory; the audit files for a system are placed in the secondary audit directory if the primary audit directory is full or not available. You can also configure a directory of last resort, which is a local audit directory that is used if the primary and all secondary audit directories become unavailable. The directories are specified in the audit_control file, which we'll talk about later.

When planning for individual auditing selections, the audit classes and policies can be customized for each site. Depending on your current setup, before accessing the audit configuration files, you may have to assume the superuser or the Primary Administrator role and run the bsmconv script, located at /etc/security, using the ./bsmconv command. This script is used to enable the Basic Security Module (BSM), which provides additional security features defined as C2 in the Trusted Computer System Evaluation Criteria (TCSEC), and features that are not supplied in standard UNIX, such as the security auditing subsystem. However, Sun recommends first customizing your audit configuration before starting the audit service (be sure to run the script again to stop the audit service to customize the configuration files). All configuration files for auditing will be created as well in the /etc/security folder. After running the script, you'll be prompted to restart the system (which you can do with the init 6 command), and the following audit system and configuration files should be available:

# ls /etc/security
audit              audit_user         dev               lib
audit_class        audit_warn         device_allocate   policy.conf 
audit_control      auth_attr          device_maps       priv_names 
audit_event        bsmconv            device_policy     prof_attr 
audit_record_attr  bsmunconv          exec_attr         spool
audit_startup      crypt.conf         extra_privs

The audit_control file can be modified to preselect audit classes, and you can execute the auditconfig -lspolicy command to see the available policy options—the audit policy is established by the auditconfig command, which is automatically started in the audit_startup script. We'll talk more about customizing the auditing system in the "Audit Configuration" section later in this chapter.

Audit File Storage  After you determine where to store the primary and secondary audit directories and which audited systems will use them, you should determine the storage space alert threshold and establish a procedure to follow when audit directories run out of space. Since the degree of storage requirements depends on such variables as the number of users and systems as well as the levels of auditing and usage, no standard formula can be used to predetermine storage size requirements. However, you should determine the minimum free disk space available for audit files before warnings are sent, who should receive warnings, and what to do when an audit trail overflows.

First, you'll specify the location for audit data on a system. You need to modify the /etc/security/audit_control file by adding the dir argument followed by the system primary, secondary, and optional last resort directory, one per line. It's important that you save a backup of the original file to avoid any potential corruption. For example, to specify the primary directory /var/audit/1/data, the secondary directory /var/audit/2/data, and directory of last resort /var/audit, you would add the following lines to the beginning of your audit_control file, in order:

# ident "@(#)audit_control.txt  1.4     00/07/17 SMI"
#
dir:/var/audit/1/data
dir:/var/audit/2/data
dir:/var/audit

Optionally, you can create partitions for audit files as required, especially if you add drives or have partitions on disks that are not currently mounted. See your device and file system administration guide for thorough instructions, or follow these simple steps:

1. Log in with an account that has root privileges, or use the su command to become superuser.

2. Create a partition using the newfs command as follows:

   newfs /dev/rdsk/name
   

   where name is the raw device name for the partition.

3. Create mount points for the partition using the mkdir command as follows:

   mkdir /var/audit/server-name.id-number

   where server-name is the name of the server and id-number is some unique number that will be used to identify the partition, which is useful if many audit partitions are in use.

4. Edit the /etc/vfstab file by including an entry to mount the new partition automatically, such as the following:

   /dev/dsk/name /dev/rdsk/name /var/audit/server-name.id-number   ufa   2   yes

   where name is the name of the partition, server-name is the name of the server, and id-number is the unique number that will be used to identify the partition.

5. Mount the new partition using the mount command:

   mount /var/audit/server-name.id-number

   where server-name is the name of the server and id-number is the unique partition identification number.

6. Create the audit directories on the new partition with the mkdir command:

   mkdir /var/audit/var/audit/server-name.id-number/audit-dir
   

   where server-name is the name of the server, id-number is the unique partition identification number, and audit-dir is the name of the new audit directory on the partition to which you wish to store audit files.

7. Modify the permissions on the mount point and new directory to allow for the auditing subsystem to store output:

   chmod – R 750 /var/audit/server-name.id-number/audit-dir

   where server-name is the name of the server, id-number is the unique partition identification number, and audit-dir is the name of the new audit directory.

After the partitions have been set, to set the minimum free disk space for an audit file before a warning is sent, you need to modify the /etc/security/audit_control file by adding the minfree argument followed by a percentage. Again, it's important that you first save a backup of the original file before making changes. For example, to set the minimum free-space level for all audit file systems so that a warning is sent when 15 percent of the file system is available, edit the audit_control file and modify the line item minfree:xx, where xx is a percentage less than 100. The recommended percentage is 30%. When you are finished, be sure to save the changes before exiting the editor.

Next, we change the minfree argument/minimum free disk space to 15 percent, as shown in the following extract:

# ident "@(#)audit_control.txt  1.4     00/07/17 SMI"
#
dir:/var/audit/1/data
dir:/var/audit/2/data
dir:/var/audit
flags:
minfree:15
naflags:lo

A warning alias is the e-mail account that will receive warnings generated from the audit_warn script, such as when the minimum free space level is reached. You can set up a warning alias in two ways. The easiest method is to edit the etc/security/audit_warn file by changing the e-mail alias in the script at entry ADDRESS=audit_warn, like so:

#--------------------------------------------------------------------------- 
send_msg() { 
        MAILER=/usr/bin/mailx
        SED=/usr/bin/sed
        LOGCMD="$LOGGER -p daemon.alert"
        ADDRESS=audit_warn              # standard alias for audit alerts

The second way is a little more complicated and requires that you redirect the audit_warn e-mail alias to the appropriate account. To do this, add the audit_warn e-mail alias to the new alias file—in /etc/mail/ aliases or the mail_aliases database in the name space—like so: audit_warn: alertadmin.

Finally, when audit files run out of free space altogether, you do have options regarding how the audit system should proceed. By default, the system will count audit records and continue to function despite the lack of free space, but audit records will not be recorded. However, if security is a higher priority than availability, you can configure the audit_startup file (which determines the audit policy) to halt the system when audit space is unavailable. To do so, simply disable the cnt policy (which allows the system to continue functioning) and enable the ahlt policy (which stops the system when audit partitions are full) with the following entries:

#!/bin/sh
/usr/bin/echo "Starting BSM services."
/usr/sbin/deallocate –Is
/usr/sbin/auditconfig –conf
/usr/sbin/auditconfig –aconf
/usr/sbin/auditconfig -setpolicy -cnt
/usr/sbin/auditconfig -setpolicy +ahlt

Note the minus (–) and plus (+) prior to policies that either disable or enable policies, respectively.

Inside The Exam–Manually Setting the Free Space Warning Threshold to 25 Percent

Following are the steps for manually changing the free space threshold before a warning is sent for all audit file systems:

1. Log in with an account that has root privileges, or use the su command to become superuser.

2. Save a backup copy of the original audit_control file, as shown:

   cp /etc/security/audit_control/etc/security/audit_control.bak

3. Edit the audit_control file in your text editor by issuing this command:

   vi /etc/security/audit_control

4. Modify the minfree entry (by pressing the I key on the keyboard at the current percentage): minfree:25

5. End insert mode by pressing the ESC key, and then save the file and exit the editor with the :wq command.

Optimal Auditing  Given the burden that auditing can impart on systems and available storage, you can ensure that you are auditing optimally in several ways. Sun recommends the following techniques for the most efficient auditing, while still adhering to security prioritizations:

• For large networks with limited storage capacity, try randomly auditing a percentage of users at one time.

• Perform routine audit file maintenance by reducing the disk-storage requirements by combining, removing, and compressing older log files. It's good practice to develop procedures for archiving the files, for transferring the files to removable media, and for storing the files offline.

• Monitor the audit data for unusual events in real time. Also set up procedures to monitor the audit trail for certain potentially malicious activities. Adhere to company policy and immediately execute mitigations with regard to substantiated malicious findings.

• Deploy a script to trigger an automatic increase in the auditing of certain users or certain systems in response to the detection of unusual or potentially malicious events.

  Exam Watch

  Remember that the most efficient audit methodology is accomplished by randomly auditing only a small percentage of users at any one time, compressing files, archiving older audit logs, monitoring in real time, and automatically increasing unusual event auditing.

Audit Configuration

We've already covered some of the auditing preconfiguration and planning steps for Solaris, so let's continue in this section by choosing what classes of system events to audit, which user events to audit, and how to configure syslog audit logs.

Choosing What Classes of System Events to Audit  In the audit_control file, the flags and naflags arguments define which attributable and nonattributable events (the na preceding the second argument specifies nonattributable events) should be audited for the entire system—that is, all users on the system. Incidentally, you can specify events by using the bsmrecord command (see the bsmrecord man page for more information). Events can be added to the flags and naflags arguments separated by commas. Following is a sample extract:

# ident "@(#)audit_control.txt 1.4     00/07/17 SMI"
#
dir:/var/audit/1/data
dir:/var/audit/2/data
dir:/var/audit
flags:lo
minfree:25
naflags:lo,na

In this extract, the attributable lo class events and nonattributable lo and na class events will be audited for all users on the system.

On the other hand, to configure the auditing subsystem not to audit the system—say, for example, if you wish to audit only specific users (explained in the next section)—simply leave out the class selections after the flags and naflags arguments, as shown next:

# ident "@(#)audit_control.txt 1.4 00/07/17 SMI"
#
dir:/var/audit/1/data
dir:/var/audit/2/data
dir:/var/audit
flags:
minfree:25
naflags:

With regard to classes of events, audit_event is the event database that can be read to determine which events are part of classes you can audit. The event numbers include the following, with the exception of 0, which is reserved as an invalid event number:

• 1–2047 Solaris Kernel events

• 2048–32767 Solaris TCB programs (6144–32767 also used for SunOS 5.X user level audit events)

• 32768–65535 Third-party TCB applications

You can use the more audit_event command to view the entire database. The database file format is as follows: event number: event name:event description:event classes. Therefore, to audit events associated with user telnet sessions you would include the lo class, which is specified in the database as event number 6154, as shown here:

6154:AUE_telnet:login - telnet:lo

Choosing Specific Users and Events to Audit  The audit_user file is the user database that can be modified to include individual user-specified events as part of classes that should be audited. To add users to the user database—say, for example, if you disabled auditing for the entire system including all users (as explained in the previous section) and wish to audit specific users only—simply add the entries to the audit_user file in the following format: username:always-audit:never-audit; where username is the name of the user to be audited, always-audit is the list of classes of events that should be always audited, and never-audit is the list of classes of events that should never be audited. Keep in mind that adding user-specific classes in the audit_user file can also be included along with the auditing of the entire system if you wish to modify the system audit configuration to add or remove some classes for specific users.

On the other hand, as noted in the previous section, you can configure the auditing subsystem not to audit the system and audit only specific users by leaving out the class selections after the flags and naflags arguments in the audit_control file and adding users and classes to the audit_user file, as shown next.

For audit_control file configuration:

# ident "@(#)audit_control.txt   1.4     00/07/17 SMI"
#
dir:/var/audit/1/data
dir:/var/audit/2/data
dir:/var/audit
flags:
minfree:25
naflags:

Inside The Exam–Manually Selecting Users and Classes of Events to Audit

Following are steps for manually selecting users and classes of events to audit:

1. Log in with an account that has root privileges, or use the su command to become superuser.

2. Save a backup copy of the original audit_user file, as shown:

   cp /etc/security/audit_user /etc/security/audit_user.bak

3. Edit the audit_user file in your text editor:

   vi /etc/security/audit_user

4. Add user entries, one per line, in the following format: username:classes- to-audit:classes-not-to-audit. Separate multiple classes with commas. As a reference, the audit_event file defines which events are part of classes you can audit. You can use the more/etc/security/audit_event command in a terminal session to view the entire database.

5. End insert mode by pressing the ESC key, and then save the file and exit the editor with the :wq command.

For audit_user file configuration:

# ident "@(#)audit_user.txt    1.6      00/07/17 SMI"
#
root:lo:no
b_friedman:lo
j_public:lo,pf

Configuring Syslog Audit Logs The auditing subsystem supports the collection of binary data, which is indicated in the previous sections, as well as binary data and a subset of the binary as text audit data. The binary and text audit data collection combination can be accomplished with the syslog auditing plug-in. The binary collection of audit data is enabled by default; therefore, to add the syslog feature, you'll need to specify the plug-in in the audit_control file. A plug-in is configured using the following:

plugin:name=audit_syslog.so.1; p_flags=classes

where classes defines a subset of the audit classes of events that are indicated in the flags and naflags entries in the audit_control file (as explained in previous sections). Currently there is only one plugin available. Use the more audit_event command to view the entire database of classes to audit.

Following is a sample extract that includes the syslog plug-in:

# ident "@(#)audit_control.txt 1.4 00/07/17 SMI"
#
dir:/var/audit/1/data
dir:/var/audit/2/data
dir:/var/audit
flags:lo
minfree:25
naflags:lo,na
plugin:name=audit_syslog.so.1; p_flags=-lo,-na

In this configuration extract, the flags and naflags attributes direct the auditing subsystem to audit all login, logout, and nonattributable events in the default binary format (as classes lo and na defined in the audit_event database). However, the plugin entry takes auditing a step further by instructing syslog also to collect login and nonattributable event failures indicated with the p_flags classes -lo and -na.

The syslog text logs can generate massive log files, so be sure to monitor and archive them regularly. In addition, you should never store syslog audit files in the same location as binary data. Therefore, the next step is to edit the etc/syslog.conf file by adding an audit.notice entry followed by the location in which to place syslog files. Here's an example:

audit.notice               /var/audit/slogs

Enabling the Auditing Service and Log Management

After you plan for and customize your auditing solution, you must enable the auditing service. In this section, we'll look at the simple steps involved in enabling the service as well as disabling the service for times when auditing is not required or for offline forensics. In addition, we'll talk about how to update the service in case you make changes to the configuration files. Finally, we'll discuss ways to manage audit records by monitoring and displaying them and merging audit files into a single grouping, which is useful for analyzing a complete audit trail.

Enabling and Disabling the Auditing Service  As mentioned, before accessing some of the audit configuration files, you may have to assume superuser or the Primary Administrator role and run the bsmconv script located in /etc/security with the ./bsmconv command. This script is used to enable the Basic Security Module (BSM), which starts the auditing subsystem. All configuration files for auditing will be created as well in the /etc/security folder. To enable the auditing service, follow these simple steps:

1. Log in with an account that has root privileges, or use the su command to become superuser.

2. Bring down the system to single-user mode using the init 1 command.

3. In the /etc/security directory, run the bsmconv script to enable the auditing service, like so: ./bsmconv

4. Bring the system into multi-user mode using the init 6 command.

If the auditing service is not required—for example, to make configuration modifications before auditing a production environment or for offline forensics—you can disable the service by following the same steps you took to enable the service. That is, become superuser, bring the system down to single-user state, run the bsmconv script again—this time to disable the service—and then bring the system back into multi-user state.

Updating the Auditing Service  After you start the auditing service in a production environment, you may find that you need to tweak the configuration to audit more classes or perhaps audit specific users more closely. After making changes, you'll need to update the auditing service. This simply restarts the auditd daemon, which in effect will apply the new configuration changes to the service. To do this, Sun recommends using the following steps:

1. Log in with an account that has root privileges, or use the su command to become superuser. Additionally, you can assume a role that includes the Audit Control.

2. Refresh the kernel with the audit -s command.

3. Refresh the auditing service with the auditconfig -conf command.

   Exam Watch

   Whenever you make changes to or update the auditing service you need to issue the audit -s command. This renews the kernel, and the auditconfig -conf command, which refreshes the auditing service in order for your changes to apply properly.

4. If users were added to the audit list, ensure that each user is being audited with the auditconfig -setmask user-id classes command; where user-id is the user's ID and classes are the preselected audit classes of events mentioned throughout this chapter.