3    Connecting to Other Systems

By connecting systems to each other, users have greater access to information; however, such connections also increase the security risks for each system. Responsible network security allows users some freedom, while protecting valuable files from unauthorized users.

Although the system administrator is responsible for most network security issues, individual users must be alert to security risks that affect their accounts and files.

The following networking protocols enable Digital UNIX users to communicate with other users on remote systems:

• Internet protocols (TCP/IP)

• Local Area Transport (LAT)

• The UUCP utility

• DECnet

Each protocol has its own scheme for handling communication between systems on a network. This chapter describes the security risks in using commands that connect to other systems using each of these protocols, and offers suggestions for minimizing those risks.

3.1    The TCP/IP Commands

The TCP/IP protocols are the most commonly used networking protocols running under Digital UNIX software. With TCP/IP, much of the network access to the computer is in the hands of users. The TCP/IP remote commands are described in the following sections.

3.1.1    The rlogin, rcp, and rsh Commands

The following commands enable you to communicate with remote systems:

rlogin

Lets you log in to a remote system. This command connects your terminal on the local host system to another login session either on a remote system or on the local host system. For more information, see the rlogin(1) reference page.

rcp

Lets you copy files to and from remote systems. For more information, see the rcp(1) reference page.

rsh

Lets you connect to a specified host and execute a command on the remote host. This command is a conduit to the remote command, passing it your input for processing and returning to you its output and any error messages that it generated. For more information, see the rsh(1) reference page.

A security risk in using the rlogin, rcp, and rsh commands lies in the network files /etc/hosts.equiv and \.rhosts, which these commands check before connecting to a remote system.

3.1.2    The hosts.equiv File

The /etc/hosts.equiv file contains a list of host systems that are equivalent to your local host system. Users on equivalent hosts can log in to their accounts on the local host without typing a password. The user name on the remote and local host must be identical.

Equivalent hosts can be remote hosts or the local host. If the local host is listed in the /etc/hosts.equiv file, users logged in to the local host can remotely log in to their own accounts on the local host, without typing a password.

For security reasons, the /etc/hosts.equiv file does not allow a superuser logged in on a remote system to log in to the local host without typing a password.

Because the /etc/hosts.equiv file is a remote system's access key to your system, security-conscious system administrators leave this file empty or carefully restrict access to systems.

If the /etc/hosts.equiv file is empty, the only way a user on a remote host can log in to your account on the local host without typing a password is if the user's name is listed in your .rhosts file.

For more information, see the hosts.equiv(4) reference page.

3.1.3    The .rhosts File

The most common use of the $HOME/.rhosts file is to simplify remote logins between multiple accounts owned by the same user. If you have active accounts on more than one system, you may need to copy files from one account to the other or remotely log in to one account from the other. The \.rhosts file is ideally suited to this type of use.

The $HOME/.rhosts file is a list of equivalent hosts that users can create in their home directories. This file is the user counterpart of the /etc/hosts.equiv file, although it has a narrower focus than its systemwide counterpart. The /etc/hosts.equiv file can affect the accounts of many users on a system. The \.rhosts file affects only the individual user's account.

Your \.rhosts file also enables users with your user name on equivalent hosts to log in to your account on the local host, without typing a password. Users must have a \.rhosts file in their home directory.

Note

Equivalent hosts can be remote hosts or the local host. If the local host is listed in your \.rhosts file, users with your user name, logged in to the local host, can remotely log in to your account on the local host, without typing a password. Including the local host in your \.rhosts file enables you to remotely log in to your account and start a new session on the local host.

If you list another user's name next to the host name in your .rhosts file, that user can log in to your account on the local host; the remote user does not need an account on the local host or a .rhosts file in his or her home directory on the remote host. For example, the following entry in Peter's \.rhosts file allows Paul to log in from rook as Peter without typing a password:

rook   paul

Your \.rhosts file can expand the access that the /etc/hosts.equiv file grants to your account, but it cannot restrict that access. When a user executes the rlogin, rcp, or rsh command, that user's \.rhosts file is appended to the /etc/hosts.equiv file for permission checking. The entries in the combined files are checked in sequence, one entry at a time. When the system finds an entry that grants access to the user, it stops looking. The entries in the /etc/hosts.equiv file are checked before the entries in the \.rhosts file are checked. However, when the user is root, only the \.rhosts file is checked.

If your security administrator excludes a host from the /etc/hosts.equiv file, then all users on that host are excluded. If you include that host in your \.rhosts file, then users on that host are considered trusted and can log in to your account without entering a password. The converse is not true. If your system administrator includes a host in the /etc/hosts.equiv file, you cannot exclude users on that host from accessing your account. If you put a remote host and a user in the /etc/hosts.equiv file, that user on the remote host has access to all nonroot accounts on your host.

3.1.4    The ftp Command

The ftp command enables you to transfer files to and from a remote host, using the Internet standard File Transfer Protocol. In autologin mode, ftp checks the .netrc file in your home directory for an entry describing an account on the remote host. If no entry exists, ftp uses your login name on the local host as your user name on the remote host, and prompts for a password and, optionally, an account for login. Because your ftp login to a remote system is in essence a remote login to that system, you have the same access to files as if you, rather than ftp, had actually logged in. For more information, see the ftp(1) reference page.

A security risk in using ftp is the practice of creating the anonymous account, a generic account that the ftp command recognizes. The anonymous account usually has a commonly known password or no password, and it allows users to log in and transfer files to or from your system from a remote system with no audit trail. System administrators concerned with network security often avoid creating such anonymous accounts or carefully restrict which files can be copied or written.

You should know and follow the security policy on using ftp for file transfers to remote systems. Talk to your system administrator about the security controls at your system.

3.1.5    The tftp Command

The tftp command provides an interface to the Internet standard Trivial File Transfer Protocol. Like the ftp command, this command enables you to transfer files to and from a remote network site. However, the tftp command does not request a password when you attempt to transfer files. Therefore, any user who can log in to a system on the network can access remote files with read and write permission for other. Because the tftp protocol does not validate user login information, setting proper permissions on your files is the only real protection from unauthorized access.

The tftp command is shipped on the system but is turned off by default. To protect your system, avoid using tftp, if possible, or limit the directories that tftp can access.

3.1.6    Remote Connection Security Tips

Follow these guidelines to protect your files against attack through the rlogin, rcp, and rsh commands:

• Check your file permissions. Your home directory should deny all access to other, and write access to group. The permissions on the command and configuration files, such as \.profile, \.login, \.logout, \.cshrc, and \.forward, should deny all access to group and other. For example, use the chmod command to change the protections on those files from your home directory, as follows:

  $  chmod 750 $HOME
   
  $  chmod 600 .profile .login .logout .cshrc .forward
  

  If you do a long listing of your home directory, your file protections should look like these:

  $  ls -al
  

  drwxr-x---  9   fields     512  Jun 13 11:46 .
  -rw-------  1   fields     419  Jun 2  08:28 .login
  

  
  

  Use the chmod command to set the permissions on your \.rhosts file to 600. The Command and Shell User's Guide discusses protecting your files and directories. ..BL .Ask your system administrator for a list of trusted hosts to include .in your .PN .rhosts file and review this list with your system .manager on a regular basis. ..BL ..NX R .rhosts file security suggestions .Include a user name as well as a system name for each remote .system listed in the .PN .rhosts file. The user name restricts remote .access to your files to the named .user, rather than to any user on the remote system.

• Include in the \.rhosts file only the current remote hosts from which you would like to issue remote commands. It is wise to list only hosts on which you have accounts. If you are unsure about which hosts to include in this file, check with your system administrator.

• You should be the owner of your \.rhosts file, and it must not be a symbolic link to another file.

3.2    LAT Commands

Your system administrator can increase the security of the LAT (Local Area Transport) protocol service by configuring LAT groups of hosts that can communicate only with each other or through specified terminals. A host can be set up to listen for connections from certain groups of terminal servers, while ignoring connections to all other LAT servers. For more information on using the LAT protocol, see the latcp(8) reference page.

3.3    The UUCP Utility

