HP HP-UX Auditing System Extensions White Paper

HP-UX 11i v2 and 11i v3 Security

Configuring and Managing the Auditing System

Technical white paper

Table of contents

Audience............................................................................................................................................ 2

Introduction......................................................................................................................................... 2

Auditing system overview ..................................................................................................................... 3

Architecture..................................................................................................................................... 3

Audit tags ....................................................................................................................................... 5

Audit trail........................................................................................................................................ 5

Audit events .................................................................................................................................... 5

Audit tunable parameters (HP-UX 11i v3 only) ..................................................................................... 7

Self-auditing programs...................................................................................................................... 7

Auditing system extensions (HP-UX 11i v3 only) ................................................................................. 13

HP-UX Auditing System Administration.................................................................................................. 14

Installation..................................................................................................................................... 14

Configuration ................................................................................................................................15

Management................................................................................................................................. 18

Writing a DPMS service module .......................................................................................................... 19

Service Provider Interfaces (SPIs) ...................................................................................................... 19

DPMS service module implementation............................................................................................... 19

Best practices .................................................................................................................................... 19

Audit policy................................................................................................................................... 20

Audit generation and capture.......................................................................................................... 20

Audit retention and storage............................................................................................................. 21

Audit log analysis .......................................................................................................................... 21

Audit log configuration, security, and protection................................................................................ 22

Troubleshooting................................................................................................................................. 22

Glossary........................................................................................................................................... 24

For more information.......................................................................................................................... 26

Send comments to HP......................................................................................................................... 26

Audience

This white paper is for security administrators responsible for defining and implementing host audit security policies, and for system administrators responsible for configuring and managing HP-UX. This white paper provides guidance to administrators for planning, deploying, configuring, and managing the HP-UX Auditing System features on HP-UX 11i v2 with HP-UX Standard Mode Security Extensions (SMSE) installed and on HP-UX 11i v3 with HP-UX Auditing System Extensions installed. In addition, the white paper provides Best Practices that you can use to address certain compliance criteria. You can compare these settings with your internal security policy and any compliance criteria that must be satisfied.

Note

This paper does not address auditing on a system converted to trusted mode.

Introduction

The purpose of auditing is to selectively record security relevant events for analysis and detection of security breaches. The auditing system records instances of access by subjects to objects on the system, and enables you to detect any attempts to bypass the protection mechanism for objects, including the misuse of privileges. Auditing also helps expose potential security weaknesses in the system. Many regulations, such as PCI, HIPAA, and Sarbanes-Oxley, require some form of auditing.

In the past several years, industry and government oversight of businesses has increased dramatically. Guidelines and laws have been defined that require businesses to protect information and to impose more significant penalties for failure to do so. This protection of information goes beyond internal corporate information and extends to the privacy of customer data and practices for the protection of business operations and infrastructure. Adherence to these regulations is generally referred to as regulatory compliance or, simply, compliance. Businesses must demonstrate appropriate internal IT controls or face penalties for noncompliance. Significant regulatory compliances are as follows:

• Sarbanes Oxley (SOX) – Pertains to protection of public company financial data

• PCI – Pertains to customer credit card information

• HIPAA – Pertains to healthcare information

• Graham Leach Bliley Act – Pertains to financial institutions

• Safe Harbor – Pertains to international privacy protection

• SEC/OCC – Pertains to US financial securities (for example, stocks)

Most of these criteria do not mandate specific security mechanisms or processes, but they define a high level of practices to which businesses must adhere. Businesses must determine appropriate processes and mechanisms to meet the specified practices.

Auditing system overview

This section describes the HP-UX Auditing System architecture and provides a high-level description of the major HP-UX Auditing System components. For a complete introduction and overview of HP-UX Auditing System, see audit(5).

Architecture

Figure 1 shows the main user-space and kernel-space components of the HP-UX Auditing System on HP-UX 11i v2 and 11i v3. Components that are only available on HP-UX 11i v3 are labeled.

Figure 1. HP-UX Auditing System Architecture

HP-UX Auditing System consists of commands, daemons, configuration files, data files, libraries, kernel modules, and system calls. The following HP-UX Auditing System components are standard on HP-UX 11i v2 and 11i v3.

Commands

• audsys(1M) — Starts and halts the auditing system, sets and displays the auditing system status

