HP OpenVMS Systems Documentation

Section 3.8 describes password grabbers as a class of programs designed to steal passwords from unsuspecting users who log in to terminals left on. The operating system provides a secure terminal server that stops any currently executing process before the start of a login at that terminal.

Invoke the secure server separately for each terminal with the following DCL command:

The user must then press the Break key followed by the Return key to start a login. The login proceeds as usual.

If you apply the secure server to all terminals, you can make the login procedure consistent throughout the site by putting the SET TERMINAL commands in the site-specific startup command procedure. However, certain applications that may use the terminal as a communications line need to use the Break key for their own purposes, which would be incompatible with the secure terminal server.

The secure terminal server feature is also incompatible with autobaud handling. However, because autobaud handling is necessary only on modem terminals (switched and dialup terminals), the modem handling on such terminals performs the equivalent of secure server functions. For secure operation, set up the terminal characteristics as follows:

• For local terminals (direct-wired), use the following SET TERMINAL qualifiers:

  /NOMODEM/SECURE/DISCONNECT/NOAUTOBAUD/PERMANENT

• For switched terminals (data-switch and dialup), use the following SET TERMINAL qualifiers:

  /MODEM/AUTOBAUD/NOSECURE/DISCONNECT/PERMANENT

Specify the /DIALUP qualifier if the terminal port is accessible through a telephone line or the equivalent, regardless of the path (direct modem, data switch, terminal server, or public data network).

Always specify the /DISCONNECT qualifier to guard against password grabbers. To prevent disconnected jobs from filling up your system, set the system parameter TTY_TIMEOUT to a low timeout value, which determines when disconnected processes are deleted.

If you decide to apply the secure server to individual terminals, include directly wired terminals located in public areas or remote, unsecured areas. Terminals never used for local or dialup logins are not subject to this security problem. Terminals closely supervised during logins may also not require this measure.

7.5.5 Detecting Intruders

Occasionally people fail to log in correctly because they enter an expired password or make a typing error. But not all failures are benign: some occur because an unauthorized person is trying to log in through an expired account or with an unknown user name or is attempting to guess passwords on a valid account.

The operating system is sensitive to login failures. After one failure, it begins to monitor the terminal, terminal server connection, or network connection where the login is taking place. At first, the operating system records unsuccessful logins in an intrusion database. As failures continue, the operating system not only records failures but takes restrictive measures. The person attempting login is monitored more closely and limited to a certain number of login retries within a limited period of time. Once a person exceeds either the retry or time limitation, he or she cannot log in for a while, even with a valid user name and password. At a later point, the restriction eases, and login is allowed once again.

7.5.6 Understanding the Intrusion Database

The DCL command SHOW INTRUSION displays the contents of the intrusion database; Example 7-5 shows a sample display. The database captures the following types of information on login failures:

Whenever the system detects an intruder, it sends an auditing message to the security operator terminal or the log file to alert you. Using the DCL command SHOW INTRUSION, you can display the source and type of intrusion. For example, Example 7-5 shows a problem with a user named MAPLE who is logging in over the network. The user has tried to log in 8 times. Because the user failed to log in within the monitoring period, the operating system suspended all logins from OMNI:.BOSTON.BIRCH::MAPLE. Table 7-6 gives a more detailed explanation of how the system decides to suspend logins.

Notice that many suspects appear in the display. Sometimes users forget their passwords or type them incorrectly. To remove an entry from the database, use the DCL command DELETE/INTRUSION_RECORD.

$ SHOW INTRUSION

Intrusion       Type       Count         Expiration       Source
   NETWORK      SUSPECT       1   2-Jan-1995 13:20:30.89  PCD025::

Intrusion       Type       Count         Expiration       Source
   NETWORK      SUSPECT       5   2-Jan-1995 13:36:39.42  DENIM::SYSTEM
   NETWORK      SUSPECT       2   2-Jan-1995 13:25:17.30  N1KDO::SYSTEM

Intrusion       Type       Count         Expiration       Source
   NETWORK      SUSPECT       2   2-Jan-1995 13:07:57.95  OMNI:.LOWELL.ASH::TESTER
   NETWORK      INTRUDER      8   2-Jan-1995 11:06:50.51  OMNI:.BOSTON.BIRCH::MAPLE

Intrusion       Type       Count         Expiration       Source
   NETWORK      SUSPECT       2   2-Jan-1995 13:20:10.09  JETTE::TIPH
   NETWORK      SUSPECT       1   2-Jan-1995 13:21:40.75  FTSR::TFREDERICK

Once a login failure occurs, a user becomes a suspect and is monitored for further failures for a period of time. The operating system tolerates only so many login failures by the suspect during this given period of time before it declares the source of login failure to be an intruder. In other words, suspects become intruders by exceeding their allowed chances for login during the monitoring period.

The chance count, set by the system parameter LGI_BRK_LIM, defines how many times a person can try logging in; the standard limit is five times. The chance parameter works in tandem with a time factor controlled by the system parameter LGI_BRK_TMO. At each login failure, the suspect's monitoring period is increased by the value of LGI_BRK_TMO. Thus, with each failure, the suspect is monitored for a longer period of time.

Table 7-6 illustrates a situation where evasive action results when user George fails five times to log in. At each failure, the monitoring period is extended by 5 minutes. On the fifth failure, the operating system labels George an intruder and refuses to log him in. (Notice that the example assumes the parameters LGI_BRK_LIM and LGI_BRK_TMO are both set to 5.)

