1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
3. Controlling Access to Systems (Tasks)
4. Controlling Access to Devices (Tasks)
5. Using the Basic Audit Reporting Tool (Tasks)
6. Controlling Access to Files (Tasks)
7. Using the Automated Security Enhancement Tool (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Role-Based Access Control (Reference)
Part IV Oracle Solaris Cryptographic Services
13. Oracle Solaris Cryptographic Framework (Overview)
14. Oracle Solaris Cryptographic Framework (Tasks)
15. Oracle Solaris Key Management Framework
Part V Authentication Services and Secure Communication
16. Using Authentication Services (Tasks)
19. Using Solaris Secure Shell (Tasks)
20. Solaris Secure Shell (Reference)
21. Introduction to the Kerberos Service
22. Planning for the Kerberos Service
23. Configuring the Kerberos Service (Tasks)
24. Kerberos Error Messages and Troubleshooting
25. Administering Kerberos Principals and Policies (Tasks)
26. Using Kerberos Applications (Tasks)
27. The Kerberos Service (Reference)
Part VII Oracle Solaris Auditing
28. Oracle Solaris Auditing (Overview)
29. Planning for Oracle Solaris Auditing
Planning Oracle Solaris Auditing (Task Map)
Audit Policies for Asynchronous and Synchronous Events
Cost of Increased Processing Time of Audit Data
Cost of Analysis of Audit Data
30. Managing 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.
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.
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.
The audit_user database might be a local file, or you might get it from a shared naming service.
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.
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.
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.
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.
On those systems, allocate space for at least one local audit directory. To specify the audit directories, see Example 30-3.
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.
Create a list of all the audit directories that you plan to use. For naming guidelines, see Storing the Audit Trail and auditreduce Command.
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.
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.
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.
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.
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.
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.
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.
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.
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.
For overview information, see Audit Logs.
For an example, see How to Configure syslog Audit Logs.