OpenVMS System Manager's Manual

For more information, see the REPLY/LOG, REPLY/ENABLE, and REPLY/DISABLE commands in the OpenVMS DCL Dictionary.

Example

The following command opens a log file to include messages about mounting and dismounting disks and tapes:

$ REPLY/LOG/ENABLE=(DISKS,TAPES)

You can specify the default state of the operator log files by defining logical names in the command procedure SYS$MANAGER:SYLOGICALS.COM. The following table lists these logical names and their functions. For more information on SYLOGICALS.COM, see Section 5.2.5.

Caution

Setting the OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND logical names to FALSE severs all OPCOM traffic in the specified direction. All OPCOM messages, as well as any returned status messages that might be expected, will not be delivered.

Note

The only logical that is used for more than the initial startup of OPCOM is OPC$LOGFILE_NAME. All other OPCOM logicals are ignored. For example, a REPLY/LOG command opens a new operator log file even if the logical OPC$LOGFILE_ENABLE is defined to be false. To reset OPCOM states and classes after startup, use REPLY/ENABLE or REPLY/DISABLE commands.

Devise a plan for regular maintenance of operator log files. One way is to start a new log file and rename the second-highest version daily. (See the example in the next section.) You might want to purge outdated versions of the operator log file on a regular basis. However, do not delete versions that you have not backed up. For more information, see Section 5.2.7.9.

If OPCOM is inadvertently deleted, follow these steps to start it manually:

1. Log in to the SYSTEM account so that you have the required privileges to perform the operation.
2. Enter the following command to execute the startup command procedure (STARTUP.COM), specifying OPCOM as the command parameter:

   $ @SYS$SYSTEM:STARTUP OPCOM 
   

Perform the following operation to produce a printed copy of the most recent version of the operator log file. (You must have OPER privilege.)

1. Use the following command to enable the terminal as an operator terminal:

   $ REPLY/ENABLE
   

2. Close the current log file and open a new one by entering the following command:

   $ REPLY/LOG
   

3. Set the default to SYS$MANAGER and enter the following command to list all versions of the file:

   $ SET DEFAULT SYS$MANAGER
   $ DIRECTORY OPERATOR.LOG
   

4. Rename the second-highest version to OPERATOR.OLD:

   $ RENAME OPERATOR.LOG;-1 OPERATOR.OLD
   

   
   The version number, --1, specifies that you want to rename the second-highest version of this file. (The highest version number is the current operator log file.)
5. Print the operator log file by entering the following command:

   $ PRINT OPERATOR.OLD
   

Example

$ REPLY/ENABLE (1)
$ REPLY/LOG (2) 
%%%%%%%%%%%  OPCOM, 19-APR-1996 12:28:20.11  %%%%%%%%%%%
Logfile was closed by operator _MARS$VTA2: (3) 
Logfile was HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;27
%%%%%%%%%%%  OPCOM, 19-APR-1996 12:29:24.52  %%%%%%%%%%%
Logfile has been initialized by operator _MARS$VTA2:
Logfile is HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;28
$ SET DEFAULT SYS$MANAGER (4) 
$ DIRECTORY OPERATOR.LOG (5) 
Directory SYS$MANAGER:[SYSMGT]
OPERATOR.LOG;28           OPERATOR.LOG;27
Total of 2 files.
$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD (6) 
$ PRINT OPERATOR.OLD (7)

Following are explanations of the numbered commands and responses in this example:

1. The REPLY/ENABLE command enables the terminal as an operator terminal.
2. The REPLY/LOG command closes the current log file and opens a new one.
3. The response from OPCOM verifies that it has opened a new log file.
4. The SET DEFAULT command sets the operator default disk to the system disk.
5. The DIRECTORY command displays the files in the directory [SYSMGT] on the system disk.
6. The RENAME command renames the second-highest version of the operator log file to OPERATOR.OLD.
7. The PRINT command prints the old operator log file, OPERATOR.OLD.

This section discusses how security auditing works; it also explains how to enable security auditing and how to create a new version of the security audit log file. For more information about the security audit log file, see the OpenVMS Guide to System Security.

