 |
» |
|
|
|
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: - audsys
Starts/stops auditing; sets and displays audit file information.
See audsys(1M). - audusr
Selects users to be audited. See audusr(1M). - audevent
Changes or displays event or system call status.
See audevent(1M). - audomon
Sets the audit file monitoring and size parameters.
See audomon(1M). - audisp
Displays the audit record. See audisp(1M).
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. If auditing is currently turned off, it will be turned on
when your changes are activated. Changes to audit will be retained
as new defaults at system reboot. By default, when system auditing is
on, the audit status for all users is on. 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 on. This is the minimum event type selection
recommended for running a Trusted System. Event types are listed
in Table 8-3 “Audit Event Types and System Calls” and Table 8-4 “Audit Event Types and System Commands”. A 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 8-3 “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) = 1000 KB Auxiliary log file path name = /.secure/etc/audfile2 Auxiliary log file switch size (AFS) = 1000 KB 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: The /.secure/etc file system must have more than 5000 KB available for
the primary audit log file, and 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.
Table 8-3 Audit Event Types and System Calls Event Type | Description of Action | Associated System Calls |
|---|
admin | Log all administrative and privileged
events | acct(2), adjtime(2), audctl(2), audswitch(2), clock_settime(2), getksym(2), getprivgrp(2), kload(2)[1], modadm(2)[1], modload(2), modpath(2), modstat(2), moduload(2), mpctl(2), plock(2), reboot(2), sched_setparam(2), sched_setscheduler(2), serialize(2), setaudid(2), setaudproc(2), setdomainname(2), setevent(2), sethostid(2), setprivgrp(2), setrlimit(2), setrlimit64(2), settimeofday(2), spuctl(2)[1], stime(2),
swapon(2), toolbox(2)[1], utssys(2)[1] | close | Log all closings of objects (file close,
other objects close) | close(2), ksem_close(2)[1], mq_close(2), munmap(2) | create | Log all creations of objects (files,
directories, other file objects) | creat(2), mkdir(2), mknod(2), msgget(2), pipe(2), semget(2), shmat(2), shmget(2), symlink(2) | delete | Log all deletions of objects (files,
directories, other file objects) | ksem_unlink(2)[1], mq_unlink(2), msgctl(2), rmdir(2), semctl(2), shm_unlink(2) | ipcclose | Log all ipc close events | fdetach(3C), shutdown(2) | ipccreat | Log all ipc create events | bind(2), socket(2), socket2(2)[1], socketpair(2), socketpair2(2)[1] | ipcopen | Log all ipc open events | accept(2), connect(2), fattach(3C) | modaccess | Log all access modifications other than
Discretionary Access Controls | chdir(2), chroot(2), fchdir(2), link(2), lockf(2), lockf64(2), rename(2), setcontext(2), setgid(2), setgroups(2), setpgid(2), setpgrp(2), setpgrp2(2), setpgrp3(2), setregid(2), setresgid(2), setresuid(2), setsid(2), setuid(2), shmctl(2), shmdt(2), ulimit(2), ulimit64(2), unlink(2) | moddac | Log all modifications of object’s Discretionary
Access Controls | acl(2), chmod(2), chown(2), fchmod(2), fchown(2), fsetacl(2), lchmod(2)[1], lchown(2),
putpmsg(2), semop(2), setacl(2), umask(2) | open | Log all openings of objects (file open,
other objects open) | execv(2), execve(2), ftruncate(2), ksem_open(2)[1], mmap(2),
mmap64(2), mq_open(2), open(2), ptrace(2), ptrace64(2), sendfile(2), sendfile64(2), shm_open(2), truncate(2), truncate64(2) | process | Log all operations on processes | exit(2), fork(2), kill(2), mlock(2), mlockall(2), munlock(2), munlockall(2), nsp_init(2)[1], rtprio(2),
setpriority(2), sigqueue(2), vfork(2) | | readac | Log all access to object’s Discretionary
Access Controls | access(2), fstat(2), fstat64(2), getaccess, lstat(2), lstat64(2), stat(2), stat64(2) | removable | Log all removable media events (mounting
and unmounting events) | mount(2), umount(2), vfsmount(2) | | Log user-defined events | See “Streamlining Audit Log Data” |
Table 8-4 Audit Event Types and System Commands Event Type | Description of Action | Associated System Commands |
|---|
admin | Log all administrative and privileged
events | sam(1M), audisp(1M), audevent(1M), audsys(1M), audusr(1M), chfn(1), chsh(1), passwd(1), pwck(1M), init(1M) | ipcdgram | Log ipc datagram transactions | udp(7P) | login | Log all logins and logouts | login(1), init(1M) | modaccess | Log all access modifications other than
Discretionary Access Controls | newgrp(1) | open | Log all openings of objects (file open,
other objects open) | lpsched(1M) | removable | Log all removable media events (mounting
and unmounting events) | exportfs(1M) | | 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: Self-auditing processesSelf-Auditing
Programs | |
Self-auditing
programs are useful for streamlining the audit data collected. Therefore,
the event types UEVENT1, UEVENT2,
and UEVENT3 are reserved for self-auditing
programs you may want to write. You
can write your own setuid-to-root 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. See audswitch(2) and audwrite(2) for more information. Audit Log Files | |
All auditing data is written to an audit log file. With the audsys command, you can specify a primary log file and
an (optional) auxiliary log file to collect
auditing data (see audsys(1M)). 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, minfree, 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 terminal device 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 appear inaccurate when
programs that call auditable system calls supply incorrect parameters.
For example, calling the kill() system call with no parameters (i.e., kill()) produces unpredictable values in the parameter section
of the audit record. The audit data shows what the user program passed to the kernel.
In this case, what got passed is not initialized due to a user code
error, but the audit system still correctly displays the uninitialized
values that were used. 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 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 that you use 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 off-line 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 the overflow of the audit file by archiving
daily. Revise current selectable events periodically, especially
after installing new releases of HP-UX, since new system calls are
often introduced in new releases. 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. |
Printable version
