Chapter 29 Planning for Solaris Auditing

This chapter describes how to set up the audit service for your Solaris installation. In particular, the chapter covers issues that you need to consider before you enable the audit service. The following is a list of the planning information in this chapter:

• Planning Solaris Auditing (Task Map)

• Determining Audit Policy

• Controlling Auditing Costs

• Auditing Efficiently

For an overview of auditing, see Chapter 28, Solaris Auditing (Overview). For procedures to configure auditing at your site, see Chapter 30, Managing Solaris Auditing (Tasks). For reference information, see Chapter 31, Solaris Auditing (Reference).

Planning Solaris Auditing (Task Map)

The following task map points to the major tasks that are required for planning disk space and what events to record.

Task	For Instructions
Determine auditing strategy for non-global zones	How to Plan Auditing in Zones
Plan storage space for the audit trail	How to Plan Storage for Audit Records
Determine who and what to audit	How to Plan Who and What to Audit

Planning Solaris Auditing (Tasks)

You want to be selective about what kinds of activities are audited. At the same time, you want to collect useful audit information. Audit files can quickly grow to fill the available space, so you should allocate enough disk space. You also need to carefully plan who to audit and what to audit.

How to Plan Auditing in Zones

If your system has implemented zones, you have two audit configuration possibilities:

• You can configure a single audit service in the global zone for all zones.

• You can configure one audit service per zone.

For a discussion of the trade-offs, see Auditing on a System With Zones.

1. Choose one of the following methods.

   • OPTION 1 - Configure a single audit service for all zones.

     Auditing all zones identically can create a single-image audit trail. A single-image audit trail occurs when all zones on a system are part of one administrative domain. The audit records can then be easily compared, because the records in every zone are preselected with identical settings.

     This configuration treats all zones as part of one system. The global zone runs the only audit daemon on a system, and collects audit logs for every zone. You customize audit configuration files only in the global zone, then copy the audit configuration files to every non-global zone.

     1. Copy the audit_control file from the global zone to every non-global zone.

     2. Use the same audit_user database for every zone.

        The audit_user database might be a local file, or you might get it from a shared naming service.

     3. Enable the audit records to be selected by zone.

        To put the zone name as part of the audit record, set the zonename policy in the global zone. The auditreduce command can then select audit events by zone from the audit trail. For an example, see the auditreduce(1M) man page.

     To plan a single-image audit trail, refer to How to Plan Who and What to Audit. Start with the first step. The global zone administrator must also set aside storage, as described in How to Plan Storage for Audit Records.

   • OPTION 2 - Configure one audit service per zone.

     Choose to configure per-zone auditing if different zones have different naming service files, or if zone administrators want to control auditing in their zones.

     • When you configure per-zone auditing, you must configure the global zone for auditing. You set the perzone audit policy in the global zone. To set audit policy, see How to Configure Per-Zone Auditing.

       ---

       Note –

       If naming service files are customized in non-global zones, and perzone policy is not set, then careful use of the audit tools is required to select usable records. A user ID in one zone can refer to a different user from the same ID in a different zone.

       ---

     • To generate records that can be traced to their originating zone, set the zonename audit policy in the global zone. In the global zone, run the auditreduce command with the zonename option. Then, in the zonename zone, run the praudit command on the auditreduce output.

     • Each zone administrator configures the audit files for the zone.

       A non-global zone administrator can set all policy options except perzone and ahlt.

     • Each zone administrator can enable or disable auditing in the zone.

     If you customize audit configuration files in every zone, use How to Plan Who and What to Audit to plan for every zone. You can skip the first step. Each zone administrator must also set aside storage for every zone, as described in How to Plan Storage for Audit Records.

How to Plan Storage for Audit Records

The audit trail requires dedicated file space. The dedicated file space for audit files must be available and secure. Each system should have several audit directories that are configured for audit files. You should decide how to configure the audit directories as one of the first tasks before you enable auditing on any systems. The following procedure covers the issues to be resolved when you plan for audit trail storage.

Before You Begin

If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.

1. Determine how much auditing your site needs.

   Balance your site's security needs against the availability of disk space for the audit trail.

   For guidance on how to reduce space requirements while still maintaining site security, as well as how to design audit storage, see Controlling Auditing Costs and Auditing Efficiently.

2. Determine which systems are to be audited.

   On those systems, allocate space for at least one local audit directory. To specify the audit directories, see Example 30–3.

3. Determine which systems are to store audit files.

   Decide which servers are to hold the primary and secondary audit directories. For examples of configuring disks for audit directories, see How to Create Partitions for Audit Files.

