C H A P T E R 6 |
Audit Configuration |
Entry-level servers can have a single domain, while midrange and high-end servers can run one or multiple domains. Those domains must be as secure as if they were running on physically separate servers. To help ensure that level of security, XSCF firmware provides the audit measures described in this chapter.
This chapter contains these sections:
The server logs all Service Processor events that could be relevant to security, such as system startup and shutdown, user login and logout, and privilege changes.
An audit record contains information about a single event, what caused it, the time it occurred, and other relevant information. A collection of audit records that are linked is called an audit trail. An audit trail can reveal suspicious or abnormal patterns of system behavior, in addition to identifying which user was responsible for a particular event.
Auditing is implemented through:
Audit records are stored in audit files on a 4-megabyte file system on the Service Processor. You cannot change the size reserved for the audit files, but you can transfer the files manually to remote storage at any time. You can also configure auditing for automatic transfers.
Audit files are stored in binary format, although you can export them to XML.
The audit file system switches storage between two partitions. Audit records are stored in one partition until it becomes full, then new records are stored in the other partition. Records in a full partition can be moved to a remote location, according to the audit policy.
If audit policy or network problems impede remote storage, the system generates an alarm. You can clear space by manually transferring the files to remote storage or by deleting them. Until you clear space, new records are dropped.
Because local space is limited to 4 megabytes, the partitions fill up quickly. If you do not configure audit policy to automatically transfer files to remote storage, you will have to intervene frequently or begin to drop records. If you are unable to maintain consistent audit trails, the utility of the audit system is limited. Typically, you either set up sufficient remote space and automatic transfers or disable the audit capability.
The minimum data recorded for each event includes:
Audit classes are categories for grouping and sorting audit events. The server provides a predefined set of audit classes, for example, log-in events and service-related events. You cannot define additional audit classes or change the events in a class. See the setaudit(8) man page for a list of audit classes.
Audit policy determines how the auditing feature is implemented at your site. You can configure the following aspects of auditing:
The default audit policy is as follows:
You can manage audit files from the Service Processor, using a tool for viewing audit files. See the viewaudit(8) man page for details on this tool.
This section describes these tasks:
To Enable or Disable Writing of Audit Records to the Audit Trail |
1. Log in to the XSCF console with auditadm privileges.
where enable enables writing of audit records, and disable disables writing of audit records.
To Configure an Auditing Policy |
1. Log in to the XSCF console with auditadm privileges.
XSCF> setaudit [-p count|suspend] [-m mailaddr] [-a users=enable|disable|default] [-c classes={enable|disable}] [-e events=enable|disable] [-g {enable|disable}] [-t percents] |
See the setaudit(8) man page for details on option information.
3. Verify the operation with the showaudit all command:
To Display Whether Auditing is Enabled Or Disabled |
1. Log in to the XSCF console with auditadm privileges.
2. Type the showaudit command:
To Display Current Auditing Policy, Classes, or Events |
1. Log in to the XSCF console with auditadm privileges.
2. Type the showaudit all command:
For additional information on this chapter’s topics, see:
SPARC Enterprise M3000/M4000/M5000/M8000/M9000 Servers XSCF User’s Guide |
Copyright © 2012, Oracle and/or its affiliates. All rights reserved.