information, and specifies the primary and secondary audit trails and their size switches.

• audevent(1M) — Changes and displays the auditing selection status of profiles, events, and

system calls.

• userdbset(1M) — Modifies the per-user AUDIT_FLAG attribute stored in the userdb(4)

database.

• audisp(1M) — Analyzes and displays the audit information contained in the specified audit trails.

For more information, see the corresponding manpages.

System calls

• audswitch(2) — Invoked by privileged programs to temporarily suspend or resume auditing on

the current process; it affects only the current process. This call cannot suspend auditing for processes created by the current process with the exec system call.

• audwrite(2) — Invoked by privileged self-auditing processes to generate higher-level audit

records of their own. These self-auditing processes are capable of turning off the generation of lowlevel (system call level) audit records using the audswitch(2) system call and turning it back on after invoking audwrite(2) to generate a higher-level audit record.

• getaudproc(2) — Invoked by privileged programs to determine whether the calling process is

audited or not.

• setaudproc(2) — Invoked by privileged programs to audit a process or not. For example,

for a new login session, depending on the value of the per-user or per-system AUDIT_FLAG attribute in userdb(4) or security(4) configuration files, respectively.

Daemons

• audomon(1M) — User space daemon that monitors the capacity of the current audit trail (Primary

Audit Trail) and the file system on which the audit trail is located. You can configure audomon to automatically switch to a Secondary Audit Trail when certain capacity limits are met. You can also configure the daemon to run a specified script after each successful switch to perform various operations on the last audit trail, such as running a script to copy the last audit trail to a remote system. For an example, see audomon(1M).

• Audit daemon — A kernel daemon that collects audit records and periodically writes the records to

the disk. On HP-UX 11i v2, the audit daemon is single threaded. On 11i v3, the audit daemon is multi-threaded to improve performance by writing audit data into multiple audit trail files simultaneously.

Files

• audit.conf(4), audit_site.conf(4) — Files containing event mapping information and

site-specific event mapping information, respectively. The audevent(1M) and audisp(1M) commands use these files.

• Audit trail — Audit records are collected in audit files as audit trails in binary format and are

compressed to save disk space. On HP-UX 11i v2, the audit trail is a single file. On HP-UX 11i v3, HP-UX Auditing System is capable of using more than one writer thread to log data to minimize the impact of audit on system performance. Each writer thread writes to one file, allowing an audit trail to be written in parallel by multiple kernel threads and potentially increasing the throughput of the system. As a result, an audit trail is present on the file system as a directory with multiple audit files in it.

• userdb(4) — The user database that contains the per-user AUDIT_FLAG attribute for controlling

whether a particular user is audited.

• security(4) — The security defaults configuration file that contains the per-system AUDIT_FLAG

attribute. This is the default AUDIT_FLAG attribute for those users that do not have a AUDIT_FLAG attribute set in userdb(4).

Audit tags

When a user logs in, a unique audit session ID called an audit tag is generated and associated with all audit records for the user's processes associated with that login. The audit tag is a string that includes the login name and the login time, and remains the same during the login session. Even if a user changes identity within a single session, all events are still recorded with the same audit tag and accountable under the original login user's name.

Audit trail

An audit trail contains all audit records in chronological order and provides a complete information trail for display and analysis. An active audit trail must be in use whenever the auditing system is enabled. Access to the auditing system, including the audit trails, is restricted to privileged users.

The Primary Audit Trail is the current audit trail in which audit records are currently being written, while the Secondary Audit Trail is the next audit trail that will store new audit records when certain capacity limits are reached for the Primary Audit Trail. The trail names and various attributes for the trails, such as the capacity limits, are set using the audsys(1M) command.

The audomon(1M) daemon determines when the current trail exceeds a specified size or when the auditing file system is dangerously full. When that occurs, the daemon automatically switches the Primary Audit Trail to the Secondary Audit Trail with the same base name but with a different timestamp extension. You can specify a script when starting audomon(1M) to perform various operations on the Primary Audit Trail that was just successfully switched, such as remotely copying the audit trail to a remote, centralized server for archiving purposes.