4. Name the audit directories.

   Create a list of all the audit directories that you plan to use. For naming guidelines, see Storing the Audit Trail and auditreduce Command.

5. Determine which systems are to use which audit directories.

   Create a map that shows which system should use which audit directory. The map helps you to balance the auditing activity. For an illustration, see Figure 31–1 and Figure 31–2.

How to Plan Who and What to Audit

Before You Begin

If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.

1. Determine if you want a single-system image audit trail.

   Systems within a single administrative domain can create a single-system image audit trail. If your systems use different naming services, start with the next step. You should complete the rest of the planning steps for every system.

   A single-system image audit trail treats the systems that are being audited as one machine. To create a single-system image audit trail for a site, every system in the installation should be configured as follows:

   • Use the same naming service.

     To interpret the audit records, two commands are used, auditreduce and praudit. For correct interpretation of the audit records, the passwd, hosts, and audit_user files must be consistent.

   • Use the same audit service settings for all systems. For information about displaying and modifying the service settings, see the auditconfig(1M) man page.

   • Use the same audit_warn, audit_event, and audit_class files for all systems.

   • Use the same audit_user database. The database can be in a naming service such as NIS or LDAP.

   • Have identical flags, naflags, and plugin entries in the audit_control file.

2. Determine the audit policy.

   Use the auditconfig -lspolicy command to see a short description of available policy options. By default, only the cnt policy is turned on. For a fuller discussion, see Step 8.

   For the effects of the policy options, see Determining Audit Policy. To set audit policy, see How to Configure Audit Policy.

3. Determine if you want to modify event-to-class mappings.

   In many situations, the default mapping is sufficient. However, if you add new classes, change class definitions, or determine that a record of a specific system call is not useful, you might also need to move an event to a different class.

   For an example, see How to Change an Audit Event's Class Membership.

4. Determine which audit classes to preselect.

   The best time to add audit classes or to change the default classes is before you start the audit service.

   The audit class values of the flags, naflags, and plugin entries in the audit_control file apply to all users and processes. The preselected classes determine whether an audit class is audited for success, for failure, or for both.

   To preselect audit classes, see How to Modify the audit_control File.

5. Determine user exceptions to the system-wide preselected audit classes.

   If you decide that some users should be audited differently from the system-wide preselected audit classes, modify the individual users' entries in the audit_user database.

   For an example, see How to Change a User's Audit Characteristics.

6. Determine the minimum free disk space.

   When disk space on an audit file system drops below the minfree percentage, the auditd daemon switches to the next available audit directory. The daemon then sends a warning that the soft limit has been exceeded.

   To set the minimum free disk space, see Example 30–4.

7. Decide how to manage the audit_warn email alias.

   The audit_warn script is run whenever the audit system needs to notify you of a situation that requires administrative attention. By default, the audit_warn script sends email to an audit_warn alias and sends a message to the console.

   To set up the alias, see How to Configure the audit_warn Email Alias.

8. Decide what action to take when all the audit directories are full.

   By default, when the audit trail overflows, the system continues to work. The system counts the audit records that are dropped, but does not record the events. For greater security, you can disable the cnt policy, and enable the ahlt policy. The ahlt policy stops the system when an asynchronous event cannot be placed in the audit queue.

   For a discussion of these policy options, see Audit Policies for Asynchronous and Synchronous Events. To configure these policy options, see Example 30–13.

9. Decide whether to collect audit records in binary format, in syslog format, or in both formats.

   For overview information, see Audit Logs.

   For an example, see How to Configure syslog Audit Logs.

Determining Audit Policy

Audit policy determines the characteristics of the audit records for the local system. You use the auditconfig command to set these policies. For more information, see the auditconfig(1M) man page.

Most audit policy options are disabled by default to minimize storage requirements and system processing demands. These options are stored as properties of the audit service and determine the policy options that are in effect at system boot or when the service is restarted. For more information about the audit service, see Solaris Audit Service.

Use the following table to determine if the needs of your site justify the additional overhead that results from enabling one or more audit policy options.

Table 29–1 Effects of Audit Policy Options

