HP OpenVMS Systems Documentation

This section describes some common BACKUP errors and how to recover from them.

11.19.1 BACKUP Fatal Error Options

If, in the course of a backup operation, the Backup utility or standalone BACKUP encounters fatal hardware- or media-related errors or encounters more media errors than considered reasonable for data reliability, BACKUP generates the following informational message and prompt:

%BACKUP-I-SPECIFY, specify option (CONTINUE, RESTART, QUIT)
BACKUP>

The option you choose depends on several factors, as explained in Table 11-9.

The following example illustrates the sequence of events that occurs when BACKUP encounters an excessive rate of media errors on VOL3 and you choose the RESTART option:

1. BACKUP indicates that the magnetic tape has an excessive number of media errors and displays the following error message and prompt:

   %BACKUP-F-WRITEERRS, excessive error rate writing VOL3 %BACKUP-I-SPECIFY, specify option (CONTINUE, RESTART, QUIT) BACKUP>

2. Enter RESTART.
3. BACKUP dismounts VOL3 and prompts for a new tape. Remove VOL3 from the drive and discard this tape.
4. Place a new tape into the drive and enter YES in response to the prompt for a new tape.
5. BACKUP restarts the save operation from the beginning of VOL3; no data is lost.

When you instruct BACKUP to use a tape that has a label other than the one you specified, BACKUP issues the following message:

%MOUNT-I-MOUNTED, DKA0 mounted on _SODAK$MUA0:
%BACKUP-W-MOUNTERR, volume 1 on _SODAK$MUA0 was not mounted because
its label does not match the one requested
%BACKUP-W-EXLABEER, volume label processing failed because
 volume TAPE4 is out of order, Volume label TAPE1 was expected
 specify option (QUIT, NEW tape, OVERWRITE tape, USE loaded tape)
BACKUP>

Depending on the option you specify, you can quit the backup operation (QUIT), dismount the old tape and mount a new one (NEW), overwrite the data on the tape (OVERWRITE), or USE the loaded tape.

If you use blank tapes or tapes that you intend to overwrite, use the /IGNORE=LABEL_PROCESSING qualifier. This suppresses the previous BACKUP message, which normally occurs if BACKUP encounters a non-ANSI-labeled tape during a save operation.

This chapter outlines the security features available with the OpenVMS operating system and suggests procedures to reduce the threat of a break-in on your system or cluster. It also tells how to use the access control list editor (ACL editor) to create and modify access control list entries (ACEs) on protected objects. For a more detailed description of security management, refer to the OpenVMS Guide to System Security.

Information Provided in This Chapter

This chapter describes the following tasks:

This chapter explains the following concepts:

For full descriptions of all these tasks and concepts, refer to the OpenVMS Guide to System Security.

12.1 Understanding Security Management

As the person responsible for the day-to-day system management, you play an important role in ensuring the security of your system. Therefore, you should familiarize yourself with the security features available with the OpenVMS operating system and implement the features needed to protect systems, users, and files from damage caused by tampering. Effective operating system security measures help prevent unauthorized access and theft of proprietary software, software plans, and computer time. These measures can also protect equipment, software, and files from damage caused by tampering.

Types of Security Problems

Security problems on most systems are generally caused by irresponsibility, probing, or penetration. The tolerance that your site might have to a breach of security depends on the type of work that takes place at your site.

Environmental Considerations

A secure system environment is a key to system security. Compaq strongly encourages you to stress environmental considerations when reviewing site security.

Operating System Protections

In the OpenVMS operating system, managing system security is concerned with three major areas:

• Controlling access to the system; for example, interactively, through batch processing jobs, or over the network
• Controlling access to information and resources that are kept on the system; for example, files, application programs, or system utilities
• Managing the auditing system so security-relevant events are logged, the log file is reviewed on a regular basis, and the log is kept to a reasonable size

The following sections describe measures to control access to your system and its resources.

12.2 Managing Passwords

A site needing average security protection always requires the use of passwords. Sites with more security needs frequently require generated passwords and system passwords. Highly secure sites sometimes choose to use secondary passwords to control network access.

For information about external authentication (also known as single sign-on), refer to the Authorize section in the OpenVMS System Management Utilities Reference Manual and the Managing System Access section in the OpenVMS Guide to System Security.

12.2.1 Initial Passwords

