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:
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).
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 | |
Plan storage space for the audit trail | |
Determine who and what to audit |
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.
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.
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.
Copy the audit_control file from the global zone to every non-global zone.
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.
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.
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.
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.
If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.
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 Example 30–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.
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.
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.
If you are implementing non-global zones, complete How to Plan Auditing in Zones before using this procedure.
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_warn, audit_event, audit_class, and audit_startup files as every other system.
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.
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.
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.
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.
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.
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.
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.
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–16.
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.
Audit policy determines the characteristics of the audit records for the local system. The policy options are set by a startup script. The bsmconv script, which enables the auditing service, creates the /etc/security/audit_startup script. The audit_startup script executes the auditconfig command to establish audit policy. For details about the script, see the audit_startup(1M) man page.
Most audit policy options are disabled by default to minimize storage requirements and system processing demands. You can dynamically enable and disable audit policy options with the auditconfig command. You can permanently enable and disable the policy options with the audit_startup script.
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
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.
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
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.
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.
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.
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:
Monitors the creation of audit files on all the audit file servers.
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.
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.
Constantly monitors the audit directories for the appearance of new not_terminated audit files.
Terminates outstanding tail processes when their files are no longer being written to.