This section describes many operating system features
designed to secure systems from unauthorized users.
Informational Display During Login
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
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.
The definition you provide here affects all users
on the system. Because this message may provide a clue to the identity
of the operating system, you may decide not to display it.
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.
To define another message for SYS$WELCOME, you
can create a text file containing the message. To display the contents
of this file, use the following line in SYSTARTUP_VMS.COM:
To disable the welcome message, place the following
DCL command in SYS$MANAGER:SYSTARTUP_VMS.COM. This command prints
a blank line in place of the standard welcome message.
$DEFINE/SYSTEM SYS$WELCOME " "
If you prefer to selectively disable the message
for individual users, you can use the AUTHORIZE qualifier /FLAGS=DISWELCOME
on individual UAF records.
Last Login Messages
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.
New Mail Announcements
By default, the system tells users the number
of new mail messages when they log in. You can prevent users from
receiving this notice by specifying the AUTHORIZE qualifier /FLAGS=DISNEWMAIL.
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:
Limiting Disconnected Processes
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.
Virtual terminals can be disabled at the terminal,
user, or system level:
To prevent particular
terminals from being used as virtual terminals, use the DCL command
To prevent specific users
from attaching to disconnected processes, set the AUTHORIZE qualifier
/FLAGS=DISRECONNECT for those users. (An applications account used
by multiple users is a good candidate for the DISRECONNECT flag to
prevent the users from connecting to each other's processes.)
To disable virtual terminals
on a systemwide basis, remove the DISCONNECT attribute from the system
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
For more information on setting up and reconnecting to
virtual terminals, see the HP OpenVMS System Manager's
Providing Automatic Login
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:
terminal/user name association
ALF ADD TTA5 RENOLDS
terminal server/user name association
records in ALF file
ALF SHOW TTA5 ALF SHOW /USERNAME=PONTRE
ALF REMOVE TTA3
ALF REMOVE /USERNAME=DOUGLAS
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.
The ALF file is an indexed file that does not
need to be purged, but it should be backed up after a modification.
Using the Secure Server
“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.
Invoke the secure server separately for each terminal
with the following DCL command:
SET TERMINAL/PERMANENT/SECURE/DISCONNECT term-id
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
For local terminals (direct-wired),
use the following SET TERMINAL qualifiers:
For switched terminals
(data-switch and dialup), use the following SET TERMINAL qualifiers:
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
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.
Understanding the Intrusion Database
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:
source of failure:
Network: failure originating from a remote node, using
a valid user name
Terminal: failure originating from one terminal
Term_User: failure originating from one terminal,
using a valid user name
Username: failure attempting to create a detached
Severity of login failure:
The system parameters for threshold count (LGI_BRK_LIM)
and monitoring period (LGI_BRK_TMO) define when a suspect becomes
Number of login failures
associated with a particular source.
Date and time when a
suspect's record is deleted or when an intruder is allowed another
chance to log in. When an intruder's record reaches its expiration
time, it becomes a suspect, and the failure count is reset to LGI_BRK_LIM.
The expiration time is reset to the old expiration plus LGI_BRK_TMO.
Origin of the login failure:
Node and user name if Network class
Terminal if Terminal class
Terminal and user name if Term_User class
User name if Username class
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.
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.
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
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.)
Table 7-6 Intrusion Example
Time of Login Failure
Extension of Monitoring Period
George fails to log in, and the
system starts to monitor logins from George's terminal. It monitors
for the next 5 minutes.
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.
Thirty seconds later, 9 minutes
remain in his monitoring period, and the system extends it by 5 minutes.
One minute later, George has 13
minutes in his monitoring period, and the system extends it by 5 minutes.
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.
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.
Setting the Exclusion Period
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.
Table 7-7 Parameters for Controlling Login Attempts
If You Want to Control...
Set the Parameter
Allows time to:
Enter the correct system password (if used).
Enter personal account passwords.
Enter the old password, enter a new password, and
verify it when using the SET PASSWORD command.
of times a person can try to log in over a phone line or network connection
Allows a person to retry the login
sequence without losing the phone connection or network link as long
as the retry time (LGI_RETRY_TMO) allows. Someone can reconnect and
reattempt login as long as the break-in limit (LGI_BRK_LIM) has not
been exceeded during the monitoring period.
between login attempts over phone lines or network connection
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.
of login chances
the 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.
of failure monitoring period
the 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.
of user name and terminal name in intrusion database source name
Controls whether failures from terminal class logins
are counted by terminal, by user (the default), or by user across
all terminals. LAT is tracked back to the originating port based on
the contents of the TT_ACCPORNAM field.
of login denial
the duration of login denial. The 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.
Enables the DISUSER flag in user's
authorization record, permanently locking out that account.
Security Server Process
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 “Intrusion Database Display”. You can delete information from the database by issuing the DCL
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.