18.7.1 Understanding Security Auditing

Security auditing is the act of recording security-relevant events as they occur on the system. Security-relevant events are divided into a number of categories called event classes.

By default, the system enables security auditing when you install or upgrade your system for the events shown in Table 18-6.

Table 18-6 Event Classes Audited by Default

Class	Description
ACL	Access to any object holding a security Auditing ACE.
AUDIT	All uses of the SET AUDIT command. You cannot disable this category.
AUTHORIZATION	All changes to the authorization database: System user authorization file (SYSUAF) Network proxy authorization files: NETPROXY and NET$PROXY Rights database (RIGHTSLIST)
BREAKIN	All break-in attempts: batch, detached, dialup, local, network, remote.
LOGFAILURE	All login failures: batch, dialup, local, remote, network, subprocess, detached.

If the security requirements at your site justify additional auditing, you can enable security auditing for other event classes by using the DCL command SET AUDIT, as explained in Section 18.7.4.

18.7.1.1 Security Audit Log File

The audit server process, which is created at system startup, records the events that are shown in Table 18-6 in the security audit log file, SYS$MANAGER:SECURITY.AUDIT$JOURNAL.

The usefulness of the security audit log file depends upon the procedures you adopt to review the file on a regular basis. For example, you might implement the following procedure as part of your site audit review policy:

1. Create a new version of the security audit log file each morning.
2. Review the previous version of the log file for suspicious system activity. Depending on the number of security events you are auditing on your system, it might be impractical to review every audit record written to the audit log file. In that case, you might want to select a specific set of records from the log file (for example, all Authorization and Breakin records, or all events created outside normal business hours).
3. If, during your review, you find any security events that appear suspicious, perform a more detailed inspection of the security audit log file, as described in the OpenVMS Guide to System Security.

The Audit Analysis utility (ANALYZE/AUDIT) running on earlier-version systems is unable to process the current version of audit log files. You must use the current version of ANALYZE/AUDIT to process the current version of the audit log files. The recommended procedure is to maintain separate audit log files on mixed-version clusters.

If redirecting the audit log files, issue the following command on both the earlier-version node and on the node running the current version:

AUDIT/JOURNAL/DESTINATION=filespec 

The destination filespec is stored in the audit server database file. By default, the files are stored in SYS$COMMON:[SYSMGR] and are called SECURITY_AUDIT.AUDIT$JOURNAL and SECURITY.AUDIT$JOURNAL, respectively.

The operating system allows workstations and other users with limited management resources to duplicate their audit log files on another node. The secondary log, a security archive file, is then available to a security administrator on a remote node who has the skills to analyze the file.

Each node in a cluster must have its own archive file. An archive file cannot be shared by multiple nodes in a cluster.

Refer to the OpenVMS Guide to System Security for more information.

18.7.2 Displaying Security Auditing Information

To see which event classes your site currently audits, you can enter the DCL command SHOW AUDIT.

Following is an example of security information:

$ SHOW AUDIT

System security alarms currently enabled for: 
  ACL 
  Breakin:       dialup,local,remote,network,detached 
  Privilege use: 
    SECURITY 
  Privilege failure: 
    SECURITY 
 
System security audits currently enabled for: 
  ACL 
  Authorization 
  Breakin:       dialup,local,remote,network,detached 
  Login:         dialup,local,remote,network,detached 
  Logfailure:    batch,dialup,local,remote,network,subprocess,detached 
  Logout:        dialup,local,remote,network,detached 
  Privilege use: 
    SECURITY 
  Privilege failure: 
    ACNT      ALLSPOOL  ALTPRI    AUDIT     BUGCHK    BYPASS    CMEXEC    CMKRNL 
    DETACH    DIAGNOSE  EXQUOTA   GROUP     GRPNAM    GRPPRV    LOG_IO    MOUNT 
    NETMBX    OPER      PFNMAP    PHY_IO    PRMCEB    PRMGBL    PRMMBX    PSWAPM 
    READALL   SECURITY  SETPRV    SHARE     SHMEM     SYSGBL    SYSLCK    SYSNAM 
    SYSPRV    TMPMBX    VOLPRO    WORLD 
  DEVICE access: 
    Failure:     read,write,physical,logical,control 
  FILE access: 
    Failure:     read,write,execute,delete,control 
  VOLUME access: 
    Failure:     read,write,create,delete,control 

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 on editing SYSTARTUP_VMS.COM, see Section 5.2.7.