For performance reasons, the HP-UX Auditing System on 11i v3 is by default in normal mode in which the audit trail consists of multiple files under a single directory to allow concurrent writing of audit records by the kernel Audit Daemon. You can also configure the HP-UX Auditing System in compatibility mode in which the audit trail is a single file. For information on how to modify the audit trail mode on HP-UX 11i v3, see audsys(1M). For HP-UX Auditing System on 11i v2, an audit trail can only consist of a single file.

Audit events

The auditing system records instances of access by subjects to objects on the system in log files for selective security related system events. Audit events, also known as audit records, are generated when users make security-relevant system calls and when self-auditing programs invoke audwrite(2) to generate self-audit records. Each system call audit record and self-audit record contains the following information about the event:

• Who caused the event (the subject)

– Real and effective user name and process id – Audit session id and audit tag – Name of command executed to trigger the event – Hostname and IP address of source host from where the user logged in

• What is the event

– The event type: a system call event or a self-audit event – The object (for example, file being modified and the user login account) – Action performed on the object (for example, modification of a file’s permissions) – Whether the event succeeded or failed. If it failed, the reason for the failure.

• Where the event occurred (host name and IP address of host)

• When it occurred (timestamp)

• Details (for example, system call arguments and self-auditing text)

There are also audit records called version and system call table records that appear at the beginning of each audit trail, and a Process ID (PID) Identification Record for each audited process.

Each of these audit records consists of an audit record header and a record body. The record header comprises a sequence number, process ID, event type, and record body length. The sequence number gives relative order of all records; the process ID belongs to the process being audited; the event type is a field identifying the type of audited activity; the length is the record body length expressed in bytes. The record body is the variable-length component of an audit record, containing more information about the audited activity. The following sections describe each audit record type.

Version records

A version record is at the beginning of each audit trail and indicates the version of the audit subsystem. The audit record structure design might change over time, and the version record directs audit display applications how to interpret the audit trail.

System call table records

The record after the version record in an audit trail is a system call table record that contains kernel system call table information, such as what parameters or additional information are being collected for each system call. The system call table record enables user space applications that process the audit trail (for example, the audisp(1M) display tool) to determine how to interpret binary audit records at run time. This allows these applications to be decoupled from kernel changes (for example, addition of new system calls and addition of new audit information).

PID identification records

When a process is audited the first time, a PID identification record (PIR) is written into the audit trail, containing information that remains constant throughout the lifetime of the process. The PIR includes the process ID; the parent process' ID; audit tag; real user ID; real group ID; effective user ID; effective group ID; group ID list; effective, permitted, and retained privileges; compartment ID; and the terminal ID. The PIR is entered only once per process per audit trail.

System call audit records

A system call record contains system call specific audit data and is unique for each audited system call. The record contains, for example, the time the audited event completes, whether the system call ended in either success or failure, and the system call parameters. Use audevent(1M) to display the system calls that are currently being audited. On HP-UX 11i v2, use audisp(1M) to determine the associated information (for example, parameters and return values) recorded for each audited system call. On HP-UX 11i v3, use auditdp(1M) to determine the information recorded for each audited system call. The audisp and auditdp commands also report Compartments and Fine Grained Privileges (FGP) information on HP-UX 11i v2 and HP-UX 11i v3, respectively. This includes the compartment ID and effective, permitted, and retained privileges of the process.

Self-audit records

A self-auditing record contains high-level auditing data generated by self-auditing programs and Dynamically Loadable Kernel Modules (DLKMs). The record contains, for example, the time the selfauditing process invoked audwrite(2) to write the record and a high-level description of the event. For examples of self-audit records, see Self-auditing programs

Audit tunable parameters (HP-UX 11i v3 only)

You can modify the auditing operation dynamically by changing one of the following audit tunable kernel parameters:

• audit_memory_usage — Defines the percentage of physical memory to be used by audit

records. If the audit record memory usage exceeds the audit_memory_usage limit, the audit subsystem blocks the system call until memory usage decreases to within the limit. You can change this tunable value at any time. However, you cannot lower its value below the memory currently used by the audit subsystem for records. Valid values are 1 to 10, inclusive. The default is 5.

• audit_track_paths — Enables and disables tracking of current and root directories for the

auditing subsystem. When audit_track_paths is set to 0, Audit does not resolve absolute pathnames, and HP-UX HIDS is unable to open the device and collect data. This is because HIDS always expects a complete pathname for its purposes.

