Terminal service access to other computers can be a vital part of many network activities. The TELNET and rlogin protocols are used for making these terminal connections, but they are not without risk. The Gauntlet Firewall includes proxies for both the TELNET and rlogin protocols, which securely handle terminal services between the inside and outside networks.
This chapter discusses the concepts behind the TELNET and rlogin proxies and explains how they work, how to configure the proxies, and how to use terminal services. The chapter consists of these sections:
The TELNET and rlogin proxies are application-level proxies that provide configurable access control, authentication, and logging mechanisms. The TELNET and rlogin proxies, which run on the firewall, pass TELNET and rlogin requests through the firewall, using rules you supply. The TELNET proxy also passes TN3270 requests through the firewall. You can configure the proxies to allow connections based on:
source IP address
source hostname
destination IP address
destination hostname
Using these options, you can configure your firewall to allow specific hosts on outside networks to connect to inside hosts or vice versa. Employees working at customer sites can access their workstations inside the perimeter.
The proxies allow administrators to require users to authenticate before connecting. The proxies log all successful and unsuccessful connection attempts and the amount of data transferred.
These access controls allow you to have much more control over the connections to and from your system than using the standard IRIX TELNET and rlogin programs. The logging capabilities are also much more extensive.
 | Note: You can use the TELNET proxy without the rlogin proxy, or rlogin without TELNET. You can configure different policies for hosts and authentication as well. |
