HP OpenVMS Systems Documentation

Ordinarily, the system turns on auditing in VMS$LPBEGIN just before SYSTARTUP_VMS.COM executes. You can change this behavior, however, by redefining the logical name SYS$AUDIT_SERVER_INHIBIT.

To change the point at which the operating system begins to deliver security-event messages, add the following line to the SYS$MANAGER:SYLOGICALS.COM command procedure:

$ DEFINE/SYSTEM/EXECUTIVE SYS$AUDIT_SERVER_INHIBIT YES

You can initiate auditing during another phase of system startup, perhaps at the end of SYSTARTUP_VMS.COM, by editing the command file to add the following line:

$ SET AUDIT/SERVER=INITIATE

For information about editing SYSTARTUP_VMS.COM, see Section 5.2.7.

20.7.4 Enabling Security Auditing for Additional Classes

To enable security auditing for classes in addition to those shown in Table 20-7, use the following format:

The OpenVMS Guide to System Security contains descriptions of event classes that you can enable.

When you enable auditing for additional event classes, you must specify two qualifiers:

1. /ENABLE
2. Either /ALARM or /AUDIT (Although you must specify one qualifier, you can specify both.)

The following table contains explanations of the /ENABLE, /ALARM, and /AUDIT qualifiers.

The system begins auditing new events on all nodes as soon as you enable them.

Examples

1. The command in the following example enables auditing for volume mounts and dismounts and sends messages to the security audit log file.

   $ SET AUDIT/ENABLE=MOUNT/AUDIT

2. The command in the following example enables auditing of unsuccessful file accesses and sends messages to all enabled security operator terminals as well as to the security audit log file.

   $ SET AUDIT/ALARM/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE

The system continues auditing until you explicitly disable the classes with the /DISABLE qualifier using the following syntax:

20.7.6 Enabling a Terminal to Receive Alarm Messages

The system sends alarm messages to terminals enabled for security class messages. Security alarm messages are not written to the operator log file. They appear only on terminals enabled for security class messages.

In most cases, security alarm messages appear on the system console by default. Since messages scroll quickly off the screen, it is good practice to enable a separate terminal for security class messages and disable message delivery to the system console.

Either choose a terminal in a secure location that provides hardcopy output, or have dedicated staff to monitor the security operator terminal. You can enable any number of terminals as security operators.

To set up a terminal to receive security class alarms, enter the following DCL command from the designated terminal:

$ REPLY/ENABLE=SECURITY

Example

The following example shows a security alarm message:

%%%%%%%%%%%  OPCOM  25-MAY-2000 16:07:09.20  %%%%%%%%%%%
Message from user AUDIT$SERVER on GILMORE
Security alarm (SECURITY) on GILMORE, system id: 20300
Auditable event:          Process suspended ($SUSPND)
Event time:               25-MAY-2000 16:07:08.77
PID:                      30C00119
Process name:             Hobbit
Username:                 HUBERT
Process owner:            [LEGAL,HUBERT]
Terminal name:            RTA1:
Image name:               $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE
Status:                   %SYSTEM-S-NORMAL, normal successful completion
Target PID:               30C00126
Target process name:      SMISERVER
Target username:          SYSTEM
Target process owner:     [SYSTEM]

The most common type of report to generate is a brief, daily listing of events. You can create a command procedure that runs in a batch job every evening before midnight to generate a report of the day's security event messages and send it to the system manager via Mail.

The following example shows the ANALYZE/AUDIT command line you would use to generate this type of report:

$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31JAN2000.AUDIT -
_$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ MAIL/SUBJECT="Security Events" 31JAN2000.AUDIT SYSTEM

Because the security audit log file continues to grow until you take action, you must devise a plan for maintaining it.

Use the SET AUDIT command to create a new version of the clusterwide security audit log file. To prevent the loss of audit messages, the previous version of the audit log file is not closed until all audit messages stored in memory are written to the file.

20.7.8.1 Creating a New Clusterwide Version of the Log File

To open a new, clusterwide version of the security audit log file, use the following command:

$ SET AUDIT/SERVER=NEW_LOG

The audit server process opens a new version of the audit log file on each cluster node.

After you open the new log, rename the old version, using a naming convention for your files that incorporates in the file name a beginning or ending date for the data. Then copy the file to another disk, delete the log from the system disk to save space, and run the Audit Analysis utility on the old log.

By archiving this file, you maintain a clusterwide history of auditing messages. If you ever discover a security threat on the system, you can analyze the archived log files for a trail of suspicious user activity during a specified period of time.

20.7.8.2 Creating a New Node-Specific Version of the Log File

In some cases, OpenVMS Cluster nodes might not share the same system security audit log file. To create a new, node-specific version of the security audit log file, use the following commands:

$ SET AUDIT/DESTINATION=filespec
$ SET AUDIT/SERVER=NEW_LOG

where filespec is a logical name that points to a node-specific file; for example, SYS$SPECIFIC:[SYSMGR]SECURITY. System security audit log files on other nodes are unaffected.

20.8 Monitoring Operating System Performance

The Monitor utility (MONITOR) is a system management tool that you can use to obtain information about operating system performance. Various MONITOR qualifiers collect system performance data from the running system or play back data recorded previously in a recording file. When you play back data, you can display it, summarize it, and even rerecord it to reduce the amount of data in the recording file.

Following an explanation of the Monitor utility are sections that tell how to perform these tasks:

For additional information about interpreting the information the Monitor utility provides, refer to the OpenVMS Performance Management. For additional information about using the Monitor utility, refer to the OpenVMS System Management Utilities Reference Manual.

20.8.1 Understanding MONITOR

