Auditing

An HP-UX trusted system provides auditing. Auditing is the selective recording of events for analysis and detection of security breaches.

Using SAM to perform all auditing tasks is recommended as it focuses choices and helps avoid mistakes. However, all auditing tasks can be done manually using the following audit commands:

Title not available (Auditing )

audsys(1M): Starts/halts auditing; sets and displays audit file information
audusr(1M): Selects users to be audited
audevent(1M): Changes or displays event or system call status
audomon(1M): Sets the audit file monitoring and size parameters
audisp(1M): Displays the audit record

The HP-UX Reference provides more details on these commands.

The system supplies default auditing parameters at installation. Some of these defaults are activated automatically, some have to be enabled.

By default, the audit status for all users is set to y. New users added to the system are automatically audited. You must explicitly turn audit off for these users, if desired. Changes take effect at the user's next login.
The event types admin, login, and moddac are selected as defaults by the system. Both Audit Success and Audit Failure are set to y. This is the minimum event type selection recommended for running a trusted system. Event types are listed in Table 12-1 “Audit Event Types and System Calls ”.
An audit record is written when the event type is selected for auditing, and the user initiating the event has been selected for auditing. The login event is an exception. Once selected, this event will be recorded whether or not the user logging in has been selected for auditing.
When an event type is selected, its associated system calls are automatically enabled. Table 12-1 “Audit Event Types and System Calls ” lists these system calls.
The following audit monitor and log parameters are provided with default values shown. They may be changed using SAM or audit commands.
- Primary log file path name = /.secure/etc/audfile1
- Primary log file switch size (AFS) = 5,000KB
- Auxiliary log file path name = /.secure/etc/audfile2
- Auxiliary log file switch size (AFS) = 1,000KB
- Monitor wake up interval = 1 minute
- Allowable free space minimum (FSS) = 20% (of file system)
- Start sending warning messages when log reaches = 90%
You can assess the size of your file systems using the bdf command. Choose a file system with adequate space for your audit log files. For example, using the system supplied defaults:
1. The /.secure/etc file system must have more than 5000KB available for the primary audit log file, and
2. It must have more than 20% of its file space available.
You should provide a new path name for the auxiliary audit log file. We recommend that the primary and auxiliary audit log files reside on separate file systems. When specifying a new path name for an audit log file, that file must be empty or nonexistent; otherwise the file content will be deleted.

If auditing is currently turned off, it will be turned on when activating your changes. Changes to audit will be retained as new defaults at system reboot.

Table 12-1 Audit Event Types and System Calls

Event Type	Description of Action	Associated System Calls
`admin`	Log all administrative and privileged events	stime(2), swapon(2), settimeofday(2), sethostid(2), privgrp(2), setevent(2), setaudproc(2), audswitch(2), setaudid(2), setdomainname(2), reboot(2), sam(1M), audisp(1M), audevent(1M), audsys(1M), audusr(1M), chfn(1), chsh(1), passwd(1), pwck(1M), init(1M)
`close`	Log all closings of objects (file close, other objects close)	close(2)
`create`	Log all creations of objects (files, directories, other file objects)	creat(2), mknod(2), mkdir(2), semget(2), msgget(2), shmget(2), shmat(2), pipe(2)
`delete`	Log all deletions of objects (files, directories, other file objects)	rmdir(2), semctl(2), msgctl(2)
`ipcclose`	Log all `ipc close` events	shutdown(2)
`ipccreat`	Log all `ipc create` events	socket(2), bind(2)
`ipcdgram`	Log ipc datagram transactions	udp(7) user datagram
`ipcopen`	Log all `ipc open` events	connect(2), accept(2)
`login`	Log all logins and logouts	login(1), init(1M)
`modaccess`	Log all access modifications other than Discretionary Access Controls	link(2), unlink(2), chdir(2), setuid(2), setgid(2), chroot(2), setgroups(2), setresuid(2), setresgid(2), rename(2), shmctl(2), shmdt(2), newgrp(1)
`moddac`	Log all modifications of object's Discretionary Access Controls	chmod(2), chown(2), umask(2), fchown(2), fchmod(2), setacl(2), fsetacl(2)
`open`	Log all openings of objects (file open, other objects open)	open(2), execv(2), ptrace(2), execve(2), truncate(2), ftruncate(2), lpsched(1M)
`process`	Log all operations on processes	exit(2), fork(2), vfork(2), kill(2)
`removable`	Log all removable media events (mounting and unmounting events)	smount(2), umount(2), vfsmount(2)
`uevent1`, `uevent2`	Log user-defined events	See "Streamlining Audit Log Data"

