Methods of Capturing Event Messages
| | |
| ||
| ||
The operating system can send event messages to an audit log file or to an operator terminal. If a site wants additional copies, it can send duplicate messages to a remote log file or an application listener mailbox.
The operating system writes all security event messages to the latest version of the security audit log file. This log file is created by default during system startup in the SYS$COMMON:[SYSMGR] directory and named SECURITY.AUDIT$JOURNAL. “Characteristics of the Audit Log File” describes some of its more notable characteristics.
Table 10-5 Characteristics of the Audit Log File
| Characteristic | Advantage |
|---|---|
Binary | A binary file requires the least amount of disk space. |
Clusterwide | A clusterwide file, when processed by the Audit Analysis utility, results in one report of security-relevant events in the cluster. |
Sequential record format | A sequential record format is easily analyzed by user-written programs. See the HP OpenVMS System Management Utilities Reference Manual for a description of the message format of the security audit log file. |
Ordinarily, all cluster events are written to a single audit log file. The use of one security audit log file in a cluster results in a single record of all security-relevant events on the system. For this reason, one clusterwide log file is preferable to node-specific audit logs, which lose the interrelationship of events across the cluster, thus producing an incomplete analysis of security events. You can, if you wish, create node-specific audit logs (see “Maintaining the File”), but this is not the recommended procedure.
The usefulness of the security audit log file depends upon the procedures you adopt:
Maintain the log file so events are recognized early and the file does not get too big (see “Maintaining the File”).
Routinely review the log file and scrutinize suspicious activity (see “Analyzing a Log File”).
The security audit log file continues to grow until action is taken, so you must devise a plan for maintaining it.
Typically, sites rename each day's log file and create a new one. To open a new, clusterwide version of the security audit log file, use the following command:
|
|
|
To create a new, node-specific log, precede the SET AUDIT/SERVER=NEW_LOG command with the command SET AUDIT/DESTINATION=filespec where the file specification includes a logical name that resolves to a node-specific file (for example, SYS$SPECIFIC:[SYSMGR]SECURITY).
Once you have opened the new log, rename the old version with a name that incorporates a beginning or ending date for the data.
To save space on the system disk, you may want to copy the file to another disk and delete the log from the system disk. Even sites with a dedicated auditing disk, which is common to environments with high security requirements, may want to relocate the old version to make space for future messages.
Once you archive the file, run the Audit Analysis utility on the old log (see “Invoking the Audit Analysis Utility”). 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.
To relocate the file from the SYS$COMMON:[SYSMGR] directory, edit the command procedure SYSECURITY.COM. This procedure executes each time the system is rebooted, before the audit server is started.
To relocate the file, perform the following steps:
Change the startup sequence by adding a line to SYSECURITY.COM that directs the operating system to mount the designated auditing disk before the audit server process is started rather than after. For example:
$ IF .NOT. F$GETDVI("$1$DUA2","MNT") - _$ THEN MOUNT/SYSTEM $1$DUA2 AUDIT AUDIT$ /NOREBUILDThe command in this example mounts a volume labeled AUDIT on $1$DUA2 and makes it available systemwide. MOUNT also assigns the logical name AUDIT$.
Move the audit server database to the auditing disk, if you choose. The database remains small and fairly stable so this step is not essential.
To move the database, add a second line to SYSECURITY.COM to define the system logical name VMS$AUDIT_SERVER. (The line follows the one that mounts the auditing disk.) In the command, define a system logical name and assign it to the VMS$AUDIT_SERVER data file on the disk with the logical name AUDIT$. For example:
$ DEFINE/SYSTEM/EXEC VMS$AUDIT_SERVER AUDIT$:[AUDIT]VMS$AUDIT_SERVER.DAT
This command redirects the audit server database to the volume on $1$DUA2, which was mounted in step 1.
From the DCL level, redirect the security audit log file to the volume mounted in SYSECURITY.COM (see step 1). Use the SET AUDIT command to update the audit server database with the new location of the security audit log file, and instruct the audit server process on each node in the cluster to begin using the file. For example:
$SET AUDIT/JOURNAL=SECURITY - _$/DESTINATION=AUDIT$:[AUDIT]SECURITY
Do not repeat this command on each system restart.
If you use a logical name in the specification of the security audit log file, it must be defined as a /SYSTEM logical name in SYSECURITY.COM.
The operating system sends alarm messages to terminals enabled for security class messages. In most cases, these security alarms appear on the system console by default. Because messages scroll quickly off the screen, it is a good practice to enable a separate terminal for security class messages and disable message delivery to the system console. Choose either a terminal in a secure location that provides hardcopy output or have dedicated staff monitor the security operator terminal. Any number of terminals can be enabled as security operators.
To set up a terminal to receive security class alarms, enter the following DCL command from the designated terminal:
|
|
|
For long-term use of a specific terminal, you can modify your site-specific startup command procedure to automatically enable the terminal. For example, the following command lines in a startup command procedure disable the delivery of security alarms to the system console and enable alarms on terminal TTA3:
|
|
|
The authorization and SYSGEN event classes occasionally produce such lengthy alarm messages that the messages get truncated. For this reason, it is best to enable these classes for both alarms and audits. When an alarm message is truncated, the text indicates it is incomplete. As long as you have enabled the classes for audit messages, you can use ANALYZE/AUDIT to display the complete message.
The operator terminal and the audit log file are the primary destinations for security event messages. A site can choose to send copies of audit messages to a remote log file (called an archive file) or a listener mailbox.
The operating system allows workstations and other users with limited management resources to duplicate their audit log file on another node. This secondary log, the security archive file, is then available on a remote node to a security administrator who has the skills to analyze the file. In some situations, the archive file can also provide insurance should the local audit log file be tampered with in some way. One node can direct auditing messages to an archive file. Once enabled, the audit server writes a copy of each auditing message to the security archive file as well as to the security audit log file.
| |
| |
| |
 | NOTE: Each node in a cluster must have its own archive file. An archive file cannot be shared by multiple nodes in a cluster. |
