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.

2

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.

3

• 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 low­level (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,

login(1) invokes setaudproc(2) to audit or not audit a login process and all its descendents

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).

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.

5

• 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 self­auditing 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

.

6

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.

7

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

8

• 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

audomon: kernel audit daemon has switched auditing to the backup trail
audomon: FreeSpaceSwitch point reached, but audomon failed to switch
audit trail
audomon: AuditFileSwitch point reached, but audomon failed to switch
audit trail
audomon: failed to update audit trail configuration information in
/etc/audit/audnames:current_trail=pathname of current trail

• audsys(1M) (admin)

audsys: argv1 … argvn
audsys: various error condition messages (too many to list here)

audsys: current audit trail directory is changed to pathname
audsys: auditing system started
audsys: auditing system shut-down

• authadm(1M), roleadm(1M), cmdprivadm(1M) (admin)

ACCESS CONTROL CHECK:successful|failed; username=username;
program=authadm|roleadm|cmdprivadm; euid=euid; ruid=ruid; egid=egid;
rgid=rgid;

ACCESS CONTROL SUPPRESS:successful|failed; username=username;
program=authadm|roleadm|cmdprivadm; euid=euid; ruid=ruid; egid=egid;
rgid=rgid;

• chfn(1) (admin)

User= name Temporary file busy (open or lockf of /etc/ptmp failed)
User= name No account for user
User= Current user No passwd file entry
User= name Error in chown (of /etc/ptmp)
User= name Error in chmod (of /etc/ptmp)
User= name Successful chfn

• chsh(1) (admin)

User= name shell= shell Permission denied
User= name shell= shell Temporary file busy (open or lockf of /etc/ptmp
failed)
User= name shell= shell Can’t create temporary file (/etc/ptmp)
User= name shell= shell Can’t recover (can not rename /etc/ptmp to
/etc/passwd)
User= name shell= shell Chsh failed
User= name shell= shell Successfully changed

• dtlogin(1)

User=name uid= user id audid= audit id attempted to login - too many
users on the system

User=name uid= user id audid= audit id attempted to login - bad audit
flag

User=name uid= user id audid= audit id attempted to login - bad audit id
User=name uid= user id audid= audit id attempted to login - bad group id
User=name uid= user id audid= audit id attempted to login - bad user id
User=name uid= user id audid= audit id Successful login - no home

directory
User=name uid= user id audid= audit id attempted to login - no home

directory
User=name uid= user id audid= audit id Successful login
User=name uid= user id audid= audit id Failed login (bailout)

9

• groupadd(1M) (admin)

Attempt to add a new group failed
A new group added successfully.

groupname=name gid=gid
group_members=uid list

• groupdel(1M) (admin)

Attempt to delete a group failed
A group with groupname=name is deleted successfully

• groupmod(1M) (admin)

Attempt to modify a group failed
The group record of groupname=%s is modified successfully

[New_groupname=name] |
[ gid=gid] |
[New_group_members=uid list]

• inetd(1M)

inetd: Failed setauduser for user username

• init(1M) (admin)

Run level is changed to level
Dead process: pid

• lpsched(1M) (open)

File(s) filename(s) was printed for user username @ hostname on printer
printer name
File(s) filename(s) was not printed for user username @ hostname on
printer printer name due to an error.

• newgrp(1) (modaccess)

newgrp=name [Failed|Successful] newgrp
newgrp=name setresuid failed

• passwd(1) (admin)

User= username passwd successfully changed
User= username shell successfully changed
User= username home directory successfully changed
User= username gecos information successfully changed
Attempt to change <passwd|shell|home|gecos information> failed

• privedit(1M) (admin)

ACCESS CONTROL CHECK: privedit: attempt to edit file: file=’filename’;
username=username; program=privedit; euid=euid; ruid=ruid; egid=egid;
rgid=rgid;

ACCESS CONTROL CHECK: privedit: failed to edit file: file=’filename’;
username=username; program=privedit; euid=euid; ruid=ruid; egid=egid;
rgid=rgid;

10

• privrun(1M) (admin)

ACCESS CONTROL CHECK: privrun: attempt to execute command:
command=command; username=username; program=privrun; euid=euid;
ruid=ruid; egid=egid; rgid=rgid;

ACCESS CONTROL CHECK: privrun: command execution failed:
command=command; username=username; program=privrun; euid=euid;
ruid=ruid; egid=egid; rgid=rgid;

• setfilexsec(1M) (modaccess)

Could not lock file
No passwd entry
Memory allocation failed
Failed to re-exec the command after initializing FAT
Not authorized
Failed to raise necessary privileges
Could not register exit routine
Configuration file update failed for file pathname

• setrules(1M) (admin)