Streamlining Audit Log Data

Some processes invoke a series of auditable actions. To reduce the amount of audit log data collected and to provide for more meaningful notations in the audit log files, some of these processes are programmed to suspend auditing of the actions they invoke and produce one audit log entry describing the process that occurred. Processes programmed in this way are called self-auditing programs; for example, the login program. The following processes have self-auditing capabilities:

Title not available (Streamlining Audit Log Data )

chfn(1): Change finger entry
chsh(1): Change login shell
login(1): The login utility
newgrp(1): Change effective group
passwd(1): Change password
audevent(1M): Select events to be audited
audisp(1M): Display the audit data
audsys(1M): Start or halt the auditing system
audusr(1M): Select users to be audited
init(1M): Change run levels, users logging off.
lpsched(1M): Schedule line printer requests
pwck(1M): Password/group file checker

Self-auditing programs are useful for streamlining the audit data collected. Therefore, two event types, UEVENT1 and UEVENT2, are reserved for self-auditing programs you may want to write.

Users with superuser permission may wish to write their own programs to streamline auditing data with the audswitch and audwrite system calls. You can suspend auditing (audswitch(AUD_SUSPEND)), choose key points in the program to generate an auditing record (audwrite), and then resume regular auditing (audswitch(AUD_RESUME)).

If the auditing system is turned off at the time your program is run, audwrite returns successfully, but no auditing record is written. Refer to audwrite(2) for more information.

Audit Log Files

All auditing data is written to an audit log file. You can specify a primary log file and an (optional) auxiliary log file to collect auditing data. The growth of these files is closely monitored by the audit overflow monitor daemon, audomon, to insure that no audit data is lost.

The primary log file is where audit records begin to be collected. When this file approaches a predefined capacity (its Audit File Switch (AFS) size), or when the file system on which it resides approaches a predefined capacity (its File Space Switch (FSS) size), the auditing subsystem issues a warning. When either the AFS or the FSS of the primary log file is reached, the auditing subsystem attempts to switch to the auxiliary log file for recording audit data. If no auxiliary log file is specified, the primary log file continues to grow.

If other activities consume space on the file system, or the file system chosen has insufficient space for the AFS size chosen, the File Space Switch point could be reached before the Audit File Switch point.

If the primary audit log continues to grow past the FSS point, a system defined parameter, min_free, could be reached. All auditable actions are suspended for regular users at this point. Restore the system to operation by archiving the audit data, or specifying a new audit log file on a file system with space.

Viewing Audit Logs

Auditing accumulates a lot of data. SAM gives you the opportunity to select the data you want to view. You may select the following items:

Whether the log output is directed to the screen or to a file.
The name of the file to which log output is to be directed.
Whether you wish to view successful and/or failed events.
Which log file you wish to read.
Which user login you wish to view.
Which tty you wish to view.
Which events or system calls you wish to view.

It may take a few minutes to prepare the record for viewing when working with large audit logs. When viewing your audit data be aware of the following anomalies:

Audit data may be inaccurate when programs that call auditable system calls supply incorrect parameters. For example, calling the kill(2) system call with no parameters (i.e. kill()) produces unpredictable values in the parameter section of the audit record.
System calls that take file name arguments may not have device and inode information properly recorded. The values will be zero if the call does not complete successfully.
Auditing of the superuser while using the SAM interface to change event or system call parameters will result in a long audit record. For example, when you add an event type to be audited in SAM, a record will be produced for each event type and system call that has been enabled for audit, not just for the new event type being added.

Guidelines for Administering Your Auditing System

We recommend using the following guidelines when administering your system:

Check the audit logs once a day at a minimum. An online audit file should be retained for at least 24 hours and all audit records stored offline should be retained for a minimum of 30 days.
Review the audit log for unusual activities, such as: late hours login, login failures, failed access to system files, and failed attempts to perform security-relevant tasks.
Prevent overflow of audit file by archiving daily.
Revise current selectable events periodically.
Revise audited users periodically.
Do not follow any pattern or schedule for event or user selection.
Set site guidelines. Involve users and management in determining these guidelines.

Performance Considerations

Auditing increases system overhead. When performance is a concern, be selective about what events and users are audited. This can help reduce the impact of auditing on performance.

Using Auditing in an NFS Diskless Environment

Auditing can only be done on trusted systems. Each diskless client has its own audit file. Each system on the cluster must administer its own auditing, including making sure the file system where the audit files are to reside is mounted. The audit record files are stored in the /.secure directory.