Auditing Trusted Systems

An HP-UX trusted system provides auditing, which is the selective recording of events for analysis and detection of security breaches. You need to set up auditing so it records appropriate events after your system is converted to a trusted system. The audit subsystem collects information about security-related events specified and writes this information to a series of files called an audit trail.

Effective auditing concerns events such as system call requests from user processes, logins, logoffs, and failed login attempts. These events are critical to determining who has accessed the system, at what times, from which terminal, and what actions were performed.

You must review the audit trail on a regular basis to monitor system use and detect potential penetrations of the system and misuse of system resources. In accordance with a site's security policy, you should examine patterns of access to objects (such as files) and observe the actions of subjects (for example, specific users and their processes) in an effort to detect any attempts to violate protection and privilege mechanisms.

Administering Auditing

As system administrator, you are responsible for administering auditing and performing the following tasks:

Setting up the auditing subsystem parameters
Selecting event types and other selection criteria for generating auditing information
Performing reduction and analysis of the audit trail
Maintaining online and offline audit trail data
Planning file system space consumption for audit data
Coordinating disk space requirements and user-specific audit parameters

The audit subsystem lets you collect only the audit data you want. You can preselect the type of auditing information you want to collect, based on event type, user ID, and/or group ID.

Setting Up Auditing

You must have superuser privilege to set up auditing. You can administer auditing by using the character version of SAM. Using SAM is recommended because it focuses choices and helps avoid mistakes. You can also perform all auditing tasks manually using the following audit commands:

audsys(1M): Starts or halts auditing; sets and displays audit file information.
audusr(1M): Lets you specify 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.

You can use audsys(1M) to start or halt the auditing subsystem and to specify the current and next audit files. audsys(1M) uses the audctl(2) system call to start auditing and specify the audit files to the kernel. The audsys(1M) also creates the audit files, if necessary, defines the parameters for the audit files, and maintains the names of the auditing files in the /.secure/etc/audnames file.

When you start auditing, the audomon daemon starts to monitor the audit files. Thereafter, audomon is typically spawned by /sbin/init.d/ auditing as part of the init(1M) startup process when the system is booted.

Refer to the HP-UX Reference or system man pages for more information on the auditing commands.

Turning On Auditing




	NOTE: Auditing must be turned on for normal system operation on a trusted system. If you need to turn auditing off to perform system administrative functions, bring the system into single user mode, turn auditing off, then perform the desired operations.

Follow these steps to turn on auditing on a C2-level trusted system:

Consider what events you want to audit.
Run SAM (in character mode):
sam
Highlight Auditing and Security.
Highlight Audited Events. The Audited Events screen is displayed. If you see the message:
Auditing Turned Off
make sure you turn auditing on by following these steps. If it says Auditing Turned On, you are done with this procedure.
Press Tab to move from the auditing options to the menus at the top of the screen. Use the right arrow to move to the Actions menu.
Select Turn auditing ON.

Auditing is now turned on. You must now select the events, users, and system calls you want to audit.

Selecting Events to Audit

Continue by selecting what you want to audit:

Select the event types you want to audit. You can audit selected events on success, failure, on both success and failure. Tab to the menus, select the Actions menu and choose the appropriate action:
- Audit for Success Only
- Audit for Failure Only
- Audit for Both Success and Failure
- Audit for Neither Success nor Failure
From the List menu, select Audited System Calls. Select the system calls you want to audit. You can audit selected system calls on success, failure, on both success and failure. Tab to the menus, select the Actions menu and choose the appropriate action.
From the List menu, select Audited Users. The Audited Users screen is displayed with the names of users on the system who can be audited along with system accounts such as lp, bin, and root. The screen also states the number of users currently being selected.
1. To audit all users: tab to the menus and select Action and choose Audit User(s). (To turn auditing off for all users, select Action and choose Don't Audit User(s).)
2. To audit specific users:
  1. Tab to the list of usernames.
  2. Use the arrow keys to select the user you want to audit.
  3. Tab back to the menus and select Action and choose Zoom. The user attributes are then displayed.
  4. Use the arrow keys to highlight Login Audited No and press Return. No changes to Yes.
Select Exit when you are done.

Default Auditing Parameters

The system supplies default auditing parameters when auditing is turned on. Some of the defaults are activated automatically, others 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. According to C-2 level requirements, all users must be individually accountable for their actions from login until exit.
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 2-1 “Audit Event Types and System Calls”.
An audit record is written when the event is selected for auditing and the user initiating the event is selected for auditing. The login event is an exception. Once selected, login events are recorded whether or not the person logging in is being audited.
When an event type is selected, its associated system calls are automatically enabled. Table 2-1 “Audit Event Types and System Calls” lists the system calls.
The following audit monitor and log parameters are provided with default values shown. You can change them using SAM (in character mode) or audit commands.
- Primary log file path name = /.secure/etc/audfile1
- Primary log file file switch size (AFS) = 1,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
- Warning messages sent when log reaches 90%
Choose a file system with adequate space for your audit log files. (You can assess the size of your file systems using the bdf command.) Using the system supplied defaults:
1. The ./secure/etc file system must have more than 1000KB available for the primary audit log file.
2. The file system must have more than 20% of its file space available.
3. You must provide a new path name for the auxiliary audit log file.




	NOTE: We recommend that the primary and auxiliary audit log files reside on separate file systems. You must specify the path name of a new (or empty) file for the audit log file; otherwise, the contents of the file will be deleted.

Table 2-1 Audit Event Types and System Calls

Event Type	Actions Logged	Associated System Calls
`admin`	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), pwdk(1M), init(1M)
`close`	All closing of objects (file close, other object close)	close(2)
`create`	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`	All deletions of objects (files, directories, other file objects)	rmdir(2), semctl(2), msgctl(2)
`ipcclose`	All `ipc close` events	shutdown(2)
`ipccreat`	All `ipc create` events	socket(2), bind(2)
`ipcdgram`	Ipc datagram transactions	udp(7) user datagram
`ipcopen`	All `ipc open` events	connect(2), accept(2)
`login`	All logins and logouts	login(1), init(1M)
`modaccess`	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`	All modifications of Discretionary Access Controls	su(1), chmod(2), chown(2), umask(2), fchown(2), fchmod(2), setacl(2), fsetacl(2)
`open`	All opening of objects (file open, other objects open)	open(2), execv(2), ptrace(2), execve(2), truncate(2), ftruncate(2), lpshed(1M)
`process`	All operations on processes	exit(2), fork(2), vfork(2), kill(2)
`removable`	All removable media events (mounting and unmounting)	mount(2), umount(2), vfsmount(2)
`uevent1`, `uevent2`, `uevent3`	User-defined events	See "Streamlining Audit Data" in HP-UX System Administration Tasks




	NOTE: Table 2-1 “Audit Event Types and System Calls” includes uevent3 which is not listed in Table 11-1 in HP-UX System Administration Tasks, however, uevent3 is available.

Selecting Data to Audit

You can concentrate on auditing a specific user, a group of users, or you can preselect only certain event, such as logon and logoff events, for auditing. By being selective, you can save disk space, because the number of audit records written to the collection files is reduced. Especially when performance is a concern, being selective can help reduce the impact of auditing on performance.

Note that you must choose carefully the event types that the system will audit. If, for example, you choose not to include login events in the audit trail, a penetration of the system through a dial-up line might go undetected.

The drawback to preselecting specific events to audit is that it may present an incomplete history of activities on your system. A more conservative approach is to perform full auditing. This ensures that all security- related events that occur are recorded in the audit trail. Full auditing consumes a large amount of disk space, however.

You can also postselect audited events, examining only those records that are of interest. This lets you examine the audit trail based on event types, user IDs, group IDs, object names, or whatever criteria you find useful.

Some privileged programs are given the capability to self-audit. Self- auditing programs suspend system call auditing of themselves and write their own audit records. This is done to reduce the amount of data in the audit trail and to provide high-level summary information.

Refer to "Streamlining Audit Log Data" in Chapter 12 of HP-UX System Administration Tasks for details on ways to reduce the amount of audit log data collected including a description of self-auditing programs.

Auditing Log Files

All auditing data is written to an audit log file. When you set up auditing, you define a primary log file and an optional auxiliary log file to collect auditing data.

To set audit monitor and log parameters:

Run SAM:
sam
The SAM main menu is displayed.
Highlight Auditing and Security.
Tab to the menus and select Action.
Select Set Audit Monitor and Log Parameters. The Set Audit Monitor and Log Parameters screen is displayed.
Specify the auditing information including:
1. Primary Audit Log File name and maximum size
2. Auxiliary Audit Log File name and maximum size
3. Minimum time interval for checking the log file (in minutes)
4. Percentage of allowable free space minimum
5. Percentage of log file to be filled before sending messages
Select OK.

Processes that perform a security-relevant event generate an audit record. Audit records are generated as a result of a user initiating a system call or due to a self-auditing program through a call to audwrite(2). Audit records are classified into different audit event types as shown previously in Table 2-1 “Audit Event Types and System Calls”.