Setting the audit_track_paths to 1 enables both Audit and HP-UX HIDS to resolve and report absolute pathnames for their accounting purposes. This also causes additional tracking by the kernel, resulting in a small degradation in performance, even if auditing subsystem is not in use. The tunable is set to 0 (default) when the system is installed without HP-UX HIDS. The tunable is set to 1 when HP-UX HIDS is first installed. You cannot change this tunable when either HIDS or auditing is running.

Although not required, HP recommends you reboot the system when changing the audit_track_paths tunable to enable or disable the recording of absolute pathnames. Otherwise, Audit or HP-UX HIDS might not resolve and report absolute pathname consistently.

• diskaudit_flush_interval — Defines the periodic time interval (in seconds) between two

consecutive flushes of audit records buffered in the kernel memory. Set the value of this tunable so that buffers are cleaned when they are approximately half full, or are idle for a long time but still holding some data in the buffer. Keeping the tunable value too low results in flushing too soon and can lead to too many small write operations that can affect performance. On the other hand, keeping the value too high might lead to high unflushed memory consumption. Valid values are 1 to 100, inclusive; HP recommends a value from 3 to 6. The default value is 5.

The kctune command is the administrative command for HP-UX kernel tunable parameters. It provides information about tunable parameters and their values, and makes changes to tunable values. For more information, see kctune(1M).

Self-auditing programs

To reduce the amount of low-level log data and to provide a higher-level recording of some typical system operations, a collection of privileged programs are given capabilities (privileges) to perform self-auditing. Most of these programs generate audit data under a single event category. For example, audsys(1M) generates the audit data under the event admin. Other programs might generate data under multiple event categories. For example, the telnetd(1M) generates data under the events login and ipcopen. For a list of predefined event categories, see audevent(1M).

This section contains a description and list of the self-auditing programs and DLKMs on HP-UX 11i v3 that produce self-audit event records with self-audit text. The event names (in parentheses) indicate the event categories under which the self-audit record is generated.

Note:

The list assumes the installation of AuditExt v3.1 and corresponding patches as specified in the AuditExt v3.1 Release Notes.

The list and information is incomplete and might change in the future.

Audit aware

Most self-auditing programs are audit aware. They can suspend the currently specified low-level system call auditing on themselves by invoking the audswitch(2) system call and can produce a high-level description of the operations they perform by invoking the audwrite(2) system call to generate self-auditing events. The audit suspension they perform only affects these programs and does not affect any other processes on the system. The list of audit aware programs is as follows:

• audevent(1M) (admin)

audevent: getting event and syscall status audevent: [disable|enable] [success|failure] for [event|syscall] name

• audisp(1M) (admin)

audisp : argv1 … argvn (for various error conditions)

• auditdp(1M) (admin)

auditdp: argv1 … argvn auditdp: invalid command line auditdp: audit_dpms_write_nevent(3) failed auditdp: audit_dpms_read_event(3) failed auditdp: data has been successfully processed

• audfilter(1M) (admin)

audfilter: argv1 … argvn audfilter: User is not authorized to run audfilter audfilter: Invalid command line options audfilter: Daemon is not started yet audfilter: Request to kill daemon [failed|succeeded] audfilter: Request to load audit filtering rules [failed|succeeded] audfilter: Request to clear audit filtering rules [failed|succeeded] audfilter: Request to display audit filtering rules [failed|succeeded] audfilter: Request to display audit filtering rules in preview mode [failed|succeeded] audfilter: Request to display daemon status [failed|succeeded] audfilter: Request to change daemon’s wakeup period [failed|succeeded]

• audfilterd(1M) (admin)

audfilterd: argv1 … argvn audfilterd: User is not authorized to run audfilterd audfilterd: Failed to raise necessary privileges for audfilterd audfilterd: Failed to access the configuration file /etc/audit/filter.conf audfilterd: Invalid command line options audfilterd: Invalid wakeup period audfilterd: Daemon is already running audfilterd: Daemon status displayed audfilterd: Failed to install signal handler audfilterd: Failed to start the server audfilterd: Failed to fork as a background process: error message

• audomon(1M) (admin)

audomon: FreeSpaceSwitch point reached, audomon has successfully switched auditing to pathname of new audit trail audomon: AuditFileSwitch point reached, audomon has successfully switched auditing to pathname of new audit trail

+ 18 hidden pages