Updated: 11 December 1998 |
OpenVMS Guide to System Security
Previous | Contents | Index |
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.)
Time of Login Failure | Failure Count | Extension of Monitoring Period |
---|---|---|
6:00 | 0 | George fails to log in, and the system starts to monitor logins from George's terminal. It monitors for the next 5 minutes. |
6:00:30 | 1 | Thirty seconds later, with 4.5 minutes left in the monitoring period, George fails again. The monitoring period is extended by 5 minutes. Thus, the system monitors George for login failures during the next 9.5 minutes. |
6:01 | 2 | Thirty seconds later, 9 minutes remain in his monitoring period, and the system extends it by 5 minutes. |
6:02 | 3 | One minute later, George has 13 minutes in his monitoring period, and the system extends it by 5 minutes. |
6:02:30 | 4 | Thirty seconds later, George has 17.5 minutes in the monitoring perod, and the system extends it by 5 minutes. Thus, the system monitors George for login failures during the next 22.5 minutes. |
6:04:30 | 5 | Two minutes later, George makes a sixth attempt. Even though the monitoring period allows the time, he runs out of chances. He becomes an intruder and can no longer access the system. |
An intruder can be excluded temporarily or permanently, depending on system settings:
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.
If You Want to Control... | Set the Parameter | Description |
---|---|---|
Login time period | LGI_PWD_TMO |
Allows time to:
|
Number of times a person can try to log in over a phone line or network connection | LGI_RETRY_LIM | As long as the retry time (LGI_RETRY_TMO) allows, a person can retry the login sequence without losing the phone connection or network link. Someone can reconnect and reattempt login as long as the break-in limit (LGI_BRK_LIM) has not been exceeded during the monitoring period. |
Interval between login attempts over phone lines or network connection | LGI_RETRY_TMO | Specifies the number of seconds allowed between login attempts after a login failure. If there is no user response after a login failure for LGI_RETRY_TMO seconds, LOGINOUT disconnects the session. |
Number of login chances | LGI_BRK_LIM | Number of login failures during the monitoring period that triggers evasive action. The failure count applies independently to login attempts by each user name, terminal, and node. |
Length of failure monitoring period | LGI_BRK_TMO | Time increment added to the suspect's expiration time each time a login failure occurs. Once the expiration period passes, prior failures are discarded, and the subject is given a clean slate. |
Association of user name and terminal name in intrusion database source name | LGI_BRK_TERM | Controls whether failures from terminal class logins are counted by terminal, by user (the default), or by user across all terminals. If LAT or another terminal switch is in use, set the parameter to 0 to log failures by user name only. |
Duration of login denial | LGI_HID_TIM | Value of this parameter times a random number (between 1 and 1.5) determines the actual length of evasive action when the failure count has exceeded LGI_BRK_LIM. |
Disable intruder's account | LGI_BRK_DISUSER | Enables the DISUSER flag in user's authorization record, permanently locking out that account. |
The Security Server process, which is created as part of the normal operating system startup, performs the following tasks:
The intrusion database is used by the system 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 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:
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.
Department | Employee | Function |
---|---|---|
Executive | Samuel Gibson | President |
Olivia Westwood |
Treasurer
Head of Computer Operations |
|
Accounting | Carlo Ruiz | Payroll |
Rich Smith | Bookkeeping | |
Rod Jacobs | Clerk | |
Ruth Crandall | Clerk | |
Marketing | Jason Chang | Forecasting |
Alana Mack | Sales Reporting | |
Shipping | Scott Giles | Inventory Control |
Administration | Jane Simon |
Correspondence Management
Paycheck Printing |
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.
8.2 Naming Individual Users in ACLs
Rather than attempting to restructure UIC groups to solve data and resource protection problems, you may be able to achieve your goals by using access control lists (ACLs). ( Section 4.4 provides a detailed description of ACLs.) The UIC can serve as an identifier in an ACE, so you can easily construct ACLs that allow specific users across various UIC groups access to an object.
For example, consider the ACL that you might construct to allow specific users from the Rainbow Paint Company to access the file PAYROLL.DAT:
(IDENTIFIER=OWESTWOOD,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=CRUIZ,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=RSMITH,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=JSIMON,ACCESS=READ) (IDENTIFIER=SGIBSON,ACCESS=READ) |
Many users often share the same access needs, and an ACL consisting strictly of UIC identifiers can become too lengthy. To shorten the ACL, you can include environmental identifiers, which are system-defined, or create general identifiers (see Table 4-1).
When creating general identifiers, you design the names of the identifiers you want on your system and compose the set of holders for the identifiers. Then you add the identifiers to the rights database and assign the identifiers to the intended users.
For example, the Rainbow Paint Company decided to add the identifier PAYROLL to the rights database. The holders of that identifier were all users who needed read, write, execute, and delete access to PAYROLL.DAT: OWESTWOOD, CRUIZ, and RSMITH.
Once the identifier and its holders were defined, the security administrator used the following ACL to specify the same type of access to PAYROLL.DAT:
(IDENTIFIER=PAYROLL,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=JSIMON,ACCESS=READ) (IDENTIFIER=SGIBSON,ACCESS=READ) |
A final step in designing ACLs and identifiers is to consider how and when different identifiers are going to be used. Users often need to hold an identifier for different reasons, such as updating databases or performing system operations. For this reason, you may want to qualify the use of an identifier.
There are several ways to qualify identifiers. One way is to use environmental identifiers, and another is to add special attributes to identifiers, as described in Section 8.6.7.
Environmental identifiers describe different types of users based on their initial entry into the system. These identifiers---local, dialup, remote, interactive, network, and batch---let you define a large potential group of users according to their use of the system. Typically, these types of identifiers are used in combination with other identifiers.
For example, the following ACE permits user Martin to have read, write, execute, and delete access to the object only when logged in from a local terminal:
(IDENTIFIER=MARTIN+LOCAL,ACCESS=READ+WRITE+EXECUTE+DELETE) |
You can use the environmental identifiers in ACLs to deny access to an entire class of logins. For example, the following ACE denies access to all dialup users:
(IDENTIFIER=DIALUP,ACCESS=NONE) |
In assigning these environmental identifiers to users in a DECwindows
environment, remember that DECwindows processes can be virtually any
type of process. For example, a user may choose to run DECwindows Mail
in a batch job. Even though the process is communicating interactively
with a user through a DECwindows workstation, it is still classified as
a batch job.
8.5 Designing ACLs
There are several factors to consider when designing ACLs:
ACLs become too long (for example, more than 200 entries or so),
you might consider grouping users into discrete categories and creating
general identifiers.
For more information on defining identifiers, see Section 8.6 and the
the description of AUTHORIZE in the OpenVMS System Management Utilities Reference Manual. For more information
about creating and maintaining ACLs, see Chapter 4. For extensive
work, using the access control list editor (ACL editor) is appropriate;
the ACL editor is described in the OpenVMS System Management Utilities Reference Manual.
8.6 Populating the Rights Database
Once you have designed the names of the identifiers you want on your system and composed the set of holders for the identifiers, use AUTHORIZE to add the identifiers to the rights database and assign the identifiers to the intended users. These associations are kept in the rights database (RIGHTSLIST.DAT), which you maintain as you add or remove users and identifiers.
Initially, the rights database is created at system installation and is located in the [SYSEXE] directory. At creation, it contains the names of the environmental identifiers. As you add users to the authorization file, one identifier is added for each authorized user. The identifier, called a UIC identifier, is associated with the user's UIC and user name.
There is also an identifier in the rights database equivalent to each UIC group name. When you add a new user as the first member of a new UIC group and you specify an account group name with the user, an identifier corresponding to the account group name is added to the rights database, as shown in the following example:
$ SET DEFAULT SYS$SYSTEM $ RUN AUTHORIZE UAF> ADD ROB/PASSWORD=SP0152/UIC=[014,006] - _UAF> /DIRECTORY=WORK:[ROB]/ACCOUNT=MGMT UAF-I-ADDMSG, user record successfully added UAF-I-RDBADDMSGU, identifier ROB value: [000014,000006] added to RIGHTSLIST.DAT UAF-I-RDBADDMSGU, identifier MGMT value: [000014,177777] added to RIGHTSLIST.DAT |
Because the account name MGMT is specified when adding ROB's account and no UIC group of that name exists, the MGMT identifier is added to the rights database.
Each site adapts its own rights database according to actual use and needs.
Note that when you use AUTHORIZE to add, remove, or change user names in the system user authorization file (SYSUAF.DAT), AUTHORIZE makes corresponding changes for you in RIGHTSLIST.DAT so that the rights list corresponds to SYSUAF.DAT.
Because of the automatic creation and maintenance of the rights database, you seldom need to use the AUTHORIZE command CREATE/RIGHTS. However, if the rights database is damaged or deleted, you can create a new one with this command. (See the OpenVMS System Management Utilities Reference Manual for more information.)
Previous | Next | Contents | Index |
Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal |
6346PRO_017.HTML
|