CXL Securing your mid-range systems.

CXL - Securing your mid-range systems.

DEC VAX/VMS Operating System Security Review

Following was contributed to AuditNet LLC by Rey LeClerc rey@mass-usa.net

Objectives:

(1) Perform a limited review of the DEC VAX/VMS operating system to assess the adequacy of control.

(2) Determine the potential impact of identified concerns on the system of internal control.

General VAX Information and Security

A. How VMS security determines access

The following are the steps VMS uses to determine if a user is allowed access to a particular object (files, directories).

Access Control Lists (ACLs) are always evaluated first. ACLs are a group of entries in the rights database specifying access attributes. Each entry in the access control list is known as an access control entry. These can be defined for files, directories, or physical devices (e.g., disk drives).

If an ACL fails to apply to the access request, then User Identification Codes (UIC) -based protection is checked. UIC are either alphabetic or numeric codes that are assigned to users and objects within the VAX/VMS environment. Each user of the system has a UIC defined in the User Authorization File (UAF).

Each system object also has an associated owner UIC and a protection code that defines who is allowed what type of access.

The user requesting access to the resource is related to the resource by one of the user categories (system, owner, group, and world).

The user is granted or denied access according to the protection specified for the user category that the user requesting access and the resource are related by.

When an ACL specifically denied access, the user still may acquire access by belonging to the system or owner categories and being eligible for access through them or by possessing privileges.

Users who possess certain privileges, i.e. system or owner, may be entitled to access regardless of the protection offered by the ACL or the protection.

Magnetic tapes volumes are only protected at the volume level. Regardless of the protection specified for tape volumes, the system and owner categories always have access.

B. Access Control Lists (ACL)

ACLs operate in conjunction with the UIC-based protection to restrict access in very specific ways. ACLs may be created by the system default, by the security manager for specific objects, and by users to protect their own files. However, a user cannot create or change an ACL unless he owns the associated object, or can obtain the same access as the owner. ACLs are used to control access to files, queues and devices.

ACLS are based on identifiers. In the rights database (RIGHTS.DAT) there is a file associating users with special names, called identifiers, which they are allowed to hold. An identifier may represent a user's username and UIC, or it may represent a more general name held by many users (for group users).

There are three types of identifiers:

UIC identifiers, which depends on the user identification codes (UICs) that uniquely identify each user on the system.

General identifiers, which are defined by the security manager in the system rights database to identify the security manager in the system rights database to identify groups of users in the system.

System-defined identifiers, which describe certain types of users based on their use of the system.

When you login, the identifiers you hold in the rights database are copied into a rights list that is part of your login process. VMS uses the rights lists to perform all protection checks. Additional identifiers may be added to your rights list either by the VMS login software or by software specific to your location.

The security manager decides what kinds of access to specific objects should be granted to holders of each identifier. Often there are many identifiers attach to an object, and there may be access control lists with many entries created. Each entry defines the group of access rights to be granted or denied to the holders of the identifiers named in that entry. The list of entries is the ACL, and each entry is known as an Access Control List Entry (ACE).

There are three types of ACE as follows:

An identifier ACE controls the type of access granted to a particular user or group of users.

A default protection ACE defines the default protection for a directory so that the protection can be propagated to the files and subdirectories created in that directory.

A security alarm ACE provides an alarm message when an object is accessed in a designated way.

Note that an identifier ACE may be UIC-based, general or system-defined (batch, network, interactive, local, dialup, and remote). Also note that the stem stops searching at the first match, which means that a matchup occurring further down the line has no effect. It is crucial, therefore, to make sure that ACEs identifying specific users should appear before ACEs identifying groups.

ACLs can be used to monitor the system, e.g. used with security auditor, to send alarm when an object is accessed, and to initiate an alarm that generates a security record in the security log.

C. UIC-Based Protection

Upon creation of an account on the system, the user of the account is associated with a UIC. A UIC may be either numeric or alphanumeric. In the numeric format, the UIC consists of a group number and a member number. An alphanumeric UIC consists of a member name and an optional group name.

Regardless of the format, the system translate the UIC into a 32-bit value representing a group number and a member number. The 32-bit numeric UIC is stored in the system rights database. The system rights database is a file containing information pertaining to the access rights and attributes associated with identifiers and holders of those identifiers.

When a user attempts to access any object, the system usually compares the user's UIC with that of the object. The only exception to this generalization is when the object is protected by an ACL that immediately grants the user access.

