Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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.
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.
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 files permissions)
Whether the event succeeded or failed. If it failed, the reason for the failure.
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 daemons 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
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=
User= name shell=
failed)
User= name shell=
User= name shell=
/etc/passwd)
User= name shell=
User= name shell=
dtlogin(1)
User=name uid= user
users on the system
User=name uid= user
flag
User=name uid= user
User=name uid= user
User=name uid= user
User=name uid= user
directory
User=name uid= user
directory
User=name uid= user
User=name uid= user
audid=
audid=
audid=
audid=
audit
audit
audit
audit
id
id
id
id
attempted to login
attempted to login
attempted to login
Successful login -
- bad audit id
- bad group id
- bad user id
no home
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;
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;
10
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 telnetds 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 = username|
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. |
12
User=login_user (login)
logoff event SID session_id PGRP process_group PPID parent_pid PID pid
program (login) Generated only when AudReport product is not installed
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.
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).
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.
14
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
Number of log files in an audit trail
16
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-toauthorization 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
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
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. This section
contains best practices to provide guidance for making decisions as part of the planning stage.
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.
20
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.
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.
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.
22
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.
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.
24
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
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 HPUX 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