When you open an account for a new user with the Authorize utility, you must give the user a user name and an initial password. When you assign temporary initial passwords, observe all guidelines recommended in Section 12.2.5. You should consider using the automatic password generator. Avoid any obvious pattern when assigning passwords.

Using the Automatic Password Generator

To use the automatic password generator while using the Authorize utility to open an account, add the /GENERATE_PASSWORD qualifier to either the ADD or the COPY command. The system responds by offering you a list of automatically generated password choices. Select one of these passwords, and continue setting up the account.

Using the System Dictionary and the Password History List

The OpenVMS operating system automatically compares new passwords with a system dictionary to ensure that a password is not a native language word. It also maintains a password history list of a user's last 60 passwords. The operating system compares each new password with entries in the password history list to ensure that an old password is not reused.

The system dictionary is located in SYS$LIBRARY. You can enable or disable the dictionary search by specifying the DISPWDDIC or NODISPWDDIC option with the /FLAGS qualifier in AUTHORIZE. The password history list is located in SYS$SYSTEM. To enable or disable the history search, specify the DISPWDHIS or NODISPWDHIS option to the /FLAGS qualifier.

Adding to the System Password Dictionary

You can modify the system password dictionary to include words of significance to your site. The following procedure allows you to add words to the system dictionary. The procedure also allows you to retain a file of the passwords that you consider unacceptable.

1. Create a file containing passwords you want to add to the dictionary. Each password should be on a separate line and in lowercase, as follows:

   $ CREATE LOCAL_PASSWORD_DICTIONARY.DATA somefamous localheroes [Ctrl/Z]

2. Enable SYSPRV and merge your local additions:

   $ SET PROCESS/PRIVILEGE=SYSPRV $ CONVERT/MERGE/PAD LOCAL_PASSWORD_DICTIONARY.DATA - _$ SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA

Defining Preexpired Passwords

When you add a new user to the UAF, you might want to define that user's password as having expired previously using the AUTHORIZE qualifier /PWDEXPIRED. This forces the user to change the initial password when first logging in.

Preexpired passwords are conspicuous in the UAF record listing. The entry for the date of the last password change carries the following notation:

By default, the OpenVMS operating system forces new users to change their passwords the first time they log in. Encourage your site to use a training program for its users that includes information about changing passwords.

12.2.2 System Passwords

System passwords control access to terminals that might be targets for unauthorized use, as follows:

• All terminals using dialup lines or public data networks for access
• Terminals on lines that are publicly accessible and not tightly secured, such as those at computer laboratories at universities
• Terminals the security manager wants to reserve for security operations

Implementing system passwords is a two-stage operation involving the DCL commands SET TERMINAL and SET PASSWORD. First, you must decide which terminals require system passwords. Then, for each terminal, you enter the DCL command SET TERMINAL/SYSPASSWORD/PERMANENT. To enable system passwords for all terminals, set the appropriate bit in the system parameter TTY$DEFCHAR2.

12.2.3 Primary and Secondary Passwords

The use of dual passwords is cumbersome and mainly needed at sites with high-level security concerns. The effectiveness of a secondary passwords depends entirely on the trustworthiness of the supervisor who supplies it. A supervisor can easily give out the password or worse yet, change it to a null string.

The main advantage of a second password is that it prevents accounts from being accessed through DECnet for OpenVMS using simple access control.

Another advantage of a second password is that it can serve as a detection tool when a site has unexplained break-ins after the password has been changed and the use of the password generator has been enforced. Select problem accounts, and make them a temporary target of this restriction. If the problem goes away when you institute personal verification through the secondary password, you know you have a personnel problem. Most likely, the authorized user is revealing the password for the account to one or more other users who are abusing the account. Refer to the OpenVMS Guide to System Security for an explanation of how to add secondary passwords.

12.2.4 Enforcing Minimum Password Standards

Security managers can use AUTHORIZE to impose minimum password standards for individual users. Specifically, qualifiers and login flags provided by AUTHORIZE control the minimum password length, how soon passwords expire, and whether the user is forced to change passwords at expiration.

Password Expiration

With the AUTHORIZE qualifier /PWDLIFETIME, you can establish the maximum length of time that can elapse between password changes before the user will be forced to change the password or lose access to the account.

The use of a password lifetime forces the user to change the password regularly. The lifetime can be different for different users. Users who have access to critical files generally should have the shortest password lifetimes.

Forcing Expired Password Changes