Using MONITOR, you can monitor classes of systemwide performance data (such as system I/O statistics, page management statistics, and time spent in each of the processor modes) at specifiable intervals, and produce several types of output. You can also develop a database of performance information for your system by running MONITOR continuously as a background process, as explained in Section 20.8.9.

20.8.1.1 MONITOR Classes

Each MONITOR class consists of data items that, taken together, provide a statistical measure of a particular system performance category. The data items defined for individual classes are listed in the description of the MONITOR command in the OpenVMS System Management Utilities Reference Manual.

To monitor a particular class of information, specify a class name on the MONITOR command line. The information MONITOR displays depends on the type of class you select. Table 20-8 compares the two MONITOR class types.

As an example of the distinction between types of MONITOR classes, the IO class includes a data item to measure all direct I/O operations for the entire system, and is therefore a system class. The DISK class measures direct I/O operations for individual disks, and is therefore a component class.

Table 20-9 describes each MONITOR class and indicates whether it is a system or component class.

Except in the PROCESSES class, all data item statistics are displayed as rates or levels:

• Rates are shown in number of occurrences per second.
• Levels are values that indicate the size of the monitored data item.

You can request any or all of four different statistics for each data item:

For the DISK, MODES, SCS, and STATES classes, you can optionally express all statistics as percentages.

In the PROCESSES class, MONITOR displays descriptive information, level information, and counters that increase over time.

20.8.1.3 Output Types

MONITOR collects system performance data by class and produces three forms of optional output, depending on the qualifier you specify:

If you specify /INPUT with any of these qualifiers, MONITOR collects performance data from one or more previously created recording files; otherwise, data is collected from counters and data structures on the running system.

You use the /BEGINNING and /ENDING qualifiers to specify, respectively, when you want a MONITOR request to begin and end.

Using the /DISPLAY Qualifier

Information collected by MONITOR is normally displayed as ASCII screen images. You can use the optional /DISPLAY qualifier to specify a disk file to contain the information. If you omit the file specification, output is directed to SYS$OUTPUT.

Refer to the OpenVMS System Management Utilities Reference Manual for a discussion of the /DISPLAY qualifier.

Using the /RECORD Qualifier

When you use the /RECORD qualifier, all data pertaining to the class is recorded, even if you are concurrently displaying only a single statistic or a single item of a component statistics class. The file is created when a MONITOR request is initiated and closed when a request terminates. You can use the resulting file as a source file for later requests to format and display the data on a terminal, to create a summary file, or to create a new recording file with different characteristics.

20.8.2 Invoking MONITOR

To invoke the Monitor utility, enter the following DCL command:

$ MONITOR

MONITOR then displays the following prompt:

MONITOR>

In response to the prompt, you can enter any of the MONITOR commands, which are described in OpenVMS System Management Utilities Reference Manual. The most frequently used MONITOR command, however, specifies a class name.

Example

MONITOR> MONITOR PAGE

In this example, you specify the PAGE class name in the MONITOR command to monitor page management statistics.

You can also use the MONITOR command from DCL command level.

How to Override or Terminate a MONITOR Request

Generally, each MONITOR request runs until the time specified or implied by the /ENDING qualifier. However, to override or terminate a MONITOR request, you can press one of the following conbinations of keys:

Use the live display monitoring mode of operation when you want to examine the activity of a running system, either on a routine basis or as part of an installation checkout, tuning, or troubleshooting exercise. The system does not keep a historical record of output. The following examples show how to use the live display monitoring mode.

Examples

1. $ MONITOR PROCESSES/TOPCPU

   
   The command displays a bar graph showing the eight processes that were the top consumers of CPU time during the period between displays. It also displays the amount of CPU time each process used.
   The command might produce a display similar to the following one:

   OpenVMS Monitor Utility TOP CPU TIME PROCESSES on node BOMBAY 20-JAN-2000 10:06:49 0 25 50 75 100 + - - - - + - - - - + - - - - + - - - - -+ 07E00181 CAFARET 100 **************************************** | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + - - - - + - - - - + - - - - + - - - - -+

   
   This example shows that user CAFARET is using 100 percent of the CPU time available. To display more information about the computer resources a user is using, use a command similar to the following one:

   $ SHOW PROCESS/CONTINUOUS/ID=07E00181

   
   For this example, the most useful information in the resulting display is the name of the image at the end of the display; for example:

   . . . $1$DUA1:[SYS1D.SYSCOMMON.][SYSEXE]RODAN.EXE

   
   This example indicates that CAFARET is running RODAN.EXE, which might be new software that is unintentionally running in a loop. This situation would occur if CAFARET were a privileged user running a process at a higher priority than other users.

2. $ MONITOR/DISPLAY=PROCESSES.LOG PROCESSES

   
   You can route MONITOR display output to any supported terminal device or to a disk file. This command writes MONITOR's display process statistics to the file PROCESSES.LOG. You can then print this file on a hardcopy device.

   Caution Because data is continuously added to the display file, be careful that the file does not grow too large.

3. $ MY_CLASSES :== - _$ "DECNET+FCP+IO+LOCK+MODES+PAGE+PROCESSES+STATES" $ MONITOR/NODE=(CURLEY,LARRY)/INTERVAL=20/VIEWING_TIME=8 'MY_CLASSES'

   
   You might find it convenient to establish DCL symbols for frequently used combinations of class names, as in this example. The MONITOR command collects selected classes of data for OpenVMS Cluster nodes CURLEY and LARRY every 20 seconds. Every 8 seconds, the system displays the most recently collected data for one of the classes. MONITOR predetermines the ordering of the classes for display.