Telnet Proxy

The Telnet proxy provides a virtual terminal relay and allows or denies connections based on source and destination addresses. The Telnet proxy can ask for user authentication as an additional mechanism for controlling access to sites and commands. The Telnet proxy does not support content filtering.

To authenticate users, the Telnet proxy can request a user name from a user and, based upon the type of authentication for that user name, request and validate a reusable password or digital token.

Telnet Proxy Operation

When the Telnet proxy starts, it reads its policy files and listens on the standard Telnet port (23) for connections. When a connection is made, the Telnet proxy starts a new thread to handle the connection, and the main thread returns to listening.

The child thread generates a proxy login banner and waits to read the user name and password. The format for user names consists of a login ID and a destination host separated by an @ symbol; for example, lionel@manduck.bafb.af.mil. The Telnet proxy validates the user name and password. If an invalid user name or password is sent, the Telnet proxy sends an error to the user and closes the connection. If the user name or password is valid, the source and destination addresses are checked against the Screen's policy rules. If a match is found, the flags associated with that policy rule are checked. If the connection is permitted, the Telnet proxy opens a connection to the actual destination server and relays data between the source host and the destination host.

The hostname (backend server) given in the user prompt, after the @ character, is translated to its IP address using the hostname-to-address translation mechanism configured for and in the context of the Telnet proxy. The resulting addresses provide the values to use as matching criteria for the destination addresses in the proxy rules.

The standard proxy rule matching is employed (see "Policy Rule Matching"). If a match is found, a connection is established to the Telnet server of the user-requested destination. If multiple addresses result from the translation of the user-specified backend server, they are each tried in the order yielded by the name translation mechanism (for example, DNS). Once a connection to the backend server is established, all data are relayed (uninspected) by the thread in both directions until either end terminates.

Other Telnet Proxy Issues

The Telnet proxy uses TCP keep-alives on the connection to the client. The Telnet proxy insists on doing its own echoing during the initial user authentication portion of the session. Some Telnet client programs do not obey standard Telnet echo negotiation and improperly double-echo username@hostname input and single-echo the password.

By configuring the Telnet proxy on a Screen, the Telnet service into that system becomes unavailable. To avoid confusion, define the destination address of proxy rules so as to exclude all the addresses of your Screens. (You can still use the rlogin protocol to access the Screen, as necessary, and telnet out.)

Telnet Proxy Use

Before a client can connect to a remote host when the Telnet proxy is active, the client must first connect to the Telnet proxy. In the following example, the Telnet proxy is running on the host Screen, and the user wants to connect to the remote system foo.com.

riyal% telnet Screen
SunScreen Telnet Proxy Version: 3.2
Username@Hostname: edison@foo.com

At the password prompt, you type the password for the proxy authentication. The Telnet proxy would compare the specified user name and password to the list of valid proxy users and their passwords. If the user name/password are correct and the connection is allowed, the user is presented with a login banner for the machine foo.com.

Using Encryption With Proxies

You can have the Screen decrypt incoming traffic from a client before passing it to the proxy by creating two rules. The following is an example of using the Telnet proxy with SunScreen SKIP:

edit> add rule telnet proxyclient localhost SKIP_VERSION_2 ...
edit> add rule telnet proxyclient proxyserver PROXY_TELNET

Likewise, you can have the Screen encrypt the connection from the proxy to the backend server using a similar pair of rules:

edit> add rule telnet localhost proxyserver SKIP_VERSION_2 ...
edit> add rule telnet proxyclient proxyserver PROXY_TELNET