Upon requesting access to a given object, VMS compares the user's UIC to that of the object. It then determines what category the user belongs to. For example:

* SYSTEM

All users who have access to the system privilege (SYSPRV).

Users with low group numbers (usually system managers, system programmers, and operators).

Users with the privileges GRPPRV whose UIC group matches the group of the object's owner.

For files on disk volumes, users whose UIC matches the owner UIC of the volume on which the file is located.

- OWNER The users with the same UIC as the owner who created the object.

- GROUP All users, including the owner, who have the same group number in their UICs as the object's owner.

- WORLD All users defines to the system.

Each category of users can be further controlled (access allowed or denied) via access protection codes or RWED access. Specifically:

* R(READ) Provides the right to examine (read), print, or copy the file.

* W(WRITE) Provides the right to or modify the file).

* E(EXECUTE) Provides the right to execute a file that contains an executable program image or DCL command procedure.

* D(DELETE) Provides the right to delete the file.

Note that control is omitted because this is never specified in the standards UIC-based protection code. However, it can be specified in an ACL and is automatically granted to certain user categories which UIC-based protection is evaluated. CONTROL access grants the user all the privileges of the objects actual owner, and allows the user to change the protection and file characteristics.

D. Digital Network Security

VMS and DECnet-VAX provides several mechanisms for establishing a correspondence between a subject or process on a source node and another on a target node. Access to and from a subject node and a target node can be established via the following facilities:

* An explicit entry in the UAF (User Authorization File). This approach requires that an explicit username and password be provided upon establishing a connection on the targeted node. This mechanism restricts access to those objects accessible to the named user/UIC, but, it has the undesirable effect of broadcasting passwords over the network.

* Proxy Account. This option requires the target reference monitor to maintain a table of source subjects and corresponding local user names. The advantages of a proxy account is twofold:

* There is no need to embed passwords in commands.

* File protection code need not be set to allow the world category of users read access to transfer a file.

Note that there are two utilities are used to set up proxy logins: Authorize and NCP (Network Control Program). The following security considerations should be evaluated when using PROXY accounts:

* Proxy accounts should be restricted so that they prohibit interactive users and batch jobs, which is to they should permit only network logins.

* Avoid granting privileges to proxy login accounts.

* Default protection on the directory should be properly customized to the particular user's need.

* Command procedures used at login time should reside in well-protected directory owned by a user other than the owner of the proxy account. It should also prohibit write access for those who use the account.

* DECnet-VAX Account. This option permits certain types of access to the system from remote nodes without requiring account and password information. Instead, this information is specified in the DECnet-VAX executor and object databases. These accounts are controlled through the system authorization file. Note that default account mechanisms create anonymous subjects on the target nodes. As a result, objects that are to be made accessible to a default account must permit the WORLD user category full access, thus leaving the object unprotected. Security considerations when using this option include the following:

DECnet-VAX has no requirement for privileged default account.
UICs of the network non-privilege accounts should be unique for each group and user. Also, the group code must exceed the system UIC group number to avoid granting the system user category for file access to the user.
Keep the privileges for DECnet-VAX accounts to a minimum. Typically, this means giving only TMP MBX (TEMPORARY) and NET MBX (NET MAILBOX) to NONPRIVILEGE accounts.
The account for the FAL (File Access Listener) object should have a group code in its UIC that differs from that of every other account in the system, including accounts for other DECnet objects.
The member number of the owner UIC of the default directory for the FAL account should differ from the FAL account.
DECnet-VAX Database. This facility provides access and control over other computers which are connected to your computer. Security considerations when using this option include the following:
Defining receive and transmit password for all nodes in the database. When possible, the transmit password should be direct and not obvious.
Always enable verification on any circuit that goes outside a locked computer room, or goes to a machine with a different security environment.

E. Dial-up Security Considerations

In general, backup synchronous dial-up for autoanswer should not be nabled. Systems that have incoming dial-up for production purposes should control which nodes can connect.

To protect against dial-up intrusions it is advisable to use the SET PASSWORD/SYSTEM command and the SET TERMINAL/SYSPWD command. This will require a user to enter a system passwords before the username: prompt will be displayed.

F. DEC VAX Command Procedures

Sending output to a file: $ SHOW command D/OUT=filename

Printing a file: $ PRINT filename

Changing privileges (with SETPRIV): $ SET PROC/PRIV=privilege (e.g., SECURITY, ALL)

Showing executor characteristics to a file: $ SHOW EXEC CHAR TO filename

Audit Program

A. User Authorization File

I. Obtain a full user authorization file (UAF) listing and ascertain that user access to the system and data has been provided on a need-to-know basis.

To obtain the UAF, execute the following commands:

$LOGON

$SET PROC/PRIV=SYSPRV

$SET DEFAULT SYS$SYSTEM

$RUN AUTHORIZE

UAF>SHOW (or LIST) /FULL *

UAF>EXIT

$PRINT PRINTFILE

$DELETE PRINTFILE

$LOGOFF

List the records in SYSUAF.DAT.

- Brief Listing by Username

- Full Listing by Username and UIC.

II. Review the UAF user profiles and ascertain that special user attributes and/or privileges have been assigned only to personnel who have a legitimate need for them. Items of particular concern are:

Login Controls

Ascertain that at login the system welcome message that identifies the system has been disabled; and the only message provided is last login information message. Note that this is especially crucial if dial-in facilities are being used at this location.

Ascertain that appropriate login controls are in effect which restrict system access to authorize users via classes and types of logins, times and functions. Review the following login fields:

- LOGINCMD

- LOGINFLAGS

- PRIMARY AND SECONDARY DAYS

- TYPES OF LOGINS

- LOGIN RESTRICTIONS

Note that special consideration should be given to accounts with login flags set to NOPASSWORD option. The NOPASSWORD option allows login without a password, just the user- ID.

Ascertain that the location is currently not permitting automatic logins. To determine if automatic login is active perform the following:

a. Determine where the file SYSALF.DAT resides (default location is SYS$SYSTEM:SYSALF.DAT).

b. Use the DIRECTORY/ directory.name.SYSALF.DAT command. Note that the SYS$MANAGER: ALFMAINT.COM is used to maintain the automatic login feature (ALF). Note that this command will inform you whether the file is being used or empty. If it is being used , identify the users allowed to automatically login (i.e. without specifying the password) into the system. Evaluate whether

or not the access is appropriate, adequately controlled and that the associated devices is physically secured.

If the location has implemented menu security via the login command procedure, perform the following:

a. Ascertain that the CTRL/Y function has been disabled in the login command procedure. Note that disabling CTRL/Y does not permit the user to suspend execution of the current image and invoke the command interpreter. Thus forcing the execution of the complete login command procedure whenever a user logins in.

b. Review the login command procedure and ascertain that embedded logon-IDs and passwords are used, ensure that access (read and write) to the command procedure has been properly restricted. To determine occurrences of password and username in the login command file, execute the following command:

$SEARCH SYS$SYSTEM:*COM;*/WINDOW=(2,2)

$_STRING(S):PASS,PSWD,AUTHOR,AUDIT, PASS,PASSWD,AUTHOR,AUDIT

Note that this will provide a listing of all occurrences of the above two lines before and after these occurrences.

System Accounts

Determine the option specified for the sysgen parameter MAXSYSGROUP by scanning the SYSGEN listing. Ensure that it is within the range of 1 to 10 (minimum and maximum range). Note that MAXSYSGROUP specifies the UIC range for the system group.

Identify the users within the group number that is within the range specified in the MAXSYSGROUP parameter by performing the following:

- SHOW {*.UIC.GROUP} command, where the UIC-group is MAXSYSGROUP maximum number, and

- Scan the UIC-group section of the SYSUAF/BRIEF listing (in UIC order) for duplicate UICs.

Password Controls

Ascertain that system provided accounts (e.g. field, system, systest, etc.) have either been disabled or have had the original password changed from the vendor provided values.

Determine if the site uses a DECserver to communicate with other VAXs. If so, ascertain that the DECserver's password has been changed. To perform this test, type the following at the LOCAL> prompt SET PRIVILEGE and when the DECserver prompts you for the password enter the default password.

Ascertain that the default passwords for the mail and the terminal server facilities have been changed.

Determine whether the DEC SERVICE and other specialized accounts are disabled or restricted appropriate access time.

Ascertain that appropriate digital password control features have been implemented. Parameters of particular concern are:

PWDMIN - password minimum length

PWDLIFETIME - number of days before a password change is forced

PWDCHANGE - date the password was last changed

User Privileges

Ascertain that user privileges have been granted appropriately. Scan the authorized/default privileges section of the SYSUAF records and ensure that users are granted only TMPMBX and NETBBX. The users with the following privileges should be identified and proper justification and authorization should exist:

BYPASS - allows full access regardless of an object's protection.

SETPRIV - allows a user to set his privileges to whatever he/she desires (e.g.

BYPASS, SYSPRIV, SYSTEM, READALL, DETACHED, CONTROL, etc.) Providing full access to the system and resources.

READALL - allows read and control access to the object, even if such access is denied by the ACL or UIC-based protection. In addition, the user may receive any other access granted by the protection code.

SYSPRIV - allows the same access granted to users in the SYSTEM category.

GRPPRIV - allows a user whose UIC matches the group of an object the same access as users in the same category.

DETACHED - allows the user's process to create a detached process. There is no restriction on the UIC that can be specified for a detached process. Thus, there are no restrictions on the files and directories to which a detached process can gain access.

DEVOUR - Users with this privilege can seriously impact system integrity and performance.

Other Security Matters

Ascertain that the login flag parameter has been set to DISUSER for UAF records of accounts with high level privileges that are not actively used and for accounts/files which are undergoing transition (i.e. transferred and terminated employees).

Ask to see the Digital Site Manager's Guide. This binder will usually be filled out by DEC's field service representative (FSR) following a visit. It provides a service record for each processor. Frequently the FSR writes down the password to the field service account in this binder.

B. System Configuration and Defaults

Obtain a listing of the active system parameters, options, and defaults.

Ascertain that the active settings provide an appropriate level of control,

auditability, and integrity over the VMS environment.

Perform and print the following:

I. SHOW commands

SHOW ACCOUNTING - This will display items for which accounting is enabled. The items of concern are the logging of login failures and job terminations (batch, interactive, network, detached, etc.)

SHOW AUDIT - This will display which security auditing features and alarms have been enabled (e.g., system break-ins, file access violations, usage of the BYPASS privilege, etc.)

SHOW INTRUSION - This displays the content of the break-in database. The database, if active, contains information about login failures and the aversive action taken by VMS.

SHOW NETWORK - This displays information on the availability of the local node as member of the network and the addresses and names of all nodes that are currently accessible to the local node.

SHOW CLUSTER - This displays information on cluster activity and performance and the current VMS version number. Clustered systems permit the sharing of disks, resources, and operating systems.

SHOW LOGICAL - This displays the logical names which have been assigned to any physical units.

II. Run and print the SYSGEN utility

Run and print the SYSGEN utility and determine that installation selected values are appropriate.

To run the SYSGEN utility:

$LOGON

$SET PROC/PRIV=SYSPRV

$SETDEFAULT SYS$SYSTEM

$RUN SYSGEN

SYSGEN>SET/OUT=SYSGEN1.LIS

SYSGEN>SHOW/ALL

SYSGEN>EXIT

SYSGEN>DELETE SYSGEN1.LIS

$LOGOFF

Items of particular concern are:

MAXSYSGROUP=X - This parameter defines the range of system accounts (group numbers from 1 o X are system accounts).

LGI_BRK_LIM - This parameter specifies the number of failures that may occur at login time before the system will take action.

LGI_BRK_DISUSER - This parameter is used to flag in UAF record when an attempted break-in is detected.

LGI_BRK_TMO - This parameter specifies the number of seconds that a user or node is permitted to attempt a login (after an unsuccessful one) before the system forgets that a break-in attempt has occurred. This time is cumulative (added on for each unsuccessful attempt).

LGI_BRK_TERM - This parameter specifies that the terminal name is to be part of the associated string for the terminal node of the break-in detection.

LGI_RETRY_LIM - This parameter specifies the number of retry attempts allowed for users attempting to login over dial-up lines.

LGI_RETRY_TWO - This parameter specifies the number of seconds allowed between login retry attempts after a login failure.

LGI_PWD_TMO - This parameter specifies the period of time, in seconds, a user has to correctly enter the system password on a terminal on which the system password is in effect.

LGI_HID_TIM - This parameter determines the number of seconds that evasive action will persist following the detection of a possible break-in attempt. The evasive action consists of refusing to allow any logins during this period, regardless of whether a valid user name and password are specified. (This number is multiplied by a random value from 1 to 1.5 to specify he actual

amount of time).

C. Directory/File Protection

Evaluate the controls in place to restrict access to important/sensitive data to only those who need it to perform their job function.

ACL-based protection - To determine if ACL exists perform the following commands:

$DIR/SECURITY file.extension

$DIR/FULL file.extension

$EDIT/ACL file.extension

To obtain a listing of identifier(s) on the system and the user associated with the identifier(s), perform the following:

$RUN AUTHORIZE

UAF>LIST/IDENTIFIER/USER=* (This will list all identifiers in the rights database).

UAF>LIST/RIGHTS/USER=* (This lists all identifiers held by each user name).

UIC-based protection - To determine what UIC-based protection masks are used perform the following:

For a file:

$SHOW PROTECTION

$DIR/PROT file.extension

For a device:

$SHOW DEVICE/BRIEF

$SHOW DEVICE/FULL device name

System and Security Files

Identify the directories, subdirectories and files containing system software. Through discussion with the local system's manager, determine their sensitivity and ascertain that adequate protection is being provided. Particular attention should be provided to the security related files. Ascertain that the following security files are adequately protected either via ACL and/or UIC-based protection:

Directory Files

SYS$SYSTEM: SYS.EXE

F11BXQP.EXE

LOGINOUT.EXE

DCL.EXE

JOBCTL.EXE

JBCSYSQUE.DAT

SYSUAF.DAT

SYS$SYSTEM: NETUAF.DAT

RIGHTSLIST.DAT

STARTUP.COM

SYS$LIBRARY: SECURESHR.EXE

SYS$MANAGER: SYSTARTUP.COM

VMSIMAGES.DAT

SYS$ROOT: [000000]SYSEXE.DIR

[000000]SYSLIB.DIR

[000000]SYSMGR.DIR

Ensure that he following compilers do not exist in the production (non-system) executable program directory. These should not be available to any user in the production environment other that the user responsible for moving files into production:

VAXC.EXE

BASIC.EXE

FORTRAN.EXE

PLIG.EXE

MACRO32.EXE

Perform a DIR/PROT of the files to determine if key files have security alarms

(e.g. AUTHORIZE.EXE, LOGINOUT.EXE, DCL.EXE, SYSUAF.DAT, RIGHTSLIST.DAT.

Note that they should reside in the system pack and that they should be restricted from the world.

Production Programs

Identify the production application and user source and executable libraries and ascertain that these libraries and their members are being afforded an appropriate level of protection either via ACLs and/or UIC-based protection.

Production Data

Through discussion with MIS and user personnel, identify sensitive/critical data files used on the system. On a selected basis, review the level of protection afforded to these files.

If privileges provided to the auditor are limited, perform the following to verify that ACL protection is in place for the above named files by performing the following:

$SET DEFAULT directory name

DIRECTORY/PROTECTION file name

Those files that are ACL-protected will have the following message displayed:

"No access permitted." For those files with ACL-protection, have the system manager list out the ACL's and review their appropriateness.

Review the DEC/VAX violation reports and evaluate whether the report is being utilized and the steps taken for its review. Evaluate how security violation are tracked and obtain a copy of the log (if maintained) for review.

D. Network Security

Using the network utilities, list the critical parameters, options and defaults for the network environment. Determine that the environment has been set up with proper controls and provides an appropriate level of security.

Execute the following utilities and examine the parameters specified. Note that LIST is for permanent parameters and SHOW is for volatile or temporary parameters. The Network Control Program (NCP) can be run entering the following:

$RUN SYS$SYSTEM:NCP

>SHOW (or LIST) EXECUTOR CHARACTERISTICS

Determine whether or not default proxy or DECnet default access are permitted for both incoming and outcoming access.

Determine if proxy login access is enabled or disabled for both the subject and the object databases.

To perform this test, execute the following commands:

>SHOW (or LIST) KNOWN NODE CHARACTERISTICS

>SHOW (or LIST) KNOWN OBJECT CHARACTERISTICS

Ascertain that remote nodes (synchronous and nonsynchronous circuits) are required to send a routing initialization password.

Determine if network logins are controlled via proxy accounts. If not, determine what controls are in effect that prevents passwords from being echoed-in at the terminal, recorded on system log files, or from being intercepted in an unencrypted form.

Examine the UAF (User Authorization File) for proxy accounts and ascertain whether or not they are adequately controlled. To perform this test execute the following commands:

$RUN AUTHORIZE

UAF>SHOW (or LIST) PROXY

UAF> EXIT

$PRINT/DELETE PRINT FILE

$LOGOFF

Note that the proxy account should be restricted in the SYSUAF file as follows:

- Should only be given TMPMBX and NETMBX privileges.

- Should be captive accounts.

- Should be restricted from other mode of login such as batch and interactive (by specifying /NOBATCH, /NOINTERACTIVE login flags parameters.

	OSA OSU OSV Testa Testu Testv Filesa Filesu Filesv Reports Home AReport UReport VReport
www.cxlsecure.com