HP OpenVMS System Manager's Manual, Volume 2:... |
Getting Information About the System |
|
|
| |
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 Event Classes Audited by Default.
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
Enabling Security Auditing for Additional Classes.
Security Audit Log File ![]()
The audit server process, which is created at system startup,
records the events that are shown in
Event Classes Audited by Default 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:
Audit Log Files in Mixed-Version Clusters ![]()
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=filespecThe 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 HP OpenVMS Guide to System Security for more information.
Displaying Security Auditing Information ![]()
To see which event classes your site currently audits, you
can enter the DCL command SHOW AUDIT.
The follow example contains 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
Delaying Startup of Auditing ![]()
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 YESYou 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=INITIATEFor information about editing
SYSTARTUP_VMS.COM, see the HP OpenVMS System Manager's Manual, Volume 1: Essentials.
Enabling Security Auditing for Additional
Classes ![]()
To enable security auditing for classes in addition to those
shown in
Event Classes Audited by Default, use
the following format: SET AUDIT/ENABLE=keyword[,...] {/ALARM | /AUDIT}
The HP 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:
The following table contains explanations of the /ENABLE, /ALARM, and /AUDIT qualifiers.
| Qualifier | Explanation |
|---|---|
|
/ENABLE
|
Defines which event classes
you want audited. See
Tracking Resource Use for more information.
|
|
/ALARM /AUDIT
|
Defines the destination of the event
message.
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 Event Classes Audited by Default are sent as both alarms and audits. |
The system begins auditing new events on all nodes as soon as you enable them.
$SET AUDIT/ENABLE=MOUNT/AUDIT
$SET AUDIT/ALARM/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE
Disabling Security Auditing ![]()
The system continues auditing until you explicitly disable
the classes with the /DISABLE qualifier using the following syntax:SET AUDIT/DISABLE=keyword[,...] {/ALARM | /AUDIT}
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:
Example$REPLY/ENABLE=SECURITY
The following example shows a security alarm message:
%%%%%%%%%%% OPCOM 25-MAY-2002 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-2002 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]
Generating Security Reports ![]()
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.
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. |
$ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31JAN2002.AUDIT -_$SYS$MANAGER:SECURITY.AUDIT$JOURNAL$MAIL/SUBJECT="Security Events" 31JAN2002.AUDIT SYSTEM
Creating a New Version of the Security Audit
Log File ![]()
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.
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:
The audit server process opens a new version of the audit log file on each cluster node.$SET AUDIT/SERVER=NEW_LOG
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.
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:
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.$SET AUDIT/DESTINATION=filespec$SET AUDIT/SERVER=NEW_LOG
|
|