skip book previous and next navigation links
go up to top of book: HP OpenVMS Guide to System SecurityHP OpenVMS Guide to System Security
go to beginning of part: Security for the System AdministratorSecurity for the System Administrator
go to beginning of chapter: Security AuditingSecurity Auditing
go to previous page: Analyzing a Log FileAnalyzing a Log File
go to next page: System Security BreachesSystem Security Breaches
end of book navigation links

Managing the Auditing Subsystem  



This section discusses how to manage the auditing system.Management tasks include the following:

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.
Example 9  Default Characteristics of the Audit Server  
$ SHOW AUDIT/ALL
List of audit journals:  Journal name:           SECURITY  Journal owner:          (system audit journal)  Destination:            SYS$COMMON:[SYSMGR]SECURITY.AUDIT$JOURNAL  Monitoring:             enabled    Warning thresholds,   Block count:    100   Duration:  2 00:00:00.0    Action thresholds,    Block count:     25   Duration:  0 00:30:00.0 Security auditing server characteristics:  Database version:       4.4  Backlog (total):        100, 200, 300  Backlog (process):      5, 2  Server processing intervals:    Archive flush:        0 00:01:00.00    Journal flush:        0 00:05:00.00    Resource scan:        0 00:05:00.00  Final resource action:  purge oldest audit events Security archiving information:  Archiving events:       none  Archive destination: System security alarms currently enabled for:  ACL  Authorization  Breakin:     dialup,local,remote,network,detached  Logfailure:  batch,dialup,local,remote,network,subprocess,detached,server System security audits currently enabled for:  ACL  Authorization  Breakin:     dialup,local,remote,network,detached  Logfailure:  batch,dialup,local,remote,network,subprocess,detached,server


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):

$ SET PROCESS/PRIVILEGES=(OPER,BYPASS)$ RUN SYS$SYSTEM:SYSMANSYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMSSYSMAN> 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)
To delete the audit server process and shut down securityauditing on the system, enter the following commands on each nodein the cluster:
$ SET AUDIT/ALARM/AUDIT/DISABLE=ALL/CLASS=*$ SET AUDIT/SERVER=EXIT
You can restart security auditing and OPCOM on the systemby executing the following DCL command lines:
$ @SYS$SYSTEM:STARTUP OPCOM$ @SYS$SYSTEM:STARTUP AUDIT_SERVER
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:
$ SET PROCESS/PRIVILEGES=(OPER,BYPASS)$ RUN SYS$SYSTEM:SYSMANSYSMAN> STARTUP SET DATABASE STARTUP$STARTUP_VMSSYSMAN> 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)
See the HP OpenVMS System Management UtilitiesReference Manual for more information about SYSMAN.

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.

Table 7   Controlling the Flow of Audit Event Messages
Control Stages Total Message Backlog (Default) Process Backlog Limit (Default)
1
100
5
2
200
2
3
300
None

  1. When there are100 messages in memory, the operating system suspends any processthat has five or more outstanding messages. Once a process has allits messages written to the log file, it can resume processing.
  2. When there are 200 messages in memory, the operatingsystem suspends any process that has submitted two or more messagesuntil all messages are written to disk.
  3. When there are 300 messages in memory, any processwith messages in memory is suspended until all messages are writtento disk.

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:

$ SET AUDIT/SERVER=FINAL_ACTION=IGNORE_NEW
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.

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:

$ SET AUDIT/INTERVAL=JOURNAL_FLUSH=00:02
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.

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:

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:

$ SET AUDIT/JOURNAL=SECURITY/RESOURCE=DISABLE
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.

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.


go to previous page: Analyzing a Log FileAnalyzing a Log File
go to next page: System Security BreachesSystem Security Breaches