By default, users are forced to change expired passwords when logging in. Users whose passwords have expired are prompted for new passwords at login. A password is valid for 90 days unless a site modifies the value with the /PWDLIFETIME qualifier.

Minimum Password Length

With the AUTHORIZE qualifier /PWDMINIMUM, you can direct that all password choices must be a minimum number of characters in length. Users can still specify passwords up to the maximum length of 32 characters.

Requiring the Password Generator

The /FLAGS=GENPWD qualifier in AUTHORIZE allows you to force the use of the automatic password generator when a user changes a password. At some sites, all accounts are created with this qualifier. At other sites, the security manager can be more selective.

12.2.5 Guidelines for Protecting Passwords

Observe the following guidelines to protect passwords:

• Make certain the password for the SYSTEM account, which is a standard account on all OpenVMS systems, is secure and is changed regularly.
• Disable any accounts that are not used regularly with the AUTHORIZE qualifier /FLAGS=DISUSER (for example, SYSTEST and FIELD).
• Do not permit an outside or an in-house service organization to choose the password for an account they use to service your system. Such service groups tend to use the same password on all systems, and their accounts are usually privileged. On seldom-used accounts, set the AUTHORIZE flag DISUSER, and enable the account only when it is needed. You can also change the password immediately after each use and notify the service group of the new password.
• Set appropriate account expiration dates, especially when you know a user has only short-term requirements for an account.
• Delete accounts no longer in use.
• If you have an account on a system that stores passwords in plaintext (unencrypted), choose a different password on all of your accounts on other machines. Passwords should not even be shared between machines that encrypt the password. A compromised machine can be used to read plaintext on its way into the machine, thereby gaining access to the other machine.
• Do not leave listings of operator logs, accounting logs, or audit logs where they could be read or stolen.
• Maintain adequate protection of authorization files. Note that the system user authorization file (SYSUAF.DAT) and network proxy authorization file (NETPROXY.DAT) are owned by the system account ([SYSTEM]). There should be no other users in this group. Accordingly, the categories SYSTEM, OWNER, and GROUP are synonymous. Normally the default UIC-based file protection for these authorization files is adequate.

The following actions are not strictly for password protection, but they reduce the potential of password detection or limit the extent of the damage if passwords are discovered or bypassed:

• Avoid giving multiple users access to the same account.
• Separate users into distinct user groups.
• Protect telephone numbers for dialup lines connected to your system.
• Make all accounts that do not require a password captive accounts.
• Extend privileges to users carefully.
• Ensure that the files containing components of the operating system are adequately protected.

The password history database maintains a history of previous passwords associated with each user account. By default, the system retains these records for one year. Password history records that are older than the system password history lifetime are allowed as valid password choices. When a user account is deleted, the system removes the associated password history records from the history database.

12.3 Using Intrusion Detection Mechanisms

This section describes how to set up intrusion detection and evasion and how to display the intrusion database.

Controlling the Number of Retries on Dialups

You can control the number of login attempts the user is allowed through a dialup line. If the user makes a typing mistake after obtaining the connection, the user does not automatically lose the connection. This option is useful for authorized users, while still restricting the number of unauthorized attempts.

To implement control of retries, use the following two LGI system parameters: LGI_RETRY_TMO and LGI_RETRY_LIM. If you do not change the values of these system parameters, the default values allow the users three retries with a 20-second interval between each.

Keep in mind that controlling dialup retries is only a part of an overall security program and is not, in itself, sufficient to avoid break-ins. An obstacle like redialing is not going to prove an effective deterrent to a persistent intruder.

Discouraging Break-In Attempts Further

The OpenVMS operating system offers additional methods of discouraging break-in attempts. These methods also use system parameters in the LGI category.

Refer to the OpenVMS Guide to System Security for a full description of these parameters.

Displaying the Intrusion Database

The Security Server process, which is created as part of 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 intrusion database keeps 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.

Use the DCL command SHOW INTRUSION to display the contents of the intrusion database. Use the DCL command DELETE/INTRUSION_RECORD to remove entries from the intrusion database.

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. The information contained in this database is managed by the Authorize utility.

The following example shows the expanded expiration time field in the new SHOW INTRUSION output.

$ SHOW INTRUSION
Intrusion       Type       Count        Expiration         Source
   NETWORK      SUSPECT       1   21-MAY-2000 12:41:01.07  DEC:.ZKO.TIDY::SYSTEM