18.7.4 Enabling Security Auditing for Additional Classes

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

SET AUDIT/ENABLE=keyword[,...] {/ALARM | /AUDIT} 

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

Following are explanations of the /ENABLE, /ALARM, and /AUDIT qualifiers.

Qualifier	Explanation
/ENABLE	Defines which event classes you want audited. See Chapter 19 for more information.
/ALARM /AUDIT	Defines the destination of the event message. /ALARM directs the message to all enabled security operator terminals. /AUDIT directs the message to the security audit log file. Use the /ALARM and /AUDIT qualifiers to report critical events. Less critical events can be written only to the security audit log file for later examination. The default event classes listed in Table 18-6 are sent as both alarms and audits.

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:

SET AUDIT/DISABLE=keyword[,...] {/ALARM | /AUDIT} 

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-1996 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-1996 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.

Note

Because the MOUNT command translates /NOLABEL to /FOREIGN in the audit record, use ANALYZE/AUDIT/SELECT=MOUNT_FLAGS=FOREIGN instead of ANALYZE/AUDIT/SELECT=MOUNT_FLAGS=NOLABEL.

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

$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31JAN1996.AUDIT -
_$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ MAIL/SUBJECT="Security Events" 31JAN1996.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.

18.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.

18.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.

18.8 Monitoring Operating System Performance

The Monitor utility (MONITOR) is a system management tool that you can use to obtain information on 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:

Task	Section
Invoking the Monitor utility	Section 18.8.2
Using live display monitoring	Section 18.8.3
Using live recording monitoring	Section 18.8.4
Using concurrent display and recording monitoring	Section 18.8.5
Using playback monitoring	Section 18.8.6
Using remote playback monitoring	Section 18.8.7
Rerecording monitoring	Section 18.8.8
Running MONITOR continuously	Section 18.8.9
Using remote monitoring	Section 18.8.10

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

18.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 18.8.9.

18.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 18-7 compares the two MONITOR class types.

Table 18-7 Types of MONITOR Classes

Type of class	Description
System	Provides statistics on resource use for the entire system
Component	Provides statistics on the contribution of individual components to the overall system or cluster

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 18-8 describes each MONITOR class and indicates whether it is a system or component class.

Table 18-8 MONITOR Classes

Class	Type	Description
ALL_CLASSES	System or Component	Statistics for all classes
CLUSTER	System	Clusterwide performance statistics
DECNET	System	DECnet for OpenVMS statistics
DISK	Component	Disk I/O statistics
DLOCK	System	Distributed lock management statistics
FCP	System	File control primitive statistics
FILE_SYSTEM_CACHE	System	File system cache statistics
IO	System	System I/O statistics
LOCK	System	Lock management statistics
MODES	Component	Time spent in each of the processor modes
MSCP_SERVER	System	MSCP server statistics
PAGE	System	Page management statistics
PROCESSES	Component	Statistics on all processes
RMS	Component	Record Management Services statistics
SCS	Component	System Communications Services statistics
STATES	System	Number of processes in each of the scheduler states
SYSTEM	System	Summary of statistics from other classes
TRANSACTION	System	DECdtm services statistics
+VBS	System	Virtual balance slot statistics
VECTOR	System	Vector processor scheduled usage

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:

Statistic	Description
Current rate or level	Most recently collected value for the rate or level
Average rate or level	Measured from the beginning of the MONITOR request
Minimum rate or level	Measured from the beginning of the MONITOR request
Maximum rate or level	Measured from the beginning of the MONITOR request

  6017P059.HTM
  OSSG Documentation
  22-NOV-1996 14:22:43.62

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal