UNIX Telnet Environment Security Issues

Reference > Security > UNIX Telnet Environment Security Issues

To access a subset of QAD Standard Edition maintenance programs, the .NET UI uses telnet to log on to the server where QAD Standard Edition is installed. Because .NET UI communicates via HTTP, the account log-in ID and password are sent using unencrypted text. Since this may compromise system security, you should configure the telnet environment with server-side security measures.

A range of security options exists to solve the unencrypted log-in and password problem. This section outlines two security scenarios: one providing a maximum level of security and one providing less security but more flexibility for Progress client session and home directory access. In both setups, it is recommended that you use a restricted shell (rsh).

Restricted Shells

Restricted shells are restricted versions of the common UNIX Bourne shell or Korn shell. In the Bourne shell, the restricted shell is run as rsh (/usr/lib/rsh), while in the Korn Shell it is known as rksh (/usr/bin/rksh). The restricted versions of these shells allow users to log in with restricted access. They cannot:

• Use the cd command to change directories.

• Specify a path or command using /.

• Use redirection (>, >>).

• Set the value of $PATH.

Note: The default shell for a user is located in the /etc/passwd file.

Note: A user’s path should not include /usr/bin. This lets the user run another shell, thereby inheriting access to any commands that the child shell allows.

Examples of Security Measures

Case 1: Maximum Security

One UNIX account with the following characteristics is used for all telnet sessions:

• No write permissions to home directory. Temporary files are written elsewhere.

• $PATH, $DLC, and $PROPATH environment variables are set in .profile and inaccessible to the user.

• Startup command and/or scripts are run from .profile.

• Telnet disconnects immediately after the user exits the QAD Standard Edition session.

Use the following instructions to set up Case 1:

1 Create the unique account for log-in to UNIX through telnet.

2 Make the default shell for this account the restricted shell.

3 Remove all write permissions for this user in their home directory. Use the ‑T option in the remote script to specify an alternate temporary directory.

4 Set up the .profile to set minimal environment variables.

5 Set up the .profile to run the script automatically.

Example: .profile for Case 1:

/*Sample .profile for Desktop mainten session, single Desktop login*/

#set default for error (STOP) condition handling

stty intr ^C

#set environment variables

PATH=/dlc91:/dlc91/bin

DLC=${DLC - /dlc91}

PROEXE=${PROEXE - $DLC/bin/_progres}

export PATH DLC PROEXE

#Autorun remote script for Desktop Access and automatically exit

exec remote.script

exit

Case 2: Moderate Security

Users have their own unique log-in and password, but run the restricted shell by default:

• Write permission to the home directory is possible, but not necessary.

• $PATH, $DLC, and $PROPATH environment variables are set in .profile and inaccessible to the user.

• Users run a subset of UNIX commands, which you add to /usr/rbin.

• Users can run QAD Standard Edition manually from a command line or script.

Use the following instructions to set up Case 2:

1 Create or modify accounts for users of QAD Standard Edition maintenance programs by changing their default shell in the /etc/passwd file to the restricted shell.

2 Create the directory /usr/rbin and copy the UNIX commands necessary for these users. Make the /usr/bin directory read-only so users cannot change path variables.

3 Set up a special .profile for maintenance program users.

4 Set the minimal environment variables, remembering to include /usr/rbin.

5 Copy the telnet connection script to each user’s home directory with read-only access.

6 Put any other necessary read-only script files in the home directory.

Example: .profile for Case 2:

/*Sample .profile for Desktop session for individual logins

remote.script should be in home directory; executable by Desktop*/