The UUCP utility is a group of programs that enable you to connect to remote systems using a modem and telephone lines. The UUCP utility, which is available on most UNIX systems, enables you to transfer files between remote systems and the Digital UNIX operating system. In addition, your system can use UUCP to send and receive mail across telephone lines.

Several UUCP commands can present security concerns:

• uucp

• tip

• cu

• uux

3.3.1    The uucp Command

The uucp command is the main interface to the UUCP utility.

The UUCP utility enables users on remote systems to access those files and directories for which the system administrator has granted permission. The uucp command allows any user to execute any command and copy any file that is readable or writable by a UUCP login user. Individual sites should be aware of this potential security risk and apply any necessary protections.

Your system administrator exercises certain security measures when installing and setting up the UUCP utility. However, it is important for you to take the following actions to protect against unauthorized use of this powerful utility through the uucp command:

• Create a directory in your account for UUCP. Use only this directory for all UUCP transactions.

• Use the chmod command to set the sticky bit on the UUCP directory. When the sticky bit is set on a directory, only root or the owner of a file can remove files from the directory. While you are operating under UUCP, you will not be able to remove those files while the sticky bit is set, and you may have a disk space problem. If this happens, remove the sticky bit from your directory and remove the excess files. The following example sets the sticky bit on the documents directory:

  $  chmod 1777 documents
  

• Until you set up a separate UUCP directory, always copy files to or from the /usr/spool/uucppublic directory.

For more information on setting the sticky bit, see the chmod(1) reference page. For more information on the UUCP utility, see the uucp(1) reference page.

3.3.2    The tip and cu Commands

The tip and cu commands enable you to call another system, log in, and execute commands while you are still logged in to your original system. The tip and cu commands are two different interfaces to the same program. The cu program allows you to be logged in on both systems at the same time, executing commands on either one without dropping the communications link. The tip command connects you to a remote system and allows you to work on the remote system as if logged in directly. You need only tell tip or cu what telephone number to call.

The following example shows a session using the cu command:

$  cu 4783939

connected
login:

A security concern about using the tip and cu commands is that everything you type is read by the command and passed to the remote system. This can be dangerous if the remote system is not a trusted system. A trojan horse version of cu, for example, could store your login name and password on a remote system. Follow these general security guidelines for using commands that start remote sessions:

• Be sure that the program you are using is the authentic program. Do not use a terminal that seems already to be running tip or cu; reinvoke the command using the full path.

• Do not use an automatic login procedure, such as sending your remote password from a file on the local computer.

• If you are capturing the session transcript into a local file, begin the capture only after completing remote login. Capture only the data you need; avoid capturing the dialogue you used to obtain the data.

• Avoid leaving your terminal or using your terminal for other things while a remote session is in progress. If your connection with the remote system is broken, immediately reestablish contact. Using the ps -e command, check to see if your first session left any processes suspended and kill those processes with the kill -9 command.

For more information, see the tip(1) and cu(1) reference pages.

3.3.3    The uux Command

The uux command runs a specified command on a specified system while enabling you to continue working on the local system. The command gathers various files from the designated systems, if necessary. It then runs a specified command on a designated system. Users can direct the output from the command to a specified file on the designated system. For security reasons, many installations permit uux to run only the rmail command.

See the uux(1) reference page for more information.

3.4    The dlogin, dls, and dcp Commands

If DECnet is installed on your system, you can use the following DECnet commands to communicate with remote systems running the DECnet protocol:

• dlogin

• dls

• dcp

Your system administrator can increase DECnet security on your system by not creating a generic guest account for remote DECnet connections. Without this default user account, remote users must specify a valid user name and password either on the command line or interactively. For example, to copy a file from one system to a remote UNIX system without a default user account, you would have to type the following command:

$  dcp  localfile rem_node/rem_user::/rem_path/file
Password for  rem_node/rem_user:: ? :

If you are connecting to a remote system that has no default user account, you should not include the password information in the command. If you do not specify a password, you will be prompted for one. This provides more security because some shells (for example, the C shell) can maintain a history file. If you keep a history file and enter your password in clear text on a command line, the password is stored in the history file.