The threshold values may be expressed in blocks or as a delta time. Delta time values are multiplied by the average space consumption rate to yield a number of blocks. The maximum of the block and time threshold values is used as the active threshold value.
Resources consumed by the OpenVMS security-auditing facility vary with the number and type of system events being recorded. Three different error conditions can develop related to the auditing facility:
This section discusses the default behavior of the auditing system in monitoring disk space and logging to an archive file.
The audit server monitors the audit log file and regularly pre-extends its disk block allocation to ensure there is adequate space for incoming event messages. Whenever disk space is unavailable, the server first warns you through operator messages and then resorts to suspending certain contributing processes (see Section 9.6.8). If you find many processes suspended for no apparent reason, it is probably because your audit disk is full. Once you correct the disk space problem, you can resume suspended processes with the SET AUDIT/SERVER=RESUME command (rather than wait for the next resource scan).
You can disable resource monitoring altogether by entering the following command:
$ SET AUDIT/JOURNAL=SECURITY/RESOURCE=DISABLEHowever, if you disable disk resource monitoring, you eliminate the opportunity to receive warning messages until it is too late. The audit server begins to suspend processes that are generating too many audits, as Section 9.6.4 describes, and if it runs out of memory, the server takes the action described in Section 9.6.5: it ignores messages, purges old messages, or, possibly, crashes the system.
Once disk space becomes available, the audit server extends the log file and resumes any processes it suspended.
If you are writing auditing messages to a remote log file, as described in Section 9.4.3.1, the link between the local and remote node can fail. Should this happen, the audit server broadcasts a warning message to all operator terminals and attempts to reestablish the link every minute until the connection is made.
Along with developing a security policy and selecting appropriate security measures to implement that policy, a site needs to establish and test procedures for handling system, site, or network compromises. The procedure should address two areas:
This chapter describes how to recognize when an attack on the system is in progress or has taken place and what countermeasures can be taken.
As security administrator, you must monitor the system on a regular basis for possible security breaches. Following are the most common forms of system attacks:
When your system is vulnerable and possibly under attack, your first indications may come from the following sources:
User observations frequently point to system security problems. A user may contact you with the following situations:
Follow up promptly when one of these items is reported to you. You must confirm or deny that the condition exists. If you find the complaint is valid, seek a cause and solution.
Section 6.7 lists those tasks that can help you detect potential security breaches on your system. The following list details possible warning signs you may uncover while performing the recommended tasks:
All these conditions warrant further investigation. Some indicate that you already have a problem, and some may have simple explanations, while others may indicate serious potential problems.
The operating system provides a number of mechanisms that allow systematic surveillance of the activity in your system. There are many mechanisms available for monitoring the system either manually or by user-written command procedures, for example:
Proper use of such mechanisms should help you verify settings, alert you to problems, and allow you to intervene. This section describes the most important system surveillance mechanisms--ACCOUNTING and ANALYZE/AUDIT.
You can learn what the normal pattern of resource use is by studying reports of the Accounting utility (ACCOUNTING). To obtain a report, you run the utility image SYS$SYSTEM:ACC.EXE. The resulting data file is SYS$MANAGER:ACCOUNTNG.DAT. Review ACCOUNTING reports because they can provide early indications of problems. Check for the following:
As the security administrator, you can have the operating system report on security-related activity by enabling categories of events for auditing using the DCL command SET AUDIT. Using the Audit Analysis utility (ANALYZE/AUDIT), you can periodically review event messages collected in the security audit log file. (See Chapter 9 for a full description of the process.)
The operating system can send event messages to an audit log file or to an operator terminal. You define whether events are reported as audits or alarms in the following way:
$ SET AUDIT/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=(FILE,DEVICE,VOLUME)
$ SET AUDIT/ALARM/ENABLE=(INSTALL,TIME)
Because security auditing affects system performance, enable auditing only for the most important events. The following security-auditing actions are presented in order of decreasing priority and increasing system cost:
Device and Directory | File Name |
---|---|
SYS$SYSTEM | AUTHORIZE.EXE |
F11BXQP.EXE | |
LOGINOUT.EXE | |
DCL.EXE | |
JOBCTL.EXE | |
SYSUAF.DAT | |
NETPROXY.DAT | |
RIGHTSLIST.DAT | |
STARTUP.COM | |
VMS$OBJECTS.DAT | |
SYS$LIBRARY | SECURESHR.EXE |
SECURESHRP.EXE | |
SYS$MANAGER | VMS$AUDIT_SERVER.DAT |
SY*.COM | |
VMSIMAGES.DAT | |
SYS$SYSROOT | [000000]SYSEXE.DIR |
[000000]SYSLIB.DIR | |
[000000]SYS$LDR.DIR | |
[000000]SYSMGR.DIR |
Section 9.3 provides further discussion of recommended sets of security events to audit.
There are four phases that security administrators experience while handling a security breach, whether the breach actually occurred or was attempted:
The following sections describe these phases for both attempted and successful break-ins.
In all phases, train personnel to retain information and data as evidence, should there be a need to apprehend and prosecute the perpetrator.
Unsuccessful intrusion attempts include situations where someone has attempted to guess passwords or browse through files.
You usually detect intrusion attempts through the following sources:
Enabling file auditing simplifies identification of file browsers. If, however, browsing is being initiated from another node in the network, you must inspect the network server log file (NETSERVER.LOG) that corresponds to the times of the protection violations. Coordinate your investigation with the security administrator at the remote node.
Identifying a perpetrator who is guessing passwords is considerably more difficult, especially when the source is anonymous, as from a dialup line. Usually, you must trade identification for prevention. Often the only way to positively identify an outsider attempting to enter the system requires that you permit further attempts while establishing the perpetrator's identity.
The prevention phase for this kind of attack involves preventing the would-be intruder from actually gaining access to the system and making future attempts more difficult.
Password Guessing
To reduce the opportunities for successful password guessing:
File Browsing
To reduce the opportunities for successful file browsing:
A successful security breach can include a successful password guessing scheme, theft or modification of information or system resources, and placement of damaging software on the system. An intrusion may require a considerable amount of time to repair, depending upon the skill and intent of the perpetrator.
Identification is often the most difficult part of handling an intrusion. First, you must establish whether the perpetrator is an authorized user or not. This determines the nature of the preventive measures that you will take. However, the distinction between insiders and outsiders may be difficult to achieve.
Tradeoff Between Identification and Prevention
You may have to make a tradeoff between a positive identification of the intruder and preventing future attacks. Often, the data available initially does not allow complete identification. If it is important to identify the perpetrator, you will often find it necessary to permit continued intrusions while you analyze the intrusion activity. Increase your auditing. Consider planting traps in system procedures that are under your control (such as SYLOGIN.COM) to obtain additional information. Increase your system backup efforts to permit easier recovery if files become damaged.
Identification of Outsiders
Identifying external intruders is particularly difficult, especially if they use any switched forms of communication (such as dialup lines or public data networks). DECnet for OpenVMS software provides many features to help you trace the activity through the network back to the source node. If a local terminal is involved, physical surveillance may be appropriate.
When a switched connection is involved, one of the major computer security problems is the telephone system itself. Tracing a telephone or public data network connection is time-consuming. Chasing an intruder through the telephone system is likely to take months and will require the assistance of law enforcement authorities. The existence of multiple long-distance telephone services compounds the problem by increasing the number of organizations with whom you must deal.
As a result, identifying an outside intruder is usually worthwhile only when you have sustained substantial financial damage. In many cases, it may be more useful if you concentrate on preventing recurrences of the problem.
The actions you must take to secure your system after an intrusion depend on the nature and source of that intrusion. This section describes these actions in order of priority.
After an intrusion, restore corrupted files. Decide whether it is appropriate to do a wholesale restoration of your system's data or to repair problems as they are discovered. Look for modifications to file protection that would have created paths for viruses and for Trojan horses that were introduced into the system and may still reside there.
This chapter describes concerns for security administrators of clustered systems. Clustered systems refer to those systems using hardware and software that permits sharing of disks, resources, and a common operating system among various computers. Clusters of VAX processors are said to be joined in a VAXcluster environment, whereas clusters including both Alpha processors and VAX processors are said to be joined in a VMScluster environment. To properly secure your cluster, you should be familiar with the information in OpenVMS Cluster Systems.
OpenVMS Cluster Systems describes the tasks of the cluster manager. The cluster manager's job is the same as that of any system manager, but the cluster manager has to implement changes across many nodes. The security administrator for a cluster generally requires the same training and skills as a cluster manager, and at some cluster sites, the same person serves in the role of security administrator as well as cluster manager. At other sites, there may be one or more security administrators in addition to a cluster management team.
When a site separates the security administrator function from the cluster management function, coordination, cooperation, and communication between these functions becomes vital. As in previous chapters, this chapter uses the title of security administrator to refer to individuals who have the responsibility for system security, regardless of what other responsibilities they hold.
Clustered systems provide a uniform computing environment that is highly scalable, highly available, and secure. It is critical that there be a single set of authorized users and that these users be able to have processes executing on any cluster member.
To achieve a uniform computing environment, a cluster relies on the following components operating across all cluster members:
Within a cluster, authorization data for users and the security profiles of objects must be consistent across all nodes so that each cluster member makes the same access control decision when presented with a particular user's access request for a particular object. Section 11.2 and Section 11.3 describe how to achieve a single security domain.
Within a cluster, access control is mediated by individual nodes using a common set of authorization information. In the single security domain model, a process, acting on behalf of an authorized individual, requests access to a cluster-visible object, and a coordinating node determines the outcome by comparing its copy of the common authorization database with the security profile for the object being accessed. This model enforces security only when the authorization information and the object security profiles are consistent across all nodes in the cluster.
6346P019.HTM OSSG Documentation 22-NOV-1996 13:05:19.76
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.