| |
| |
| |
Use the following procedure to write security audit messages to a remote security archive file:
Log in to the node where the archive file is located, and create an account for the audit server. To the account, assign a user name like AUDIT_ARCHIVE; make the account unprivileged with only network access. Be sure the account has access to the device and directory containing the security archive file.
$SET DEFAULT SYS$SYSTEM $RUN AUTHORIZE UAF>ADD AUDIT_ARCHIVE /ACCESS=NETWORK /DEVICE=WORK2- _UAF>/DIRECTORY=[AUDIT_ARCHIVE]
Add a proxy account on the remote node for AUDIT$SERVER. This allows the audit server process to write data to its account on the remote node. For example, the following commands grant the audit server process on node SMLNOD proxy access to the AUDIT_ARCHIVE account on node BIGNOD:
UAF>ADD/PROXY SMLNOD::AUDIT$SERVER AUDIT_ARCHIVE/DEFAULT UAF>EXIT
See “Setting Up a Proxy Database” for further information about setting up proxy accounts.
Log out from the remote node. On the local node, enable archiving of the log file to the node by entering the following command:
$SET AUDIT/ARCHIVE=ALL/DESTINATION=BIGNOD::WORK2:- _$[AUDIT_ARCHIVE]SMLNOD_MAY_93.AUDIT$JOURNAL
You must supply a complete directory specification. If you include any logical names, ensure the local audit server process can translate them.
To create a new archive file, rename the current file; the next time the system starts up, it creates a new one for you.
If the network goes down, messages intended for the security archive file are lost. Security operator terminals receive notice of the lost connection and the number of lost messages. Once the network is up, the audit server reestablishes connection to the original archive file and continues writing event messages.
Analyzing the security archive file is identical, in most respects, to analysis of the security audit log file. You can analyze a remote security archive file at any time, even while the file is open. See “Analyzing a Log File” for more information.
As an additional feature of the security auditing facility, you can create a listener device to receive a binary copy of all security-auditing messages. (A listener device is a permanent or temporary mailbox that you create with the Create Mailbox [$CREMBX] system service.) You can set up an application to receive and process auditing information and react to events as they occur on the system. Each system can have one listener device, and it can receive only events that are occurring on the local node.
To enable the listener device to receive security-auditing messages, execute the SET AUDIT/LISTENER command in the following format:
SET AUDIT/LISTENER=device-name
For the device-name parameter, supply either the logical name specified when you created the mailbox or the equivalence name of the mailbox, in the form of MBAn, where n represents the unit number of the mailbox. If you create the device as a temporary mailbox, you must use the Get Device and Volume Information ($GETDVI) system service to return the mailbox device name.
To disable an audit listener device, enter the following command:
|
|
|
On VAX systems, see the files AUDSRV_LISTENER.B32 (a VAX BLISS program) and AUDSRV_LISTENER.MAR (a VAX MACRO program) in the SYS$EXAMPLES directory for examples of a program that processes audit-event messages sent to a listener mailbox on a DECtalk device.