|
|
Managing the Auditing Subsystem
Tasks Performed by the Audit Server
The operating system creates the audit server as a detachedprocess during system startup to perform the following tasks:
The audit server sends informational and error messages tothe operator communication manager (OPCOM). OPCOM broadcasts thesemessages to operator terminals and writes the messages to the operatorlog file.
Default Characteristics of the Audit Server displaysthe audit server's initial operating values. These settings arestored in the audit server database, VMS$AUDIT_SERVER.DAT in SYS$COMMON:[SYSMGR].Any time you modify security-auditing characteristics by using theDCL command SET AUDIT, the audit server database is updated. Eachtime the system is rebooted, it takes the auditing values from thisdatabase.
Disabling and Reenabling Startup of the AuditServer
All operating systemsstart the audit server process and OPCOM by default.
If the physical memory or disk storage space on your systemis especially limited and logging of security-related events isnot important, you can remove the audit server and OPCOM processesfrom the system startup procedure. Before you do so, be aware thatcluster object support requires the audit server (see Securing a Cluster). The following example showshow you would remove these processes with the System Managementutility (SYSMAN):
To delete the audit server process and shut down securityauditing on the system, enter the following commands on each nodein the cluster:$
SET PROCESS/PRIVILEGES=(OPER,BYPASS)
$
RUN SYS$SYSTEM:SYSMAN
SYSMAN>
STARTUP SET DATABASE STARTUP$STARTUP_VMS
SYSMAN>
STARTUP DISABLE FILE VMS$CONFIG-050_OPCOM.COM/NODE=*
SYSMAN>
STARTUP DISABLE FILE VMS$CONFIG-050_AUDIT_SERVER.COM /NODE=*
SYSMAN>
EXIT
$
SET PROCESS/PRIVILEGES=(NOOPER,NOBYPASS)
You can restart security auditing and OPCOM on the systemby executing the following DCL command lines:$
SET AUDIT/ALARM/AUDIT/DISABLE=ALL/CLASS=*
$
SET AUDIT/SERVER=EXIT
To start the OPCOM and the audit server processes for allsubsequent system boots, reverse your previous edits of the systemstartup procedure. Use the following SYSMAN commands:$
@SYS$SYSTEM:STARTUP OPCOM
$
@SYS$SYSTEM:STARTUP AUDIT_SERVER
See the HP OpenVMS System Management UtilitiesReference Manual for more information about SYSMAN.$
SET PROCESS/PRIVILEGES=(OPER,BYPASS)
$
RUN SYS$SYSTEM:SYSMAN
SYSMAN>
STARTUP SET DATABASE STARTUP$STARTUP_VMS
SYSMAN>
STARTUP ENABLE FILE VMS$CONFIG-050_OPCOM.COM/NODE=*
SYSMAN>
STARTUP ENABLE FILE VMS$CONFIG-050_AUDIT_SERVER.COM -
_SYSMAN>
/NODE=*
SYSMAN>
EXIT
$
SET PROCESS/PRIVILEGES=(NOOPER,NOBYPASS)
Changing the Point in Startup When the OperatingSystem Initiates Auditing
Ordinarily, the operating system starts sending audit-eventmessages just before SYSTARTUP_VMS.COM executes. However, a sitethat is not interested in receiving audit-event messages duringstartup can alter this behavior by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.
To change the point where the operating system begins to deliversecurity event messages, add the following line to the SYS$MANAGER:SYLOGICALS.COMcommand procedure:
$ !$ DEFINE /SYSTEM /EXECUTIVE SYS$AUDIT_SERVER_INHIBIT yes$ !A system manager can choose another phase of system startupto initiate auditing, perhaps at the end of SYSTARTUP_VMS. However,be sure to initiate auditing before allowing any general loginsto the system (that is, before any SET LOGINS/INTERACTIVE command).To initiate delivery of auditing messages, add the following lineto the appropriate command file:
$ !$ SET AUDIT/SERVER=INITIATE$ !
Choosing the Number of Outstanding MessagesThat Trigger Process Suspension
Unless the audit server controls the influx of messages, itis possible under some conditions to run out of memory. A very slowI/O device, a disk space problem, or even a sudden onslaught ofmessages can exceed the server's ability to write messages to disk.To prevent memory exhaustion, the audit server constantly monitorsthe total number of outstanding messages and tallies the numberof messages contributed by each active process. If the server receivesmore events than it can log to disk, it begins applying flow controlto those processes generating audit events.
Controlling Message Flow
Message volume is controlled on a per-process basis. Controlling the Flow of Audit Event Messages shows the three stages offlow control.
Control Stages | Total Message Backlog (Default) | Process Backlog Limit (Default) |
---|---|---|
1 | 100 | 5 |
2 | 200 | 2 |
3 | 300 | None |
You can establish site-specific values for controlling messagesby using the /BACKLOG qualifier to the SET AUDIT command. For example,the following command raises the action thresholds so that the operating systemstarts controlling the influx of messages when it has 125 unprocessedmessages in its queue and a contributing process has eight messagesoutstanding:
$
SET AUDIT/BACKLOG=(TOTAL=(125,250,350),PROCESS=(8,4) )
Preventing Process Suspension
Naturally, the operating system never suspends certain criticalprocesses. Realtime processes and any of the following processesare exempt:
CACHE_SERVER | CLUSTER_SERVER |
CONFIGURE | DFS$COM_ACP |
DNS$ADVER | IPCACP |
JOB_CONTROL | NETACP |
NET$ACP | OPCOM |
REMACP | SHADOW_SERVER |
SMISERVER | SWAPPER |
TP_SERVER | VWS$DISPLAYMGR |
VWS$EMULATORS |
You can prevent the suspension of a process by adding itsprocess identifier (PID) to the process exclusion list. Use thefollowing form of the SET AUDIT command: SET AUDIT/EXCLUDE=process-id
Be aware that processes (PIDs) are not automatically removedfrom 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.
Reacting to Insufficient Memory
When processes on the exclusion list (see Preventing Process Suspension) produce so many audit messages thatthe audit server runs out of memory, the default behavior of theaudit server is to remove old event messages until memory is available.It saves the most current messages.
The audit server has other alternatives when it encountersmemory limitations:
Option | Description |
---|---|
Crash | Crash the system if theaudit server runs out of memory. |
Ignore_New | Ignore new event messagesuntil memory is available. New event messages are lost but eventmessages in memory are saved. |
Purge_Old (default) | Remove old event messages until memoryis available for the most current messages. |
To alter the default behavior of the audit server and instructit to ignore all new audit messages rather than purge the old ones,enter the following command:
The audit server runs with a fixed virtual memory limit (PGFLQUOTA)of 20,480 pages. This may be further limited by the size of pagefiles installed on the system. You can adjust the size of page filesby running AUTOGEN. Whenever it detects a page file problem, AUTOGENautomatically resets the size to alleviate the problem.$
SET AUDIT/SERVER=FINAL_ACTION=IGNORE_NEW
Maintaining the Accuracy of Message Time-Stamping
If you are auditing a set of security events in which theorder of occurrence is important, all clocks within a cluster needto remain synchronized. This ensures that message time-stampingon all nodes in the cluster closely reflects the order in whichevents occurred.
Because each node in a cluster configuration maintains timeindependently, it is possible for cluster times to drift apart overtime. To prevent drifting, use the SYSMAN command CONFIGURATIONSET TIME at regular intervals. The HP OpenVMS SystemManagement Utilities Reference Manual provides a sample commandprocedure that you can run every hour to maintain clock synchronizationto within a second.
Adjusting the Transfer of Messages to Disk
The audit server stores security event messages in memoryand periodically transfers groups of messages from its buffers tothe audit log file on disk. Usually, the audit server transfersauditing messages every 5 minutes and archived messages (see Using a Remote Log File) every minute. Exceptfor some high-security environments and instances where extremenumbers of audit messages are being generated on the system, thisdefault should be sufficient.
High-security sites can transfer event messages to disk athigher than normal rates by modifying the interval of log transferoperations. The following command, for example, changes the auditserver's characteristics so it writes event messages to the auditlog file every 2 minutes:
Frequent message transfers can impact system performance,however, because the system performs more I/O operations ratherthan store messages in the system buffers associated with the auditserver process.$
SET AUDIT/INTERVAL=JOURNAL_FLUSH=00:02
To immediately force all audit messages to the log file, enterthe following command:
$
SET AUDIT/SERVER=FLUSH
Allocating Disk Space for the Audit Log File
Theaudit server constantly monitors the disk space allocated to thesecurity audit log file to ensure there is adequate space for eventmessages. Whenever the file runs low on available blocks, the auditserver extends the audit log file. If disk resource limitationsprevent the server from allocating more blocks to the log file,it takes one of the following actions:
$
SET AUDIT /JOURNAL=SECURITY /THRESHOLD=WARNING=150
$
SET AUDIT /JOURNAL=SECURITY /THRESHOLD=ACTION=50
The threshold values may be expressed in blocks or as a deltatime. Delta time values are multiplied by the average space consumptionrate to yield a number of blocks. The maximum of the block and timethreshold values is used as the active threshold value.
Error Handling in the Auditing Facility
Resources consumedby the OpenVMS security-auditing facility vary with the number andtype of system events being recorded. Three different error conditionscan develop related to the auditing facility:
This section discusses the default behavior of the auditingsystem in monitoring disk space and logging to an archive file.
Disabling Disk Monitoring
Theaudit server monitors the audit log file and regularly pre-extendsits disk block allocation to ensure there is adequate space forincoming event messages. Whenever disk space is unavailable, theserver first warns you through operator messages and then resortsto suspending certain contributing processes (see Allocating Disk Space for the Audit Log File ). If you find many processessuspended for no apparent reason, it is probably because your auditdisk is full. Once you correct the disk space problem, you can resume suspendedprocesses with the SET AUDIT/SERVER=RESUME command (rather thanwait for the next resource scan).
You can disable resource monitoring altogether by enteringthe following command:
However, if you disable disk resource monitoring, you eliminatethe opportunity to receive warning messages until it is too late.The audit server begins to suspend processes that are generatingtoo 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 describedin Reacting to Insufficient Memory: it ignores messages, purgesold messages, or, possibly, crashes the system.$
SET AUDIT/JOURNAL=SECURITY/RESOURCE=DISABLE
Once disk space becomes available, the audit server extendsthe log file and resumes any processes it suspended.
Losingthe Link to a Remote Log File
If you are writing auditing messagesto a remote log file, as described in Using a Remote Log File, the link between the local and remote node canfail. Should this happen, the audit server broadcasts a warning messageto all operator terminals and attempts to reestablish the link everyminute until the connection is made.
|
|