Preparing for Auditing and Monitoring Solaris
The Solaris Knowledge Pack expands the auditing and reporting capabilities of InTrust to Oracle (formerly, Sun) Solaris. The Knowledge Pack enables InTrust to work with Syslog, text logs, and the Solaris Audit log.
The following table shows what you can audit and monitor on Solaris:
| Data Source | Gathering | Real Time Monitoring |
|---|---|---|
| Syslog messages | X | X |
| Text logs of any format | X | |
| Configuration file modification | X | X |
| Solaris audit logs generated by Basic Security Module (BSM) | X |
For Solaris Syslog, there is an agent-free approach to gathering, which is not covered in this guide. It involves Syslog forwarding to an InTrust server. For details about this method, see Setting Up Gathering of Syslog Data.
Requirements
For details about Solaris versions that InTrust can audit and monitor, see Solaris Events.
Installation
The Solaris Knowledge Pack must be installed on top of an existing InTrust installation. The following objects are included:
- Data sources:
- Solaris Syslog
- Solaris Audit Log
- Solaris Accounts Monitoring
- Solaris Text Files Monitoring
- Gathering policies:
- Solaris: Security: Common Syslog Security Events
- Solaris: Security: Failed Logons
- Solaris: Security: Successful Logons
- Solaris: Security: SU Activity
- Solaris: Security: Reboots
- Solaris: All Syslog Messages
- Solaris: logins/logouts from Audit Log
- Solaris: process execution events from Audit Log
- Solaris: filesystem events from Audit Log
- Solaris: All Events from Audit Log
- Solaris: Accounts monitoring
- Solaris: Text files monitoring
- Import policies:
- Solaris: Security: Common Syslog Security Events
- Solaris: Security: Failed Logons
- Solaris: Security: Successful Logons
- Solaris: Security: SU Activity
- Solaris: Security: Reboots
- Solaris: All Syslog Messages
- Solaris: logins/logouts from Audit Log
- Solaris: process execution events from Audit Log
- Solaris: filesystem events from Audit Log
- Solaris: All Events from Audit Log
- Solaris: Accounts monitoring
- Solaris: Text files monitoring
- Consolidation policies:
- Solaris Logs Consolidation
- Solaris Logs Consolidation for the Last Month
- Tasks:
- Solaris Syslog—daily collection of important security events
- Solaris audit log daily collection
- Solaris configuration changes daily collection
- Solaris weekly reporting
- "Solaris hosts" site
- "Solaris: security" Real-time monitoring policies:
- Predefined reports belonging to the following categories (for complete list of reports and report descriptions, refer to the InTrust Reports for Sun Solaris document):
- Administrative Activity
- Forensic Analysis
- Normal User Activity
Installing Agents
InTrust agents must be installed manually on Solaris hosts. For details, see Installing Agents Manually on Solaris Computers.
Preparing Audit Trails
InTrust takes advantage of the following logging systems available on Solaris:
- Syslog
- Basic Security Module (BSM)
Syslog provides data for auditing and real-time monitoring activities. Basic Security Module data is used only for auditing.
This topic describes the configuration requirements that InTrust imposes on these systems.
Configuring Syslog
Syslog is an important logging facility in Solaris. Syslog functionality is provided by the syslogd daemon, which accepts messages from various sources that support logging, and either writes these messages to files or passes them on to other hosts in the network.
The InTrust agent processes the message flow before it arrives at syslogd's input. However, the agent catches only the local messages; it does not catch messages redirected from other computers over the network. Therefore, do not rely on syslogd’s message redirection feature if you audit and monitor Syslog with InTrust. InTrust support for the Solaris Syslog depends on local messages.
It is up to you how you configure syslogd logging. This configuration does not affect the operation of the InTrust agent, which provides all the Syslog data that InTrust accepts.
Configuring Basic Security Module
Basic Security Module (BSM) in Solaris provides logging capability and stores system events in the Solaris Audit log. This section describes how to prepare BSM for InTrust operations.
To enable Basic Security Module Auditing
- Switch to run level 1 (System Maintenance Mode) using the following command:
/usr/sbin/init 1 - Enable BSM auditing with the following command:
/etc/security/bsmconv
When the system prompts you for confirmation, enter Y.
If you want to customize logging options, edit the Basic Security Module configuration files at this stage. The configuration files are listed further on. - Reboot the system.
When the system is rebooted, a message similar to the following will be displayed during the startup process to indicate that auditing has been enabled:
starting audit daemon
Configured 233 kernel events.
At this point, auditing is enabled, and a log file should be present in the /var/audit directory.
If BSM functionality is no longer required on a Solaris system, you can disable it using the bsmunconv command.
|
|
Note: When the bsmconv command is run, it disables the Stop-a keyboard sequence by adding set abort_enable = 0 to the /etc/system file. Disabling the ability of a user or administrator to stop a system through a keyboard Stop-a or equivalent command over a serial port may not be appropriate for all environments. |
BSM Configuration Files
The following table describes the BSM configuration files. For detailed information about configuring BSM, visit http://www.oracle.com/technetwork/indexes/documentation/index.html.
| File |
Description |
|---|---|
| audit_class |
An audit class is a group of audit events. All audit classes are defined in the /etc/security/audit_class file. All audit events are assigned to audit classes in the/etc/security/audit_event file. Audit classes are recorded in the audit trail if they are turned on globally in the audit_control file, or are assigned to a specific user in the audit_user database. These audit classes are used by the audit_control, audit_user, and audit_event files, as well as in the audit mask. |
| audit_control |
The /etc/security/audit_control file describes system parameters for auditing. These parameters include the following:
It is possible to audit only failed audit events or only successful audit events. For example, you can specify that a successful attempt to allocate memory should not be recorded but that a failed attempt should be recorded. This can be specified in either the audit_control or audit_user files. |
| audit_event |
The /etc/security/audit_event file defines the audit events and assigns each event to one or more audit classes. For additional information on the audit_event file, refer to the audit_event man page. |
| audit_user | The /etc/security/audit_user file enables you to specify additional auditing for individual users. Access to this database follows the rules for the password database specified in /etc/nsswitch.conf. |
|
|
Note: The InTrust agent does not modify the contents of token fields it retrieves from the Solaris Audit log. However, information in these fields is not sufficient if you store Solaris Audit log data in a centralized way. The agent complements this information by adding InTrust-specific fields to tokens. These fields are filled in by resolving the values of some fields for the current Solaris host. |