Planning Oracle 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. You also need to carefully plan who to audit and what to audit. If you are using the default audit_binfile plugin, audit files can quickly grow to fill the available space, so you must allocate enough disk space.

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. This configuration is the default.
You can configure one audit service per zone.

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

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 you are using the audit_binfile or the audit_remote plugin, and 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 service on a system, and collects audit logs for every zone. You customize the audit_class and audit_event files only in the global zone, then copy these files to every non-global zone.
  1. Use the same naming service for every zone.
    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.
  2. 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 configure per-zone auditing, set the perzone policy in the global zone. You do not need to enable policy in the global zone. To set audit policy, see How to Configure Per-Zone Auditing.
  - Each zone administrator configures auditing 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.
  - To generate records that can be traced to their originating zone during review, set the zonename audit policy.
  To plan per-zone auditing, see How to Plan Who and What to Audit. You can skip the first step. If the audit_binfile plugin is active, 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_binfile plugin creates an audit trail. The audit trail requires dedicated file space. This space must be available and secure. Best practice is to configure several audit directories for audit files. Laying out the audit directories is one of your first tasks before you enable auditing on any systems. The following procedure covers the issues that you must resolve 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.

You are using the audit_binfile plugin.

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.
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 How to Assign Audit Space for the Audit Trail.
Name the audit directories.
Create a list of all the audit directories that you plan to use. For naming guidelines, see Storing and Managing the Audit Trail and auditreduce Command.

How to Plan Who and What to Audit

Before You Begin

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

Determine if you want a single-system image audit trail.
Note - This step applies only to the audit_binfile plugin.

Systems within a single administrative domain can create a single-system image audit trail. If your systems use different naming services, start with Step 2. Then, 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 system. 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 for all systems.
  
  To interpret the audit records, two commands are used, auditreduce and praudit. For correct interpretation of the audit records, the passwd, group, and hosts 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.
- Configure policy, audit class preselections, and plugins identically for all systems.
Determine the audit policy.
By default, only the cnt policy is enabled.

Use the auditconfig -lspolicy command to see a short description of available policy options.
- For the effects of the policy options, see Determining Audit Policy.
- For the effect of the cnt policy, see Audit Policies for Asynchronous and Synchronous Events.
- To set audit policy, see How to Change Audit Policy.
Determine if you want to modify event-to-class mappings.
In almost all 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 want to modify event-to-class mappings.
For an example, see How to Change an Audit Event's Class Membership.
Determine which audit classes to preselect.
The best time to add audit classes or to change the default classes is before users log in to the system.
The audit classes that you preselect with the -setflags and -setnaflags options to the auditconfig command apply to all users and processes. You can preselect a class for success, for failure, or for both.
For an alphabetical list of audit classes, see Audit Classes.
Determine user exceptions to the system-wide preselections.
If you decide that some users should be audited differently from the system, use the audit_flags keyword to the useradd, usermod, roleadd, or rolemod command. You can also use the profiles command to add this keyword to the prof_attr database.
For the procedure, see How to Configure a User's Audit Characteristics.
Decide how to manage the audit_warn email alias.
The audit_warn script is run whenever the audit system detects 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.
Decide in which format and where to collect audit records.
You have three choices.
- By default, store binary audit records locally. The default storage directory is /var/audit. To further configure the audit_binfile plugin, see How to Create ZFS File Systems for Audit Files.
- Stream binary audit records to a remote protected repository. by using the audit_remote plugin. You must have a receiver for the files. For the procedure, see How to Send Audit Files to a Remote Repository.
- Send audit record summaries to syslog by using the audit_syslog plugin. For the procedure, see How to Configure syslog Audit Logs.
  
  For a comparison of binary and syslog formats, see Audit Logs.
Determine when to warn the administrator about shrinking disk space.
Note - This step applies only to the audit_binfile plugin.

When disk space on an audit file system drops below the minimum free space percentage, or soft limit, the audit service switches to the next available audit directory. The service then sends a warning that the soft limit has been exceeded. The default is no minimum free percentage, hence no warning.
To set a minimum free space percentage, see Example 30-16.
Decide what action to take when all the audit directories are full.
Note - This step applies only to the audit_binfile plugin.

In the default configuration, the audit_binfile plugin is active and the cnt policy is set. In this configuration, when the kernel audit queue is full, 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-6.
However, if the audit_binfile queue is full and the queue for another active plugin is not full, then the kernel queue will continue to send records to the plugin that is not full. When the audit_binfile queue can again accept records, the audit service will resume sending records to it.

Note - The cnt or ahlt policy is not triggered if the queue for at least one plugin is accepting audit records.

Skip Navigation Links
Exit Print View
	System Administration Guide: Security Services Oracle Solaris 11 Express 11/10