HP OpenVMS Guide to System Security: OpenVMS Version 8.4 > Chapter 7 Managing System Access
This section describes how you can control the display of various pieces of information that appear by default at login time, such as announcement, welcome, last login, and new mail messages. So that you can understand the effect of login restrictions, it also describes how the operating system processes the login fields of the system user authorization file (SYSUAF.DAT). In addition, this section describes the use of the secure server and how to set up intrusion detection.
To provide an announcement message on your system, define the system logical name SYS$ANNOUNCE in the site-specific startup command procedure SYS$MANAGER:SYSTARTUP_VMS.COM. The HP OpenVMS System Manager's Manual describes how to do this. The announcement message appears at login.
Similar to the announcement message, the welcome message is controlled through a system logical name, SYS$WELCOME. If you do not define SYS$WELCOME, a standard welcome message is provided for all users. This welcome message reveals the operating system and version number, as well as the node if SYS$NODE is defined.
By default, the system displays three messages that provide information about the last logins and the number of failed login attempts (see “Reading Informational Messages”"Reading Informational Messages" on page 45 ). You can selectively disable the appearance of these three messages. Enter the AUTHORIZE qualifier /FLAGS=DISREPORT for specific users.
The new mail announcement is primarily a user convenience, not a security issue. If a user with a restricted account cannot invoke the Mail utility (MAIL), then you might want to disable the new mail message at the same time you prohibit mail access. The following AUTHORIZE qualifier accomplishes both tasks:
Virtual terminals let users maintain more than one disconnected process at a time. Virtual terminals are also required by the secure server feature (see “Using the Secure Server”). You may want to restrict the use of virtual terminals. For example, if you are concerned about the amount of nonpaged pool, you may not want to enable this feature on a systemwide basis.
You can also set the amount of time allowed for reconnection to less than the default of 15 minutes with the system parameter TTY_TIMEOUT. A process that remains disconnected for longer than the timeout value is automatically logged out by the system. Limiting the connection time tends to minimize the number of users who receive messages, but it also affects the usefulness of the connection feature.
You can assign accounts to particular terminals to enable an automatic login feature (see “Automatic Login Accounts”). This feature permits users to log in without specifying a user name. The operating system associates the user name with the terminal (or terminal server port) and maintains these assignments in the file SYS$SYSTEM:SYSALF.DAT, referred to as the automatic login file or the ALF file. Maintain this file with the following System Management utility (SYSMAN) commands:
The ALF file consists of one record for each terminal on which automatic logins are enabled. Each record consists of two fields: the device name or terminal server port name of the terminal, followed by the user name of an account. The device names must be unique within the file. However, the same user name can occur in any number of records; that is, one account can be automatically logged in to an unlimited number of terminals.
“Guidelines for Protecting Your Password”"Guidelines for Protecting Your Password" on page 53 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.
SET TERMINAL/PERMANENT/SECURE/DISCONNECT term-id
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:
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.
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.
The DCL command SHOW INTRUSION displays the contents of the intrusion database; “Intrusion Database Display” 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, “Intrusion Database Display” 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. “Intrusion Example” gives a more detailed explanation of how the system decides to suspend logins.
Example 7-5 Intrusion Database Display
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.
“Intrusion Example” 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.)
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.
“Parameters for Controlling Login Attempts” describes the system parameters controlling login and intrusion detection.
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 “Intrusion Database Display”. 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.