Policy Name	Description	Why Change the Policy Option?
ahlt	This policy applies to asynchronous events only. When disabled, this policy allows the event to complete without an audit record being generated.  When enabled, this policy stops the system when the audit file systems are full. Administrative intervention is required to clean up the audit queue, make space available for audit records, and reboot. This policy can only be enabled in the global zone. The policy affects all zones.	The disabled option makes sense when system availability is more important than security.  The enabled option makes sense in an environment where security is paramount.
arge	When disabled, this policy omits environment variables of an executed program from the exec audit record. When enabled, this policy adds the environment variables of an executed program to the exec audit record. The resulting audit records contain much more detail than when this policy is disabled.	The disabled option collects much less information than the enabled option.  The enabled option makes sense when you are auditing a few users. The option is also useful when you have suspicions about the environment variables that are being used in exec programs.
argv	When disabled, this policy omits the arguments of an executed program from the exec audit record. When enabled, this policy adds the arguments of an executed program to the exec audit record. The resulting audit records contain much more detail than when this policy is disabled.	The disabled option collects much less information than the enabled option.  The enabled option makes sense when you are auditing a few users. The option is also useful when you have reason to believe that unusual exec programs are being run.
cnt	When disabled, this policy blocks a user or application from running. The blocking happens when audit records cannot be added to the audit trail because no disk space is available.  When enabled, this policy allows the event to complete without an audit record being generated. The policy maintains a count of audit records that are dropped.	The disabled option makes sense in an environment where security is paramount.  The enabled option makes sense when system availability is more important than security.
group	When disabled, this policy does not add a groups list to audit records.  When enabled, this policy adds a groups list to every audit record as a special token.	The disabled option usually satisfies requirements for site security.  The enabled option makes sense when you need to audit which groups are generating audit events.
path	When disabled, this policy records in an audit record at most one path that is used during a system call.  When enabled, this policy records every path that is used in conjunction with an audit event to every audit record.	The disabled option places at most one path in an audit record.  The enabled option enters each file name or path that is used during a system call in the audit record as a path token.
perzone	When disabled, this policy maintains a single audit configuration for a system. One audit daemon runs in the global zone. Audit events in non-global zones can be located in the audit record by preselecting the zonename audit token. When enabled, this policy maintains separate audit configuration, audit queue, and audit logs for each zone. A separate version of the audit daemon runs in each zone. This policy can be enabled in the global zone only.	The disabled option is useful when you have no special reason to maintain a separate audit log, queue, and daemon for each zone.  The enabled option is useful when you cannot monitor your system effectively by simply preselecting the zonename audit token.
public	When disabled, this policy does not add read-only events of public objects to the audit trail when the reading of files is preselected. Audit classes that contain read-only events include fr, fa, and cl. When enabled, this policy records every read-only audit event of public objects if an appropriate audit class is preselected.	The disabled option usually satisfies requirements for site security.  The enabled option is rarely useful.
seq	When disabled, this policy does not add a sequence number to every audit record.  When enabled, this policy adds a sequence number to every audit record. The sequence token holds the sequence number.	The disabled option is sufficient when auditing is running smoothly.  The enabled option makes sense when the cnt policy is enabled. The seq policy enables you to to determine when data was discarded.
trail	When disabled, this policy does not add a trailer token to audit records. When enabled, this policy adds a trailer token to every audit record.	The disabled option creates a smaller audit record.  The enabled option clearly marks the end of each audit record with a trailer token. The trailer token is often used in conjunction with the sequence token. The trailer token provides easier and more accurate resynchronization of audit records.
zonename	When disabled, this policy does not include a zonename token in audit records. When enabled, this policy includes a zonename token in every audit record from a non-global zone.	The disabled option is useful when you do not need to compare audit behavior across zones.  The enabled option is useful when you want to isolate and compare audit behavior across zones.

Audit Policies for Asynchronous and Synchronous Events

Together, the ahlt policy and the cnt policy govern what happens when the audit queue is full and cannot accept more events. The policies are independent and related. The combinations of the policies have the following effects:

• -ahlt +cnt is the default policy that is shipped. This default lets an audited event be processed even if the event cannot be logged.

  The -ahlt policy states that if an audit record of an asynchronous event cannot be placed in the kernel audit queue, the system will count the events and continue processing. In the global zone, the as_dropped counter records the count.

  The +cnt policy states that if a synchronous event arrives and the event cannot be placed in the kernel audit queue, the system will count the event and continue processing. The zone's as_dropped counter records the count.

  The -ahlt +cnt configuration is generally used at sites where processing must continue, even if continued processing could result in a loss of audit records. The auditstatdrop field shows the number of audit records that are dropped in a zone.

• The +ahlt -cnt policy states that processing halts when an event cannot be added to the kernel audit queue.

  The +ahlt policy states that if an audit record of an asynchronous event cannot be placed in the kernel audit queue, all processing is stopped. The system will panic. The asynchronous event will not be in the audit queue and must be recovered from pointers on the call stack.

  The -cnt policy states that if a synchronous event cannot be placed in the kernel audit queue, the thread that is attempting to deliver the event will be blocked. The thread is placed in a sleep queue until audit space becomes available. No count is kept. Programs might appear to hang until audit space becomes available.

  The +ahlt -cnt configuration is generally used in sites where a record of every audit event takes precedence over system availability. Programs will appear to hang until audit space becomes available. The auditstat wblk field shows the number of times that threads were blocked.

  However, if an asynchronous event occurs, the system will panic, leading to an outage. The kernel queue of audit events can be manually recovered from a saved crash dump. The asynchronous event will not be in the audit queue and must be recovered from pointers on the call stack.

