HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 10 Security Auditing
The audit server sends informational and error messages to the operator communication manager (OPCOM). OPCOM broadcasts these messages to operator terminals and writes the messages to the operator log file.
“Default Characteristics of the Audit Server” displays the audit server's initial operating values. These settings are stored in the audit server database, VMS$AUDIT_SERVER.DAT in SYS$COMMON:[SYSMGR]. Any time you modify security-auditing characteristics by using the DCL command SET AUDIT, the audit server database is updated. Each time the system is rebooted, it takes the auditing values from this database.
Example 10-9 Default Characteristics of the Audit Server
If the physical memory or disk storage space on your system is especially limited and logging of security-related events is not important, you can remove the audit server and OPCOM processes from the system startup procedure. Before you do so, be aware that cluster object support requires the audit server (see “Securing a Cluster”). The following example shows how you would remove these processes with the System Management utility (SYSMAN):
Ordinarily, the operating system starts sending audit-event messages just before SYSTARTUP_VMS.COM executes. However, a site that is not interested in receiving audit-event messages during startup can alter this behavior by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.
A system manager can choose another phase of system startup to initiate auditing, perhaps at the end of SYSTARTUP_VMS. However, be sure to initiate auditing before allowing any general logins to the system (that is, before any SET LOGINS/INTERACTIVE command). To initiate delivery of auditing messages, add the following line to the appropriate command file:
Unless the audit server controls the influx of messages, it is possible under some conditions to run out of memory. A very slow I/O device, a disk space problem, or even a sudden onslaught of messages can exceed the server's ability to write messages to disk. To prevent memory exhaustion, the audit server constantly monitors the total number of outstanding messages and tallies the number of messages contributed by each active process. If the server receives more events than it can log to disk, it begins applying flow control to those processes generating audit events.
Message volume is controlled on a per-process basis. “Controlling the Flow of Audit Event Messages” shows the three stages of flow control.
You can establish site-specific values for controlling messages by using the /BACKLOG qualifier to the SET AUDIT command. For example, the following command raises the action thresholds so that the operating system starts controlling the influx of messages when it has 125 unprocessed messages in its queue and a contributing process has eight messages outstanding:
Be aware that processes (PIDs) are not automatically removed from the process exclusion list when processes log out of the system. To remove a process from the exclusion list, use the SET AUDIT/NOEXCLUDE command. Processes excluded by the operating system cannot be removed.
When processes on the exclusion list (see “Preventing Process Suspension”) produce so many audit messages that the audit server runs out of memory, the default behavior of the audit server is to remove old event messages until memory is available. It saves the most current messages.
The audit server runs with a fixed virtual memory limit (PGFLQUOTA) of 20,480 pages. This may be further limited by the size of page files installed on the system. You can adjust the size of page files by running AUTOGEN. Whenever it detects a page file problem, AUTOGEN automatically resets the size to alleviate the problem.
If you are auditing a set of security events in which the order of occurrence is important, all clocks within a cluster need to remain synchronized. This ensures that message time-stamping on all nodes in the cluster closely reflects the order in which events occurred.
Because each node in a cluster configuration maintains time independently, it is possible for cluster times to drift apart over time. To prevent drifting, use the SYSMAN command CONFIGURATION SET TIME at regular intervals. The HP OpenVMS System Management Utilities Reference Manual provides a sample command procedure that you can run every hour to maintain clock synchronization to within a second.
The audit server stores security event messages in memory and periodically transfers groups of messages from its buffers to the audit log file on disk. Usually, the audit server transfers auditing messages every 5 minutes and archived messages (see “Using a Remote Log File”) every minute. Except for some high-security environments and instances where extreme numbers of audit messages are being generated on the system, this default should be sufficient.
High-security sites can transfer event messages to disk at higher than normal rates by modifying the interval of log transfer operations. The following command, for example, changes the audit server's characteristics so it writes event messages to the audit log file every 2 minutes:
Frequent message transfers can impact system performance, however, because the system performs more I/O operations rather than store messages in the system buffers associated with the audit server process.
The audit server constantly monitors the disk space allocated to the security audit log file to ensure there is adequate space for event messages. Whenever the file runs low on available blocks, the audit server extends the audit log file. If disk resource limitations prevent the server from allocating more blocks to the log file, it takes one of the following actions:
The threshold values may be expressed in blocks or as a delta time. Delta time values are multiplied by the average space consumption rate to yield a number of blocks. The maximum of the block and time threshold values is used as the active threshold value.
Resources consumed by the OpenVMS security-auditing facility vary with the number and type of system events being recorded. Three different error conditions can develop related to the auditing facility:
The audit server monitors the audit log file and regularly pre-extends its disk block allocation to ensure there is adequate space for incoming event messages. Whenever disk space is unavailable, the server first warns you through operator messages and then resorts to suspending certain contributing processes (see “Allocating Disk Space for the Audit Log File” ). If you find many processes suspended for no apparent reason, it is probably because your audit disk is full. Once you correct the disk space problem, you can resume suspended processes with the SET AUDIT/SERVER=RESUME command (rather than wait for the next resource scan).
However, if you disable disk resource monitoring, you eliminate the opportunity to receive warning messages until it is too late. The audit server begins to suspend processes that are generating too many audits, as “Choosing the Number of Outstanding Messages That Trigger Process Suspension” describes, and if it runs out of memory, the server takes the action described in “Reacting to Insufficient Memory”: it ignores messages, purges old messages, or, possibly, crashes the system.
If you are writing auditing messages to a remote log file, as described in “Using a Remote Log File”, the link between the local and remote node can fail. Should this happen, the audit server broadcasts a warning message to all operator terminals and attempts to reestablish the link every minute until the connection is made.