An intruder can be excluded temporarily or permanently, depending on system settings:

• Temporary exclusion is controlled by the product of LGI_HID_TIM and a random number between 1 and 1.5. At the end of the temporary exclusion period, the subject is reclassified as a suspect. The monitoring period of the suspect is set by the value of LGI_BRK_TMO. For the new monitoring period, the failure count is set to LGI_BRK_LIM, allowing one more chance to log in before the subject is reclassified as an intruder.
• Permanent exclusion results if LGI_BRK_DISUSER is set because this enables the DISUSER flag in a user authorization record when the operating system detects an intrusion.

Enabling the LGI_BRK_DISUSER parameter can have serious consequences because that user name is disabled until you manually intervene. If LGI_BRK_DISUSER is enabled, a malicious user can put all known accounts, including yours, out of service in a short time. To recover, you must log in on the system console where the SYSTEM account is always allowed to log in.

7.5.6.3 System Parameters Controlling Login Attempts

Table 7-7 describes the system parameters controlling login and intrusion detection.

The Security Server process, which is created as part of the normal operating system startup, performs the following tasks:

• Creates and manages the system's intrusion database
• Maintains the network proxy database file (NET$PROXY.DAT)

The system uses the intrusion database to keep track of failed login attempts. This information is scanned during process login to determine if the system should take restrictive measures to prevent access to the system by a suspected intruder. You can display the contents of this database by issuing the DCL command SHOW INTRUSION, as shown in Example 7-5. You can delete information from the database by issuing the DCL command DELETE/INTRUSION.

The network proxy database file (NET$PROXY.DAT) is used during network connection processing to determine if a specific remote user may access a local account without using a password. You can manage the information in this database with the Authorize utility.

This chapter describes how you design user groups and provide users with the identification (UICs, identifiers, privileges) they need to do their work. As part of the discussion, the chapter shows how to assign proper protection codes and ACLs to objects so that the user can work efficiently while, at the same time, system data and resources are properly protected. The chapter assumes you are familiar with the material in Chapter 4 and Chapter 5.

8.1 Designing User Groups

As you design user groups, remember that the groups you establish have an impact on data and resource protection and influence those who receive the GROUP, GRPNAM, and GRPPRV privileges. You may want to map out the functions you expect your users to perform. Look for groups of users involved with a common function, such as accounting, engineering, marketing, and personnel.

Think ahead to future plans in your organization. Incorporate these ideas into your strategy. You can fine-tune the group design at any time, but it is most important to gain a perspective on the logical groupings according to the functions your users perform.

Following are two guidelines for determining the placement of users in UIC groups:

• Sharing: Users who typically share data and control of processes should be arranged in the same group.
• Protection: Users who should not have access to each other's data or control each other's processes should be assigned to separate groups.

However, there are limitations to UIC group design. You may want to give only a few members of your UIC group access to files that you own, or you may want to grant access to your files to members of several UIC groups without having to grant world access. These limitations are described in Section 8.1.2.

8.1.1 Example of UIC Group Design

The fictitious Rainbow Paint Company is a distribution company with five departments: executive, accounting, marketing, shipping, and administration. Table 8-1 identifies the employees in the various departments who need computer resources. The table also lists the job responsibilities of the employees.

The fact that the company has been organized into departments suggests that individuals in the same department perform many of the same functions. For example, the advantage of grouping all the employees who perform bookkeeping tasks for the company in the accounting department is that employees can easily communicate with one another and gain access to the data they must share.

As the system manager of Rainbow Paint's computer resources, Olivia Westwood will set up UIC groups based on the existing organizational structure. For example, the employees in the accounting department (Ruiz, Smith, Jacobs, and Crandall) could be members of the UIC group ACCOUNTING. Setting up the UIC group in this way ensures that user Ruiz has easy access to data from user Smith, and so on.

Effective department organization ensures that only selected employees will have access to all data and employees in the company. For example, one of the functions of the accounting department concerns payroll. Because payroll information is confidential, employees in the shipping and marketing departments should not have access to that information.

As the system manager of Rainbow Paint's computer resources, Westwood sets up the UIC groups---ACCOUNTING, EXECUTIVE, MARKETING, SHIPPING, and ADMINISTRATION---corresponding to the various departments in the company. Members of a UIC group can be given common access to files, as shown in the following example:

$ SET SECURITY/PROTECTION=G:RWE GROUP_STATS.DAT

With this command, the owner of the file GROUP_STATS.DAT allows each member of the UIC group read, write, and execute access to the file.

8.1.2 Limitations to UIC Group Design

In some cases, UIC-based protection does not present the best solution to your object protection needs. If users in several UIC groups need access to common files and other resources on the system, the only UIC-based alternatives are to give world access to the object (all users can access the object) or to grant extended privileges to each user. Neither choice is desirable.

You may also need to allow users in a UIC group several types of access to files; you may want to deny access to the object to some users in the same group. Again, UIC-based protection does not offer a good solution to meet these needs.

Access control lists (ACLs), described in the following sections, offer another way to protect files and other objects on the system.

As the site security administrator, it is extremely important to familiarize yourself with the subtleties of the UIC categories, as described in Section 4.5. Putting users in certain UIC groups may grant them system privileges, and a user with system privilege has control access to any protected object on the system. The SYSPRV privilege is given by default to all UIC groups less than or equal to 10, but the actual range for the system UIC category is determined by the value of the MAXSYSGROUP system parameter. Putting users with the GRPPRV privilege in groups that own system files might also cause security problems.