• The -ahlt -cnt policy states that if an asynchronous event cannot be placed in the kernel audit queue, the event will be counted and processing will continue. When a synchronous event cannot be placed in the kernel audit queue, the thread that is attempting to deliver the event will be blocked. The thread is placed in a sleep queue until audit space becomes available. No count is kept. Programs might appear to hang until audit space becomes available.

  The -ahlt -cnt configuration is generally used in sites where the recording of all synchronous audit events takes precedence over some potential loss of asynchronous audit records. The auditstat wblk field shows the number of times that threads were blocked.

• The +ahlt +cnt policy states that if an asynchronous event cannot be placed in the kernel audit queue, the system will panic. If a synchronous event cannot be placed in the kernel audit queue, the system will count the event and continue processing.

Controlling Auditing Costs

Because auditing consumes system resources, you must control the degree of detail that is recorded. When you decide what to audit, consider the following costs of auditing:

• Cost of increased processing time

• Cost of analysis of audit data

• Cost of storage of audit data

Cost of Increased Processing Time of Audit Data

The cost of increased processing time is the least significant of the costs of auditing. The first reason is that auditing generally does not occur during computation-intensive tasks, such as image processing, complex calculations, and so forth. The other reason is that the cost for single-user systems is usually small enough to ignore.

Cost of Analysis of Audit Data

The cost of analysis is roughly proportional to the amount of audit data that is collected. The cost of analysis includes the time that is required to merge and review audit records. Cost also includes the time that is required to archive the records and keep the records in a safe place.

The fewer records that you generate, the less time that is required to analyze the audit trail. Upcoming sections, Cost of Storage of Audit Data and Auditing Efficiently, describe ways to audit efficiently. Efficient auditing reduces the amount of audit data, while still providing enough coverage to achieve your site's security goals.

Cost of Storage of Audit Data

Storage cost is the most significant cost of auditing. The amount of audit data depends on the following:

• Number of users

• Number of systems

• Amount of use

• Degree of traceability and accountability that is required

Because these factors vary from site to site, no formula can predetermine the amount of disk space to set aside for audit data storage. Use the following information as a guide:

• Preselect audit classes judiciously to reduce the volume of records that are generated.

  Full auditing, that is, with the all class, fills disks quickly. Even a simple task such as compiling a program could generate a large audit file. A program of modest size could generate thousands of audit records in less than a minute.

  For example, by omitting the file_read audit class, fr, you can significantly reduce audit volume. By choosing to audit for failed operations only, you can at times reduce audit volume. For example, by auditing for failed file_read operations, -fr, you can generate far fewer records than by auditing for all file_read events.

• Efficient audit file management is also important. After the audit records are created, file management reduces the amount of storage that is required.

• Understand the audit classes

  Before you configure auditing, you should understand the types of events that the classes contain. You can change the audit event-class mappings to optimize audit record collection.

• Develop a philosophy of auditing for your site.

  Base your philosophy on sensible measures. Such measures include the amount of traceability that your site requires, and the types of users that you administer.

Auditing Efficiently

The following techniques can help you achieve your organization's security goals while auditing more efficiently.

• Randomly audit only a certain percentage of users at any one time.

• Reduce the disk-storage requirements for audit files by combining, reducing, and compressing the files. Develop procedures for archiving the files, for transferring the files to removable media, and for storing the files offline.

• Monitor the audit data in real time for unusual behaviors. You can extend management and analysis tools that you have already developed to handle audit records in syslog files.

  You can also set up procedures to monitor the audit trail for certain activities. You can write a script to trigger an automatic increase in the auditing of certain users or certain systems in response to detection of unusual events.

  For example, you could write a script that does the following:

  1. Monitors the creation of audit files on all the audit file servers.

  2. Processes the audit files with the tail command.

     The piping of the output from the tail -0f command through the praudit command can yield a stream of audit records as the records are generated. For more information, see the tail(1) man page.

  3. Analyzes this stream for unusual message types or other indicators, and delivers the analysis to the auditor.

     Or, the script can be used to trigger automatic responses.

  4. Constantly monitors the audit directories for the appearance of new not_terminated audit files.

  5. Terminates outstanding tail processes when their files are no longer being written to.