Memory allocation failure
Failed to create ipc rules for compartments (filename>, line #)
Failed to create network rules for compartments (filename, line #)
Undefined compartment cmpt_name referenced in (filename, line #)
Conflicting network rule definition between cmpt_name and cmpt_name
(filename, line #)
Could not create pipe for c-preprocessor
Could not create child process
Failed to remove privileges in the child process
Could not setup pipe communication
Failed to exec cpp
Conflicting network rule definition between cmpt_name and cmpt_name
(filename, line #)
Bad IPC rule: rule definition between cmpt_name and cmpt_name (filename,
line #)
Duplicate compartment definition for cmpt_name (filename, line #)
Compartment name too long: cmpt_name
Duplicate interface rule for network interface name in compartment
cmpt_name (filename, line #) and compartment name (filename
Pre processing of rule file filename failed

, line #)

• useradd(1M) (admin)

Attempt to modify template file failed
Attempt to add a new user failed
A new user added successfully, username=name uid=uid gid=gid shell=shell
pathname home_dir=pathname comment=comment audid=audit id inactive=#days
expire=date|’’’’

Template file pathname was modified successfully | The defaults file is
modified successfully [HOMEDIR=pathname] [GROUPPID=pgid] [INACT=#days]
[[EXPIRE] | [EXPIRE=MM/DD/YY]] [CHOWN_HOMEDIR=pathname]
[START_PROGRAM=shell path] [SKEL_DIR=pathname] [COMMENT=comment]
[CREAT_HOMEDIR=pathname] [ALLOW_DUP_UIDS=yes|no]

• userdel(1M) (admin)

Attempt to delete a user failed
A user with username=name is deleted successfully

• usermod(1M) (admin)

Attempt to modify a user record failed
The user record of user=name is modified successfully

[New_username=name] [uid=uid] [gid=gid] [home_dir=pathname] [shell=shell
path] [comment=comment] [supplementary_groups=gid list] [inactive=#days]
[expire=date string]

11

Audit unaware

Some self-auditing programs do not invoke the audswitch(2) system call to suspend system call
auditing on themselves, nor directly invoke audwrite(2) to generate self-audit records. Instead,
these privileged programs invoke a library routine that generates a self-auditing event on its behalf.
For example, telnetd(1M) is a privileged program that invokes the pam_hpsec(5) PAM module
for authenticating users. The hpsec PAM module invokes the audwrite(2) system call to generate
successful and failed login self-audit events on behalf of telnetd. In addition, a logoff self-auditing
event is generated on telnetd’s behalf by a DLKM.

The following self-auditing programs invoke the hpsec PAM module for authenticating users:

• telnetd(1M), rlogind(1M), sshd(1M), remshd(1M), rexecd(1M), su(1), ftpd(1M)

(login,ipcopen)

login event: Service=telnet|login|ssh|ftp User=login_user
Status=Successful (login)
login event: Service=shell|exec User=login_user Status=Successful

Command="command & args" RemoteUser=remote_user
login event: Service=telnet|login|ssh|ftp> User=login_user Status=Failed
("Authentication failed") (login)
login event: Service=su User=target_user Status=Failed("Authentication

failed")
login event: Service=ftp User=login_user Status=Failed
login event: Service=telnet|login User=login_user Status=Failed ("No
account present for user") (login)
login event: Service=shell|exec User=login_user Status=Failed("Access

denied by ruserok.") Command="command & args" RemoteUser=remote_user
Networking service = telnet|rlogin|rexec|shell

Request outcome = success|failure
Validation tool = unspecified|passwd
Service event = start_of_service|unspecified
Remote system = ip address
Remote user = username|unspecified
Local system = ip address
Local user = username|uid|unspecified
Login successful. User =
Access denied by ruserok|
exec “login –p –h remotehost login_user|

Executing login pid = pid.” (ipcopen)
Networking service = ftp

Request outcome = success|failure
Validation tool = unspecified|passwd
Service event = start_of_service|unspecified
Remote system = ip address
Remote user = username|unspecified
Local system = ip address
Local user = username|uid|unspecified
Login successful. User = username |
Repeated login failures. |
Failed login attempt - shell not in /etc/shells. |
Failed login attempt - name in /etc/ftpd/ftphosts. |
Failed login attempt - Anonymous FTP access denied. |
Failed login attempt - guest login not permitted. |
Failed login attempt - access denied for user. |
Failed login attempt - user unknown. |
Failed login attempt - user access denied. |
Failed login attempt - Kerberos authentication must succeed. |

username|

12

Failed login attempt - login incorrect. |
Failed login attempt - anonymous password not rfc822. (ipcopen)

The login event for the Service=su self-audit event is only generated when the pam.conf entry
for su does not have the bypass_setaud flag set and when source user is not root. See
pam_hpsec(5).

Dynamically Linked Kernel Modules

DLKMs can generate the following self-audit records:

• Command command tried to execute code from stack

• Command command has core dumped

• logoff event: Service=telnet|login|ssh|shell|exec User=login_user (login)

Generated only when AudReport product is installed.

• logoff event SID session_id PGRP process_group PPID parent_pid PID pid

program (login) Generated only when AudReport product is not installed

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

On HP-UX 11i v3, HP-UX Auditing System Extensions extends the features of the HP-UX Auditing
System by offering the following features and benefits to better facilitate regulatory compliance:

• Enhanced audit data (for example, program name and source IP address)

• Enhanced filtering capabilities to filter non-relevant data based on customer-specific needs and

improve the quality of the audit trail

• Performance improvement by reducing the I/O activities of logging events that are not required to

be logged

• Enhanced manageability of the audit log data

• Command line interface and a set of open APIs for extracting audit data

• Tools to generate web-based audit reports from HP-UX raw audit data

HP-UX Auditing System Extensions provides two major products for enhanced audit record filtering
and reporting.

Audit Filtering

Audit Filtering features are available on HP-UX 11i v3 with the AudFilter product that contains a set of
tools to customize and enforce the audit data pre-filtering policy on the system and the
audit_filters DLKM that makes filtering decisions and enforces the filtering policy in the kernel.
An efficient pre-filtering policy controls the size and quality of the raw data, minimizes the
performance impact of auditing, and reduces the operational cost associated with audit data
management. The AudFilter product consists of the following major components:

• The filter.conf configuration file that specifies the rule-based audit record pre-filtering policy

enforced in the kernel. For more information, see filter.conf(4).

• The audfilter configuration tool to interpret the filtering policy as specified in the configuration

file, filter.conf, and to implement the policy. You can also use the audfilter tool to display
or clear out the filtering policy currently being enforced in the kernel. For more information, see
audfilter(1M).

• The audfilterd service daemon handles service requests from the audfilter tool, and

reevaluates and reloads the filtering policy whenever the mounted file system table changes. For
more information, see audfilterd(1M).

13

• The audit_filters DLKM makes filtering decisions and enforces the filtering policy in the kernel.

Filtering in the kernel can occur both before and after the invocation of the system call code. See
the definitions of system call pre-filtering and post-filtering in Glossary

Audit Reporting

The AudReport product consists of the following components:

• Commands

auditdp(1M) — An audit data processing tool that selectively extracts, or filters, audit data from
a data source in one of several possible formats and writes the data to the target, in the same or
different format. The tool uses the DPMS framework, and is available only on HP-UX 11i v3 with the
AudReport product installed.

• Libraries

DPMS (Data Process Module Switch) — A framework implemented as a library that contains a set
of common programming interfaces (APIs) and Service Modules to selectively read and write audit
data in various formats (for example, XML Audit Reports).

DPMS provides a layer of separation between applications (for example, auditdp(1M)) that need
to extract information from audit data source and the underlying modules that have the knowledge
about the internal data format. This framework is primarily designed for HP-UX audit data that the
HP-UX system collects (see audit (5)). However, the framework allows service modules to be
plugged in to handle the data in any format. With this layer of separation, an application can treat
any data using the same APIs by simply applying the service module corresponding to the given set
of data. The application does not need knowledge about the internal format of the data to use the
information.

For more information on DPMS, see audit_dpms(5). For a description of the various DPMS
Service Modules, see audit_hpux_portable(5), audit_hpux_raw(5), and

audit_hpux_xml(5). For a description of the Audit DPMS APIs that applications writers use, see
audit_dpms_api(3). For a description of the Audit DPMS Service Provider Interface that a

DPMS Service Module writer must support, see audit_dpms_spi(3). For a description of the
configuration file for filtering Audit DPMS data, see audit_dpms_filter(4). For a description
of how a DPMS service module is implemented, see Writing a DPMS service module

.

.

14

• Files

One or more configuration files that you can use to select auditing information in the audit trail to
include in an audit report. You specify the files using the auditdp –S option. They contain filtering
rules that are described in audit_dpms_filter(4).

HP-UX Auditing System Administration

This section describes the basic installation, configuration, and management of the HP-UX Auditing
System by the Audit Administrator.

Installation

The features described in this paper assume the following software has been installed, depending on
the HP-UX release:

• HP-UX Standard Mode Security Extensions (SMSE) (HP-UX 11i v2)

Previously, the auditing system was only supported on systems converted to trusted mode. By
installing the HP-UX Standard Mode Security Extensions bundle, you can now perform audits
without converting the system to trusted mode.

• HP-UX Auditing System Extensions (HP-UX 11i v3)

The auditing system is installed as part of the base HP-UX 11i v3 distribution. However, Auditing
System Extensions bundle must be installed to make use of the AudReport and AudFilter product
features.

Both products are available on software.hp.com and have Release Notes on the Business Support
Center that contain details about product compatibility, installation requirements, patch requirements,
and installation instructions.

Configuration

This section describes guidelines and steps for configuring users for audit, configuring events for
audit, and roles.

Configuring users for audit

Users are audited depending on the value of either the system wide AUDIT_FLAG security attribute or
the per-user AUDIT_FLAG security attribute. The AUDIT_FLAG security attribute is described in
security(4). A user is audited if either of the following conditions is true:

• The user AUDIT_FLAG is set to 1.

• The system wide AUDIT_FLAG is set to 1.

To set the system wide and per-user AUDIT_FLAG values, use either of the following methods:

• userdbset command. See userdbset(1M) and userdb(4).

• HP-UX Security Attributes Configuration tool. See secweb(1M).

The audit user selection policy is based on the AUDIT_FLAG setting for the user responsible for the
event. The responsible user is traced back to the original login user, not to the user corresponding to
the real or effective user at the moment an event happens. For example, a user logins as user “Joe”
and then either executes a setuid program to run as user “Ben” or issues the su command to the
target user “Ben.” All events that occur while “Joe” is running as “Ben” are attributable to the original
login user “Joe” and are audited depending on the AUDIT_FLAG security attribute for login user
“Joe,” not on the AUDIT_FLAG security attribute for user “Ben.” For su(1), you can modify this user
selection policy to audit based on the target user (see description of the bypass_setaud flag in
pam_hpsec(5)), if su(1) requires the source user to be authenticated and the authentication is
successful. Because root does not need to authenticate when invoking su(1), users logged in as root
are always audited as user root, regardless of the bypass_setaud flag setting for su(1).

If a user is not selected for auditing, audit records associated with the user are generated in the
following cases:

• At the time user starts a session and ends a login session. Those events are considered system

events more than user events and are therefore generated based on whether the login event is
being audited rather than whether the user is being audited.

• By programs that do self-auditing and make arbitrary decisions to ignore the user selection.

• If Audit Filtering (11i v3 only) is configured to generate audit records for those users who are not

selected for auditing using the !audited_process flag. See filter.conf(4).

• System call auditing of inetd spawned daemons if inetd is not started with the –a option.

If a user is selected for auditing, audit records associated with the user are not generated in the
following case:

15

• The root user runs su – non_root_user, where the target non-root user is being audited. When

the root user switches to another user, the Pluggable Authentication Module (PAM) is not invoked;
no authentication is done when running as root. Therefore, audit records are not generated as
being triggered by the non-root target user, but are instead attributable to the root user.

Configuring events for audit

Use the audevent(1M) command to specify system activities (auditable events) that you want to
audit. Auditable events are classified into event categories and profiles for easier configuration. After
an event category or a profile is selected, all system calls and self-auditing events associated with that
event category or profile are selected. When the auditing system is installed, a default set of event
classification information is provided in /etc/audit/audit.conf file. In order to meet site-specific
requirements, you can also define event categories and profiles in

/etc/audit/audit_site.conf. For more information, see audit.conf(4) and
audevent(1M).

On HP-UX 11i v3, the AudFilter product enables you to audit events not audited according to
audevent(1M) by specifying a filtering rule that contains the !audited_event directive.

Configuring audit filtering

To configure and load audit filtering, follow these steps:

1. Customize the filtering rules in /etc/audit/filter.conf. The filter.conf file contains the

rule-based audit filtering policy that the auditing subsystem uses to determine what activities to
audit on the system. For more information, see filter.conf(4).

2. Start the filter daemon as follows:

# audfilterd –s

The audfilterd service daemon handles service requests from the audfilter(1M)
configuration tool, and reevaluates and reloads the filtering policy whenever the mounted file
system table changes. For more information, see audfilterd(1M).

3. Load the filtering rules as follows:

# audfilter –c

The audfilter configuration tool interprets the filtering policy as specified in the filter.conf
configuration file and implements the policy. Use audfilter to display or clear out the filtering
policy currently in effect.

Configuring audit settings to be preserved across reboots

To preserve audit settings across reboots, edit the /etc/rc.config.d/auditing file and make
the following changes as needed:

• AUDITING flag –- Set to 1 to enable the auditing system at system startup.

• Primary and secondary log files

– PRI_AUDFILE – Absolute pathname of the audit trail where audit records begin to be logged.
– PRI_SWITCH – Switch size (maximum size in kilobytes) for the primary audit trail
– SEC_AUDFILE – The trail to which the audit system switches when the primary reaches switch

size.

– SEC_SWITCH – Switch size (maximum size in kilobytes) for the secondary audit trail

16

• Number of log files in an audit trail

NTHREADS – The number of log files that compose an audit trail. The recommended value is the
number of processors on a system divided by two.

• Audevent settings – Arguments to the audevent command

– AUDEVENT_ARGS1 describes those events that are audited for both success and failure.
– AUDEVENT_ARGS2 describes those events that are success only.
– AUDEVENT_ARGS3 describes those events that are failure only.
– AUDEVENT_ARGS4 describes those events that are audited for neither success nor failure.

• Audomon settings

AUDOMON_ARGS describes arguments to the audomon daemon.

Configuring roles

You can base auditing on HP-UX Role-Based Access Control (RBAC) criteria and the

/etc/rbac/aud_filter file. HP-UX RBAC Version B.11.23.02 and later support the use of an

audit filter file to identify specific HP-UX RBAC criteria to audit. You can create a filter file named
/etc/rbac/aud_filter to identify specific roles, operations, and objects for which to generate
audit records. Audit records are generated only if the attributes of a process match all three entries
(role, operation, and object) found in /etc/rbac/aud_filter. If a user's role and associated
authorization are not found in the file or do not explicitly match, no audit records specific to role-to­authorization are generated.

Authorized users can edit the /etc/rbac/aud_filter file using a text editor and specify the role
and authorization to be audited. Each authorization is specified in the form of operation, object pairs.
All authorizations associated with a role must be specified in a single entry. You can specify only one
authorization per role on each line; however, the wildcard character (*) is supported. The following
are the supported entries and format for the /etc/rbac/aud_filter file:

role, operation, object

• role – Any valid role defined in /etc/rbac/roles. If * is specified, all roles can be accessed

by the operation.

• operation – A specific operation that can be performed on an object. For example,

hpux.printer.add is the operation of adding a printer. Alternatively, hpux.printer.* is the
operation of either adding or deleting a printer. If * is specified, all operations can be accessed by
the operation.

• object – The object the user can access. If * is specified, all objects can be accessed by the

operation.

The following are examples of /etc/rbac/aud_filter entries that specify how to generate audit
records for the role of SecurityOfficer with the authorization of (hpux.passwd,

/etc/passwd), and for the Administrator role with authorization to perform the
hpux.printer.add operation on all objects:

SecurityOfficer, hpux.passwd, /etc/passwd
Administrator, hpux.printer.add, *

Note

When HP-UX SMSE B.11.23.02 is used in conjunction with HP-UX RBAC
(version B.11.23.04 or later) on HP-UX 11i v2, you can restrict the use of
the userdbset command based on user authorizations.

17

Use an editor (for example, vi) to directly edit the
/etc/rbac/aud_filter file. The HP-UX RBAC administrative commands
do not provide an interface to configure /etc/rbac/aud_filter.

Management

This section describes how to enable and disable auditing, and how to rotate audit log files.

Enabling auditing

To enable auditing, use one of the following methods:

• Enter the /sbin/init.d/auditing start command. When you do this, the following occurs:

– Reads the /etc/rc.config.d/auditing file.
– Displays events to be audited by running audevent using the AUDEVENT_ARGS flags.
– Turns on the auditing system by running audsys -n.
– When audsys is run for the first time, the command creates the /etc/audit/audnames file

using the log file names and sizes specified by PRI_AUDFILE and SEC_AUDFILE. Thereafter, each
time the audsys -n command is invoked, it uses the audit log names and sizes from the
audnames file.

– Starts the audomon daemon with the AUDOMON_ARGS.

• HP-UX Security Attributes Configuration Tool

Used to view and configure system-wide and per-user (local users and NIS users) values of security
attribute. You can launch this from the HP System Management Homepage (SMH) or HP System
Insight Manager (SIM). For more information, see secweb(1M).

• Entering the audsys –n and audomon commands manually.

Disabling auditing

To disable auditing, enter the audsys –f command.

Rotating audit logs

To enable audit log rotation, run the audomon daemon. The audomon daemon monitors the capacity
of the current audit trail and the file system on which the audit trail is located, by checking the
FileSpaceSwitch (FSS) and AuditFileSwitch (AFS) switch points. If either switch point is reached, audit
recording automatically switches to an alternative audit trail. For example, if the auditing system was
started using audsys -n -c /var/.audit/my_trail -s 1000, the following command starts
the audomon daemon:

audomon -p 20 -t 1 -w 90 -X "/usr/local/bin/rcp_audit_trail hostname”

This command has the following behaviors:

• The audomon daemon sleeps at least 1 minute at intervals.

• When the size of the current audit trail reaches 1000*90% or 900 kilobytes, or the file system that

contains the current audit trail has reached (100%-20%) * 90% or 72% full, audomon starts
printing warning messages to the console.

• When the size of the current audit trail reaches 1000 kilobytes, or the file system that contains the

current audit trail has reached 100% - 20% or 80% full, audomon switches recording data to:
/var/.audit/my_trail.yyyymmdd_HHMM, where yyyymmdd_HHMM is replaced by the time
when the switch has happened.

• After the switch succeeds, audomon invokes the following command:

18

sh -c "/usr/local/bin/rcp_audit_trail hostname /var/.audit/my_trail"

This copies /var/.audit/my_trail to a remote system, assuming that is what the given script
intends to do.

Writing a DPMS service module

The Audit Data Process Module Switch (Audit DPMS) framework offers the ability to selectively access
audit data in various formats through a set of common programming interfaces. It provides a layer of
separation between applications that need to extract information from audit data source and the
underlying modules that have the knowledge about the internal data format. For more information,
see audit_dpms(5).

The framework allows Audit DPMS service modules to be plugged in to handle the data in any
format. The service modules are a set of dynamically loadable objects invoked by the Audit DPMS API
to handle a particular type of audit data and format. Currently, HP-UX provides three DPMS service
modules to handle reading and writing from and to HP-UX raw audit data, reading and writing from
and to HP-UX portable audit data, and writing to XML format data. For more information, see
audit_hpux_raw(5), audit_hpux_portable(5), and audit_hpux_xml(5), respectively.

You can develop new DPMS service modules to plug into the Audit DPMS framework to handle audit
data from a source in another format. This section describes how to write a DPMS service module.

Service Provider Interfaces (SPIs)

A new DPMS service module must support the Audit DPMS Application Programming Interfaces (APIs)
(for example, audit_dpms_start(3), audit_dpms_end(3), audit_dpms_read_event(3),
and audit_dpms_write_event(3)) by implementing the corresponding DPMS service module
Service Provider Interfaces (SPIs) (audit_dpm_start(3), audit_dpm_end(3),
audit_dpm_read_event(3), and audit_dpm_write_event(3)). The Audit DPMS interface
library is the layer implementing the APIs, while the Audit DPMS service modules implement the APIs
for different audit record formats. For more information about the Audit DPMS APIs, see

audit_dpms_api(3). For more information about the Audit DPMS SPIs, see
audit_dpms_spi(3).

A new DPMS service module can make use of the Audit DPMS interface to allow an application to
register a set of filtering rules where only the audit events that meet the filtering criteria are returned to
the caller. This interface is provided entirely within the DPMS switch; DPMS modules therefore do not
provide a plug-in for this interface. For the grammar of the filtering rules, see
audit_dpms_filter(4).

DPMS service module implementation

A sample DPMS service module will be available on a future release of the AudReport product.

Best practices

Although best practices must be developed by each individual organization based on their particular
environment, there are some general best practices that can be universally applied.
contains best practices to provide guidance for making decisions as part of the planning stage.

This section

19

Audit policy

Develop a policy for auditing based on the amount of security the site requires, the types of users
administered, and the costs of auditing. Document the policies, perform periodic reviews, and update

policies as needed. Based on the policy, take the following decisions as part of planning:

• Decide which users and events to audit based on the site policy.

• Decide whether to audit the selected events for success, for failure, or both. Auditing for failure

locates abnormal events; auditing for success monitors system use.

• Determine level and format of audit info depending on the site policy.

• Define roles (who gets to do what)

– Security Administrator

Plans what to audit according to site security policy and goal; implements policies; and develops
an archive strategy and encryption of archives.

– System Administrator

Plans for disk space (local and remote) and other resources; configures automatic backup,
archiving, and log rotation; and for centralized management, determines audit server and
network layout of audited systems.

– HP-UX RBAC

Implement roles such as readers of audit trails to protect audit trails from snooping.

• Establish standard operational procedures to support and maintain the policies. For example:

– Decide whether audit subsystem must block, suspending system activities so no audit data is ever

lost, or must discard records rather than suspending system activities when the disk space is
exceeded on audit file systems.

– Determine a regular maintenance schedule that can automatically back up and free up space for

more audit records.

Audit generation and capture

Collecting sufficient data to meet the requirements of regulations and forensic analysis is a big
challenge. For example, the payment card industry standard requires organizations to track and
monitor all access to network resources and cardholder data. Data must be collected from many
sources including security systems, operating and storage systems, and applications. Events that must
be recorded include the following:

• Privileged, administrative or root access.

• Enabling and disabling of security system and accesses to audit logs.

• System and service startup and shutdown.

• File accesses and changes to access rights on servers.

• Rejected system, application, file, or data access attempts and other failed actions.

• Login attempts and the amount of data sent and received during the session on remote access and

wireless access system.

Note:

Log sources typically reference an internal clock when placing a time stamp
on a log entry. Ensure all log sources internal clocks are synchronized to a
trusted, accurate time server.

20

Audit retention and storage

Storage cost is the most significant operational cost of auditing. The amount of audit data depends on
the site policy for the following major factors: different number of users; different usage of the system
or system loads (web or application server, timesharing system, workstation); degree of traceability
and accountability that is required. As you plan for the storage of audit logs, remember the following:

• You must set aside more disk space for the audit trail if auditing is done for monitoring of system

use than auditing for abnormal events.

• You can reduce storage cost by reducing the amount of audit data generated. Define pre-filtering

rules, using the AudFilter product, that reduce the potential size of the audit trail while not
compromising security. You can define filtering rules for events that are not generally interesting for
audit purposes. For example, any read-only operations on world-readable objects, operations on
non-existing files, any operation on files owned by the user on /home.

• If you expect the audit data volume to be high, configure audit trails on a logical volume consisting

of multiple physical disks and multiple physical I/O cards. Use the -N option with audsys
command to split the audit trail into multiple files.

• Frequently accessed data, such as production data, must be available on-line. Data not requiring as

frequent or ready access such as back-up data can be stored off-line. You can use the auditdp
command to filter on-line data to remove unnecessary information. This enables you to keep the
audit file at a manageable size and keep the less interesting information in off-line, backup storage.
For example, use auditdp to filter only login and logout events from one month’s audit trail. If you
need to access other records, you can recover them from off-line backup tapes.

• To keep audit files at a manageable size, you can invoke the audomon daemon. This monitors the

capacity of the current audit trail and the file system on which the audit trail is located. If either
capacity limit is reached, audit recording automatically switches to an alternative audit trail and
backs up the current audit trail to a secondary storage".

• Deploying a log management solution is better than storing audit data distributed across systems

because it facilitates access to logged data collected from across the organization and unifies
searching, reporting, alerting, and analysis across any type of enterprise log data.

• Ensure that when the required data retention period has ended, the logs are retired by destroying

them according to the organization's data destruction policies.

Audit log analysis

The cost of analysis is roughly proportional to the amount of audit data collected. The cost of analysis
includes the time it takes to review audit records, and the time it takes to archive them and keep them
in a safe place. The following best practices address the need to make analysis easier, enabling the
organization to extract the wealth of information logs can provide:

• Regular review and analysis helps to identify late hours login, login failures, failed access to system

files, and failed attempts to perform security-relevant tasks. Depending on the systems, risk
environment, and other requirements, logs must be reviewed in real-time, daily, monthly, or every
90 days.

• Automation can significantly improve analysis because it takes much less time to perform and

produce more valuable results.

• Analyzing logs using a log management solution is better than analyzing logs separately in

different systems because attacks usually involve multiple assets.

• You can analyze logs by extracting useful reports from the audit trail by using the following tools:

– Audit Record Display (audisp) in HP-UX 11i v2.

21

– Audit Trail Reports (auditdp) in HP-UX 11i v3. In addition, you can use the following tools in

/opt/audit/AudReport/bin:

audit_p2l — This sample script demonstrates how to convert audit data in portable format (see
audit_hpux_portable(5)) to message lines similar to syslog. The script takes no options or

arguments. It reads portable audit data from stdin and outputs the message lines to stdout.
For example, in order to convert HP-UX raw audit data to messages in follow mode and store the
results in /var/adm/auditlog, issue the following command line:

$ auditdp -r <raw_audit_log> -P -o follow -O sync | \
audit_p2l > /var/adm/auditlog &

auditreport_generator — This sample script demonstrates how to use the auditdp

command (see auditdp(1M)) to generate a collection of web-based audit reports, for example,
login history data, logoff history data, su history data, root account activities report, and file
access report.

auditreport_setup_web — This sample script sets up the Apache server properly to bring up
the generated audit reports in a web browser. It includes setting up the password that is required
to access the audit reports through web; setting up the http alias; and restarting or bringing up
the Apache server.

Audit log configuration, security, and protection

Ensuring the confidentiality, integrity, and availability of logs is very important. As you plan for this,
remember the following:

• Logging mechanisms must neither be deactivated nor compromised to provide business continuity of

logging services in the event of an incident.

• Ensure that log files cannot be edited or deleted. Generally only administrators and auditors must

have access to log files for review and management only. All privileged user (the administrator and
auditor) access must be logged and reviewed thoroughly and frequently by others outside that user
domain.

• Communications must be protected with mechanisms such as encryption (for example, HP-UX IPSec

and SSL).

• Protect the confidentiality and integrity of log files using either message digests or encryption or

digital signatures.

• Provide adequate physical protection for logging mechanisms and stored logs by preventing

unauthorized physical access.

Troubleshooting

This section describes potential problems and their solutions. To stay current with product updates and
patches, monitor the HP security software news and events web site at www.hp.com/security

• Self-audit login events are being generated for users even though they are disabled for auditing.

When a user remotely logs in using telnet, ssh, and remsh, user authentication is performed by
the pam_hpsec(5) PAM module. The module always generates self-audit login events, regardless
of whether auditing for a user is enabled (AUDIT_FLAG=1) or disabled (AUDIT_FLAG=0).
Likewise, logoff events are generated by a DLKM when the user logs off.

.

22

• System call level events are being generated for daemons spawned by inetd (for example,

telnetd(1M) and remshd(1M)) even though auditing is disabled for user root.

The inetd daemon honors the AUDIT_FLAG only for the user under whom the service is run when
inetd is started with the –a option. Self-audit login and logoff events are generated regardless of

the inetd –a option and whether the user is enabled or disabled for auditing. Most inetd
services run as user root and disabling auditing for root is not recommended, as this results in no
system call auditing of users logged in as root.

• After upgrading AuditExt, starting Audit with audsys –n returns the failed to match audit

trail version; specify different audit trail error.

The version of the audit trail for the upgraded product is newer than the previously installed
product. You must disable auditing (audsys –f) before upgrading the AudReport product. To
proceed after receiving this error, disable auditing and then enable it to start creating an audit trail
with the latest version. The new version can include more audit data for each event, for example,
the IP address of the origin of the event, the command name of the event, and the audit session ID.

Note:

Both audisp and auditdp are capable of handling both versions of
the audit trails. Therefore, you do not need to know about the internal
format of raw audit data.

• If a system crash or reboot with the reboot -n command occurs when the audit trail is being

written, the audit trail might be corrupted.
Remove the corrupted audit trail and start the audit subsystem.

23

Glossary

Audit Aware Programs

Privileged programs that invoke either the audswitch system call to suspend system call auditing
or the audwrite system call to generate self-auditing events. Audit aware programs are also
called self-auditing programs.

Audit Event

Also called an Audit Record. An event is an instance of a subject accessing an object. For
example, a process opening a file or a user logging into a system. Audit records are generated
when users make security-relevant system calls and when self-auditing processes call
audwrite(2).

Audit File

A file that stores audit records in binary format.

Audit Process Identifier (PID) Information Record (PIR)

An audit record written into the audit trail once for each process, containing information that
remains constant throughout the lifetime of the process.

Audit Tag

A unique audit session ID that uniquely identifies (or tags) all audit records generated for a
particular login session.

Audit Trail

All pieces of audit files that together store audit records in chronological order and provide a
complete information trail for displaying or analysis.

On HP-UX 11i v2, an audit trail is a single audit file. On HP-UX 11i v3, an audit trail is composed
of one or more audit files.

Base Event

A particular system operation that is audited and pre-defined by the HP-UX operating system. This
is either a self-auditing event (for example, login) or a system call (for example, open).

Event Category

A set of base events that affect a particular aspect of the system (for example, the creation of an
object, such as a file, directory, special device file, and IPC object.)

Filtering

Any one of the following types of audit filtering:

System call pre-filtering — Filtering of system call and self-audit events in the kernel based on
process (user) and event selection flags, and performed before the system call specific code
executes.

24

System call post-filtering — Filtering of system call events in the kernel based on the success or
failure of system call, and performed after the system call specific code executes.

AudFilter Product pre-filtering — Fine-grained filtering in the kernel to selectively record the audit
records that were generated and stored in the audit trail. This reduces the size of the audit trail
and enhances system call pre- and post-filtering by supporting rules-based filtering as a function of
other attributes, such as system call parameters (for example, the open(2) oflag parameter), file
owner, file system on which a file resides, and system call errno.

AudReport Product post-filtering — Fine-grained filtering in user space to selectively extract audit
records that were generated and stored in the audit trail, and to produce useful reports.

Primary Audit Trail

The current audit trail in which audit records are being written.

Profile

A set of base events defined for a particular type of system (for example, web server and file
server).

Secondary Audit Trail

The audit trail in which audit records will be written when certain capacity limits are reached for
the Primary Audit Trail.

Self-Auditing Events

An auditable event that describes a series of actions performed by a program in order to provide
a more high-level and meaningful description of an event (for example, user login event), instead
of a low system call level description provided by a series of System Call Events.

Self-Auditing Program

A privileged program that produces self-auditing events. These are not necessarily Audit Aware
Programs.

System Call Events

An auditable event that describes the invocation of a security relevant system call.

25

For more information

To read more about the HP-UX Auditing System, see the following:

• Manpages (either installed on the system or at

http://www.hp.com/go/hpux-clickable-manpages

• HP-UX System Administration Guide: Security Management at:

http://www.hp.com/go/hpux-core-docs

Click on the HP-UX version you want and scroll down to User guide.

Send comments to HP

HP welcomes your input. Please give us comments about this white paper, or suggestions for the HP­UX Security or related documentation, through our technical documentation feedback website:

http://www.hp.com/bizsupport/feedback/ww/webfeedback.html

© Copyright 2011 Hewlett-Packard Development Company, L.P. The information contained herein is subject to
change without notice. The only warranties for HP products and services are set forth in the express warranty
statements accompanying such products and services. Nothing herein should be construed as constituting an
additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Trademark acknowledgments, if needed.

5900-1628, Created July 2011

Share with colleagues