The firewall runs the network access control daemon (netacl) as a daemon listening for requests on the standard TELNET port (TCP port 23). Whenever the firewall receives a TELNET request on this port, the netacl daemon checks its configuration information and determines whether the initiating host has permission to use TELNET. If the host has permission, the netacl daemon starts the standard TELNET program (telnetd) or the TELNET proxy (tn-gw) depending upon the originating host. If the host does not have permission, the daemon displays an error message. Similarly, the netacl daemon running on the standard login port (TCP port 513) starts either the rlogin program (rlogind) or the rlogin proxy (rlogin-gw).
The default trusted service group and rules allow all inside hosts to initiate TELNET or rlogin sessions without authenticating. The inside host passes TELNET requests to the firewall, which starts the netacl daemon. The netacl daemon checks its permissions, and determines that the inside host can use TELNET. The netacl daemon starts the proxy. The proxy logs the transaction and passes the request to the outside host. The proxy remains active until either side closes the connection.The default untrusted service group allows outside hosts to initiate TELNET or rlogin sessions after authenticating. The outside host passes TELNET requests to the firewall, which starts the netacl daemon. The netacl daemon checks its permissions, and determines that the outside host can use TELNET. The netacl daemon starts the proxy. The proxy prompts the user for authentication. If it is successful, the proxy prompts the user for the inside host, logs the transaction, and passes the request to the inside host. The proxy remains active until either side closes the connection.
Note that users are not logging into the firewall directly. While users use the proxy on the firewall for authentication, the proxy simply passes the user's TELNET or rlogin session on to the appropriate host.
A configuration using netacl allows administrators on either inside or outside hosts to initiate TELNET requests to the firewall. The netacl daemon checks its permissions and determines that the host can use TELNET. The netacl daemon starts the proxy. The proxy prompts the user for authentication. If it succeeds, the proxy prompts the user for the host and logs the transaction. When users indicate they want to connect to the firewall itself, the netacl daemon reviews the source and starts the actual TELNET daemon.
To access the TELNET proxy configuration:
From within the Gauntlet Firewall Manager, select Services.
Click the TELNET tab.
The TELNET window displays.
To access the rlogin proxy configuration:
Configuring the Gauntlet Firewall involves planning, configuring the proxies to enforce your security policy, enabling the proxy, and creating user accounts for users who will need to authenticate.
When planning TELNET and rlogin proxy settings:
Determine whether you wish to allow TELNET and TN3270 connections through the firewall.
Determine whether you wish to allow rlogin connections through the firewall.
Determine your policies for authentication.
Configure the TELNET or rlogin proxy to enforce your security policies.
To configure TELNET or rlogin proxy settings, provide optional information about time-out values and other configuration settings for the TELNET and rlogin proxy if desired. Refer to the online help for specific information about the available settings.
| Note: The settings for the TELNET proxy (tn-gw) affect both TELNET and TN3270 access through the firewall. If you need different settings for these two types of access, consider creating a separate configuration for TN3270 access. |
To enable the TELNET or rlogin proxy service:
On the TELNET or rlogin windows, select Enabled.
Add the TELNET or rlogin proxy configuration to the service groups you want to use the proxies.
Before exiting the Gauntlet Firewall Manager, Save and Apply your changes.
The firewall enables the TELNET or rlogin proxies.
Use the authentication management system to create authentication user entries for any users who authenticate when using TELNET and rlogin services. Refer to Chapter 6, “Users and User Groups,” for more information.
Verify your configuration by connecting to an inside host from an outside host. See the next section, “Using Terminal Services”, for instructions.
This section discusses how to use different configurations of TELNET, rlogin, and TN3270.
You can configure the proxies so that they are transparent to your users. Common policies (including the Gauntlet Firewall default policies) configure the proxies so that users working on the trusted networks behind the firewall will not see a change in their daily TELNET and rlogin activities.
For example, Scooter, working on his workstation at Yoyodyne headquarters, wants to continue to connect to his account at Big University using TELNET. Because the Yoyodyne firewall is setup with transparency and does not require authentication, he simply uses TELNET to access the remote host directly. He does not need to explicitly mention the firewall at all.
If you have configured terminal services to require authentication, users will need to follow different procedures to use TELNET or rlogin.
To TELNET using authentication:
Use TELNET to connect to the firewall itself.
Authenticate to the proxy.
Connect to the desired host.
Continue as before.
A common security policy for the TELNET proxy is to authenticate all requests from untrusted networks to or through the firewall. The example below shows a sample TELNET session from an untrusted network to a trusted network, using S/Key authentication at the firewall:
blaze.clientsite.com-28: telnet fire-out.yoyodyne.com Trying 204.255.154.100... Connected to fire-out.yoyodyne.com Escape character is '^]'. Username: scooter Skey Challenge: s/key 651 fi19289 SAFE DUB RISK CUE YARD NIL Login Accepted fire-out.yoyodyne.com telnet proxy (Version 4.0a) ready: tn-gw> c dimension Trying 10.0.1.120 port 23... Connected to dimension.yoyodyne.com BSDI BSD/OS 2.1 (dimension) (ttyp5) login: scooter Password: ######### Welcome to dimension.yoyodyne.com |
In this example, Scooter, working at a client site (blaze.clientsite.com), needs TELNET access to a system behind the firewall (dimension.yoyodyne.com). He first connects to the outside interface of the firewall (fire-out.yoyodyne.com) using TELNET. The TELNET proxy on fire-out prompts him to authenticate. Scooter provides his authentication user ID (scooter). When the proxy prompts, he enters the response to the authentication challenge. The proxy authenticates scooter.
Scooter indicates the host he needs to access (dimension). The TELNET proxy connects Scooter to dimension, and the TELNET daemon running on that system. The TELNET daemon on dimension prompts Scooter for his user name and password on dimension. The TELNET daemon on dimension verifies Scooter's user name and password, then logs him in.
If you have configured terminal services to require authentication, users need to follow different procedures to use TN3270.
To use TN3270 with authentication:
TN3270 to the firewall itself, disabling true TN3270 support for the initial handshake.
Authenticate to the proxy.
Connect to the desired 3270 host.
Continue as before.
The corporate security policy that requires authentication before using TELNET from untrusted hosts to trusted hosts also applies to using TN3270. Generally, the only difference is in starting the TN3270 client:
blaze-55: X3270 -model 2 -efont 3270-12 a: fire-out.yoyodyne.com |