This chapter presents the security features available with TCPware.
TCPware security features can be divided into two parts: independent, free-standing security features, and those inherent within products. The free-standing security features include:
· Incoming Access Restrictions
· Outgoing Access Restrictions
· Kerberos Services
· IP Security Option (IPSO)
· Packet Filtering
Here are some general tips to maintain system security on your TCPware system:
1. Implement an aggressive password strategy for users and especially for privileged accounts. This means long passwords and frequent password changes.
2. Disable all unused accounts, especially privileged ones that are predefined with the operating system (such as field test accounts).
3. If a break-in is in progress, use one of the DEBUG commands in the Network Control Utility (NETCU) to capture the packets. However, be advised that monitoring might be construed as an invasion of privacy.
4. Carefully consider the system announcement or welcome messages. Do not welcome people to the site. Instead, make it clear that the system is for authorized users only, and that all users may be monitored for security reasons.
5. Subscribe to CERT (Computer Emergency Response Team) announcements by e-mail. If you believe that your system was compromised, contact the CERT Coordination Center or your representative in Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by e-mail, we strongly advise that the E-mail be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available through anonymous FTP on info.cert.org), or PEM (contact CERT staff for details).
6. Disable services not required for your system. For example, if SSH is enabled, disable the services it replaces such as rlogin/rshell and possibly telnet.
This section describes the security features that you can use with more than one TCPware product. These include incoming and outgoing access restrictions, packet filtering, and the IP Security Option.
With incoming access restrictions, the system imposes restrictions on the remote hosts having access to local services. Manage incoming access restrictions using the following NETCU commands:
· ADD ACCESS_LIST
· REMOVE ACCESS_LIST
· MODIFY SERVICE
· ADD SERVICE
· SHOW ACCESS_LISTS
To manage incoming access restrictions, see Chapter 21, Access Restrictions.
With outgoing access restrictions, you restrict access to outside services such as FTP or TELNET for local users. You can base restrictions on a user's ID (UIC or rights identifiers), or the destination address or port (service). Since the system checks only outgoing access restrictions with active open connections and not on each and every datagram, it involves relatively low system overhead.
Manage outgoing access restrictions using two commands in the TCPware Network Control Utility (NETCU):
· SET OUTGOING_ACCESS_RESTRICTIONS
· SHOW OUTGOING_ACCESS_RESTRICTIONS
To manage outgoing access restrictions, see Chapter 21, Access Restrictions.
Packet filtering restricts the datagrams that may be received on a network interface. The system drops all datagrams it denies entry. This software-based filtering allows you to filter datagrams by:
· Protocol (IP, TCP, UDP, or ICMP)
· Source or destination address
· Destination port (TCP or UDP) or ICMP message type
Packet filtering prevents a site from receiving datagrams from certain networks or hosts. For example, a site might wish to restrict incoming access from the rest of the Internet, but allow local users to have full access to Internet resources.
Use packet filtering only when absolutely necessary since the system must scan the packet filter for each datagram. If there is a question whether to use packet filtering or access restrictions on incoming datagrams, packet filtering is more complete, since it covers all connections. However, packet filtering requires more overhead than incoming access restrictions.
Manage packet filtering using the following NETCU commands:
· SET FILTER / SET NOFILTER
To manage packet filtering, see Chapter 20, Packet Filtering.
The IP Security Option (IPSO) is a standard for preventing a system from receiving or transmitting unauthorized datagrams. It was developed for the U.S. Department of Defense and conforms to RFC 1108, U.S. Department of Defense Security Options for the Internet Protocol. IPSO incorporates both a Basic Security Option and an Extended Security Option. TCPware supports both options.
To manage IPSO, see Chapter 24, IP Security Option (IPSO).
This section describes the TCPware security features available with particular TCPware products.
The R commands implement security at TCPware configuration and later through Service Access Lists and host equivalence files. The R services use standard TCPware and OpenVMS security facilities to ensure that only authorized hosts and users have access to the TCPware host. TCPware implements R command security through:
|
Configuration |
During TCPware configuration, you first select whether you want to enable the login, shell, and exec services. For login service, you also specify whether you want NORMAL or SECURE login authorization (the default is SECURE). The login service is used for RLOGIN, while shell or exec is used for RCP, RMT, and RSH (exec if you specify a username and password). |
|
Service Access Lists |
If desired, create a Service Access List to control which hosts, group of hosts, or network can have access to the service. |
|
Host equivalence files |
Host equivalence files allow a set of remote hosts access to the server. They contain single-line entries for each authorization. The system manager can set up a TCPWARE:HOSTS.EQUIV file on the system level. Each individual client user can also set up a SYS$LOGIN:.RHOSTS file. This allows equivalent access beyond that specified in the TCPWARE:HOSTS.EQUIV file. The format for SYS$LOGIN:.RHOSTS and TCPWARE:HOSTS.EQUIV file entries is identical. |
See Chapter 15, Managing R Commands, for details on host equivalence files.
The typical R commands server security steps are that the server:
1. Checks that the Service Access List (if any) is configured to protect the desired service.
2. Checks that the client's port number is in a reserved range.
3. Checks the password file for an entry for the supplied username.
4. Searches the /etc/hosts.equiv (on UNIX systems) or TCPWARE:HOSTS.EQUIV (on OpenVMS systems) file for the hostname and username.
5. Searches the .rhosts (on UNIX systems) or .RHOSTS (on OpenVMS systems) file in the user's home directory for the hostname and username.
6. Prompts for a password if SECURE login is specified (for RLOGIN) and there is a match-up in the .RHOSTS or HOSTS.EQUIV file, or a username and password if NORMAL login is specified (for RLOGIN) without a match-up in the .RHOSTS or HOSTS.EQUIV file.
7. Grants or rejects access depending on the server configuration and authorization results:
· Grants access for shell, exec, or NORMAL login service without a login prompt if there is a match-up in the .RHOSTS or HOSTS.EQUIV file, or for SECURE login service if the password entered is authorized.
· Rejects access if the server is configured for shell, exec, or SECURE login service and there is no matchup in the .RHOSTS or HOSTS.EQUIV files, or for NORMAL login service if the password entered fails authorization.
For details on Service Access Lists, see the ADD ACCESS_LIST in the NETCU Command Reference.
TCPware provides the following security for the DECwindows Transport Interface:
|
Target display host configuration |
Configure the target display host to allow incoming X Window System applications from the OpenVMS system host. |
|
Displaying on the local host |
Bring up the Security option under the Session Manager's Options menu. |
|
Displaying on the remote host |
Configure "security" on the remote host to allow incoming connections on the currently active session. |
To manage DECwindows security, see Chapter 29, DECwindows Transport Interface.
The FTP server provides the following security functions and options:
|
Functions and Options |
Description |
|
Passwords |
Like DECnet, you cannot use FTP to log in to multiple-passworded accounts. |
|
Directory access restrictions |
The FTP server lets you define the TCPWARE_FTP_ROOT logical for directory access restrictions on a system-wide basis, the TCPWARE_FTP_ANONYMOUS_ROOT logical for the ANONYMOUS user directory access restrictions, and the TCPWARE_FTP_username_ROOT logical for directory access restrictions for specific user accounts. |
|
Log file |
The FTPSERVER_DTP.LOG file contains information about files transferred during the FTP session. Examining this file helps to isolate security problems. |
|
Idle timeout |
If the control connection (other than during a data transfer) is idle for more than 10 minutes, the system aborts the connection. |
|
SYLOGIN.COM |
This procedure and user account login command procedures can contain commands that cause the login to fail. |
|
FTP ANONYMOUS Accounts |
FTP supports ANONYMOUS accounts whereby the user can log in using the ANONYMOUS login and the GUEST password. You set up ANONYMOUS accounts using the AUTHORIZE utility.
ANONYMOUS users only have read-only access unless you define the TCPWARE_FTP_ANONYMOUS_RIGHTS logical to allow write, rename, and delete access rights. In addition, the TCPWARE_FTP_ANONYMOUS_ROOT logical allows you to restrict ANONYMOUS users to files in the root directory and its subdirectories. |
|
TCPWARE_FTP_LOGFILE |
Define this system logical name to specify the log file name if you suspect break-in attempts through the server. Note that you must restart the FTP server after setting this logical by issuing the @TCPWARE:RESTART FTP command. |
|
TCPWARE_FTP_421_REPLY |
This logical defines a message to send when a user you want to prevent from logging in connects to the server. After sending the message, the connection closes. |
To manage FTP server security, see Chapter 12, Managing FTP.
The NFS server provides several features that maintain the integrity of the OpenVMS file system:
|
PROXY database |
The server requires that the local system must register any user attempting access to OpenVMS files. You do this through the PROXY database when you configure the server, and through later modifications as needed. |
|
EXPORT database |
You must export an OpenVMS directory for an NFS user to have access to it. The server does this through the EXPORT database when you configure the server, and through later modifications as needed. |
You can take the following additional system security measures:
· Assign an NFS rights identifier to further restrict file access.
· Require all RPC requests to originate from privileged ports.
· Restrict all remote mounts to the NFS superuser only.
· Restrict mounts only to explicit directories and not their subdirectories.
· Require the PROXY database to define the mount requester's identification.
See Chapter 14, Managing NFS Server.
Passwords can be a problem in RCP since the /PASSWORD qualifier requires entry of plain text that someone on the network can intercept.
You can prevent users from having to specify the /USER, /PASSWORD, or /TRUNCATE qualifier with the RCP command. Check that remote hosts include your hostname entry in their host equivalence files (such as the /etc/hosts.equiv file in UNIX systems). On OpenVMS hosts, the TCPWARE:HOSTS.EQUIV or SYS$LOGIN:.RHOSTS file serves as the host equivalence file to permit remote hosts to log in.
To manage RCP security, see Chapter 16, Managing R Commands.
The SSH server provides safe, encrypted access, replacing rlogin, rshell, and telnet. It provides the following security features:
|
X11 display forwarding |
Encrypts the display output for X11 sessions for transmission to another system over an unsecure network. |
|
Port forwarding |
Provides transfer of encrypted data between ports on two systems over an unsecure network. |
|
User Authentication |
.rhosts - Provides simple access via the rhosts file. Inherently unsecure and not recommended. .rhosts with RSA authentication - the user and system must exist in the rhosts file, and the client system's public key must be known to the server system. RSA challenge-response - the client and server system must encode, exchange, and decode successfully a random 32-bit number using the private and public client and server keys. Password - the user is validated via the use of a password. |
|
Multiple Encryption Algorithms |
idea, blowfish, twofish, des, 3des, and arcfour. |
The TELNET Server provides the TCPWARE_TELNETD_INTRO_MSG option. With this logical, you can define a special message that appears whenever a user attempts access to the host through TELNET. You can use this logical to issue warnings such as "Authorized Use Only" for remote logins.
Kerberos password protection is available for the TELNET service.
To manage TELNET security, see Chapter 17, Managing TELNET Server.