As audit records are generated, they are written to the primary audit file. Audit files are located in /.secure/etc/audfile*. When auditing is enabled, at least one audit log file must be present. Setting up an auxiliary (backup) log file on another file system is recommended.

The growth of the audit files is closely monitored by the audit overflow monitor daemon, audomon, to ensure that no audit data are lost. It prints warning messages when either the audit file or the file system is getting full, and automatically switches to the auxiliary audit file if one is available. If no backup is located, audomon requests appropriate action so you can react to the conditions that could cause the system to shut down.

It is critical for security that the system administrator place the system in single user mode before modifying or extending the audit file or auxiliary audit file. This action will ensure that no users can perform actions what would not be audited while maintenance of the audit files is taking place.

Audit Record Formats

Audit records are made up of a fixed-length header and a variable-length body. The header contains the time, process ID, error, event type, and record body length.

The body contains additional information about the audited activity. For records generated by system calls, the body contains the parameters of the system calls. For records generated by self-auditing programs, the body contains a high-level description of the event. See audwrite(2). Refer to Appendix A for a detailed description of the record format of audit records.

Reducing and Analyzing the Audit File

Auditing accumulates a lot of data. SAM allows you to select which data to view. You can 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 to view successful or failed events
Which log file to view
Which tty to view
Which events or system calls to view

Viewing the Audit File

To view the audit file:

Run SAM:
sam
The SAM main menu is displayed.
Highlight Auditing and Security.
Tab to the menus and select Action.
Select View Audit Log File. The View Audit Log screen is displayed.
Select whether to display the log on the screen or put the information into a file. Select Screen or File.
Select which records to view:
1. Successful and Failed Events
2. Successful Events
3. Failed Events
Select one or more of the following information filters. You can audit all or select particular items of each type:
1. Users
2. Events
3. System calls
4. TTYs
5. Time Interval
Highlight Select to select particular items to audit.
Select OK.
Once you have specified the items to view, it may take a few minutes to prepare the report for viewing, especially if you are working with a very large audit file. Then the audit file is displayed.

Analyzing the Auditing Data

When viewing auditing data, be aware of the following:

Auditing data may be inaccurate when programs that call auditable system calls supply incorrect parameters.
System calls that take file name arguments may not have device and inode information properly recorded.
Auditing the superuser while using SAM to change event or system call parameters will result in a long auditing record.

Maintaining the Auditing Subsystem

You can use SAM to perform maintenance functions on the auditing subsystem such as:

Enabling and disabling auditing
Saving and restoring audit session files
Displaying session information for backup or reduction
Retrieve subsystem statistics




	NOTE: Auditing must be turned on for normal system operation on a trusted system. If you need to turn auditing off to perform system administrative functions, bring the system into single user mode, turn auditing off, then perform the desired operations.

See "Guidelines for Administering Auditing" in Chapter 3 for information. Refer to HP-UX Administration Tasks for additional guidelines for administering your auditing system.

Planning Sufficient Disk Space for Auditing Data




	NOTE: Auditing must be turned on for normal system operation on a trusted system. If you need to turn auditing off to perform system administrative functions, bring the system into single user mode, turn auditing off, then perform the desired operations. Auditing must be turned on for normal system operation on a trusted system. If you need to turn auditing off to perform system administrative functions, bring the system into single user mode, turn auditing off, then perform the desired operations.

The amount of disk space required for auditing depends on many factors such as system size, the amount of system activity, the number of events that you are auditing. It is of the utmost importance that you monitor the audit files and archive them daily.

The auditing subsystem warns you when disk space is low. You have the option of disabling auditing or shutting the system down when the free space of file systems is too low. For this reason, you can specify multiple directories for the audit files. If an error occurs when writing audit data to a directory or is disk space is exhausted, the subsystem and the daemon attempt to use the next directory on the list.

Maintaining Audit Across Boot

To ensure that auditing remains in effect when your system is rebooted, you must:

set boot authentication to root
ensure that your system reboots in single-user mode
make sure that auditing is on after a reboot and before you bring the system back into multi-user mode

Recovering From a System Crash

Your audit records will be preserved in the event of a system crash. If your system were to crash, it will, if possible, reboot automatically. When your system reboots it will come up in multi-user mode with auditing enabled. Auditing will continue as before the crash.

If your system cannot automatically reboot, you will have to determine and correct the problem. This may require obtaining help from Hewlett-Packard. After your system has recovered from the crash, ensure that it is returned to trusted mode with auditing enabled.

The maximum number of audit records lost during a system crash is one per process except when the file system is full and the system administrator continues to carry out operations.