test

SunScreen 3.1 Reference Manual

Chapter 10 Proxies

This chapter discusses the proxies used in the SunScreen application. It contains information on:

SunScreen Proxies

A proxy is a user-level application that runs on the Screen. The main purpose of proxies is to provide content filtering (for example, allow or deny Java applets) and user authentication.

SunScreen lets you set up proxies for FTP, HTTP, SMTP, and Telnet traffic protocols. Although each proxy has different filtering capabilities and requirements, you can allow or deny sessions based on source or destination addresses of packets. Proxies share common objects and policy rule files. To start a proxy, you set up rules for a proxy in your security policy and activate the policy.

Use of these proxies does not require installing additional client or server system software. However, some changes may be required in system configurations or user-supplied commands to access protected destinations through the proxies.

The activation process employs a script that checks to see if the policy being activated contains one or more rules that use a given proxy. If so, the corresponding proxy is automatically started. If this same script determines that the Screen has been configured as a SecurID client, then the SecurID PIN server is started as well.

FIGURE 10-1 shows a Screen using a proxy to filter packets for the HTTP protocol.

Figure 10-1 Screen With a Proxy

Graphic

How Proxies Work

Each proxy is a multithreaded program provided with SunScreen. Each is configured through common objects and policy rules. A particular proxy is initiated or reconfigured whenever a policy is activated that contains rules that specify its type of access regulation.

Note -

SunScreen proxies require the facilities of TCP and UDP internet protocols. As such, only Screens with at least one routing-mode (IP-address-bearing) interface can provide proxy services.

Policy Rule Matching

Each proxy is interposed in the middle of rules that reference it by the rule compilation process. In proxy rules, as in other Screen rules, you refer to originating client and destination (or backend) server address objects, not the Screen itself.

Note -

The Screen rule compilation process actually produces two subrules for each proxy-use rule; one that allows client access to the proxy server program, and the other that allows the proxy server program to access the backend server or servers. You do not see these rules as they are hidden but effect a similar kernel-based stateful filtering mechanism to other rules for the Screen. The proxies themselves employ the original proxy-use rules for their own, more detailed, access control mechanisms.

In addition to stateful packet filtering within the Screen kernel, each proxy performs additional rule processing to control access. The additional checking enforces end-to-end (client-to-server) address and service matching, as well as user authentication, command restriction, and content filtering as may be configured.

The general flow of tests that each proxy applies to access requests is:

  1. For FTP and Telnet proxies: Has the user been properly authenticated?

    Note -

    User authentication occurs only once, regardless of the number of rules configured. Authentication is based upon the user identity and accompanying passwords (if any) supplied by interaction with the client host. See Chapter 9, Authentication.

  2. For each rule configured for a particular proxy: Is the requested service port one that is handled by the proxy?

The proxy only receives connection requests for the port or ports on which it is configured to listen.

  1. Is the address of the client contained in the set of source addresses for the policy rule?

  2. Is the address of the backend server (if applicable) in the set of destination addresses for the policy rule?

  3. For HTTP URL references with specific port numbers: Is the target service port allowed by the proxy?

  4. For FTP or Telnet proxies: Is the authenticated user a member of the GROUP proxy user specified in the rule?

As with other Screen rules, these tests are performed in the order in which they appear within the policy. The first rule that matches all tested criteria takes effect with respect to any incoming request for a proxy-provided service. If no rule is found that matches all (applicable) criteria, the requested access is denied.

Proxy User Authentication

The FTP and Telnet proxies of SunScreen provide the ability to restrict access to users who can verify their authenticity.

User authentication mechanisms of SunScreen are described in detail in Chapter 9, Authentication. In this section, the discussion is prefaced by notes that pertain especially to how these user mechanisms are employed by the proxies.

The goals of user authentication within a proxy are to:

A side-effect of establishing an authentic user is a collateral mapping to a backend user identity. This identity is a string that is supplied (by the FTP proxy) as the user of the backend server (for example, a user's userid on Solaris).

The second goal is achieved by the rule matching steps previously described. A rule that references the authentic proxy user itself, or that references a GROUP proxy user that contains an ENABLED member reference to that authentic proxy user, causes a successful user match.

Proxy Limitations

Proxy implementation has the following limitations:

Save Is Not Required With Certain Common Objects

The following common objects that appear in the administration GUI are automatically saved when they are edited or new objects are added:

You do not need to save these objects. Once these objects are added or edited, the change applies immediately and cannot be reversed. The Save button in the administration GUI is greyed out to show that it is inactive.

Note -

Although the changes made to these objects are saved immediately, they do not take effect until a policy is activated. The administration GUI edits authorized users, which are authuser objects; administrative users, which are adminuser objects; or proxy users, which are proxyuser objects; and Java archive (Jar) hashes and Jar signatures.

FTP Proxy

The FTP proxy functions as a relay for the File Transfer Protocol to let you control connections based upon source and destination addresses and user authentication. It can also limit access to certain file transfer commands, such as put and get, based on source or destination addresses and user authentication.

You can configure the FTP proxy to ask for user authentication as an additional mechanism for controlling access to sites and commands.

FTP Proxy Operation

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

The child thread generates an FTP login banner and asks for a user name and password pair. The user name format is proxyuser@server. The password format is proxypass@serverpass, where proxypass is the password for the proxy, and serverpass is the password for the destination FTP server.

The FTP proxy validates the proxyuser name using proxypass as was described previously. The hostname (backend server), given in the USER command after the first @ character, is translated to its IP address(es) using the hostname-to-address translation mechanism configured for and in the context of the FTP 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 (given in the section "Policy Rule Matching") is used. If a match is found, a connection is established to the FTP 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, the proxy attempts to log in using the backend username generated during authentication and using serverpass as the password (see "Proxy User Authentication"). Once the backend user identity is established, commands that are allowed by flags associated with the policy rule in use are relayed, results returned, and files exchanged.

The following example illustrates a session between an FTP connection to a target host (ftp.cdrom.com) using anonymous FTP.


 
Connected to screen
 
220- Proxy: SunScreen FTP Proxy Version 3.1
	:Username to be given
as proxy-user@FTP-server
 
	:Password to be given as proxy-pass@FTP-server-pass
220 Ready
Name (screen:edison): anonymous@ftp.cdrom.com
331-Proxy: Authenticate and
connect
331 Password needed to authenticate anonymous.
 
Password:
	:Authentication mapped anonymous to backend user anonymous
 
	:Connecting to ftp.cdrom.com (165.113.121.81) - done
 
Server: 220 wcarchive.cdrom.com FTP server (Version 2.0) ready
 
Proxy: Login on server as anonymous
Server: 331 Guest login OK,
send your email address as password
Proxy: Supplying password
to server
230-Server:
230-Welcome to wcarchive - home
ftp site for Walnut Creek CD-ROM
230-There are currently 2273
users out of 2750 possible
230 Guest login OK, access restrictions
apply

FTP Proxy and Anonymous FTP

The proxy user anonymous is configured during the installation process as an unauthenticated proxy user. As such, any string provided before the first @ in the password is ignored. The password after the first @ in the password sequence (that is, edison@carter.com) is the backend user password, which, for anonymous FTP, is traditionally the user's email address.

FTP Proxy Use

To use the proxy and make FTP connections, the user must open an FTP connection to the Screen (as shown in the preceding example) rather than open a direct connection to the end system. The Screen's policy rules only allow FTP connections to and from the FTP proxy.

Other FTP Proxy Issues

The FTP proxy does not permit the PASV command (used for third-party transfers).

The FTP proxy has a 10-minute time-out on the control connection for user requests. The responses from the backend server have only two minutes to arrive before timing out.

The maximum number of concurrent sessions available in the FTP proxy daemon is configurable through the variable N_Sessions.

It contains the following items:

As initially installed, a global version of this variable is created that restricts the number of concurrent sessions to 100.

The following is an example of what you would type to display this (initial) variable while logged in to the primary Screen:


>admin% ssadm -r primary edit Initial
edit> vars print prg=ftpp name=N_Sessions
 
PRG="ftpp" NAME="N_Sessions" ENABLED VALUE="100" DESCRIPTION="limit # of concurrent
sessions, FTP proxy"

You can alter this number of sessions, perhaps to be more restrictive, on a particular Screen.

The following is an example of what you would type to do this while logged in to the primary Screen:


edit> vars add sys=Screen 
prg=httpp name=N_Sessions value=66 
description="limit # of concurrent sessions on the Screen FTP proxy"
edit> quit

By configuring the FTP proxy on a Screen, the actual FTP service into that system becomes unavailable. To avoid confusion, define the destination address of proxy rules to exclude all the addresses of your Screen or Screens. (You can still FTP out of the Screen, as necessary.)

HTTP Proxy

The HTTP proxy as currently implemented is a means of filtering Web content for outbound references from Web browsers to external, unknown servers. It does not have the ability to restrict inbound access such as user access control.

The HTTP proxy:

To use the HTTP proxy, define the source addresses that should be allowed to have access to the proxy and to the destination addresses of allowed Web servers to be contacted. To create the HTTP proxy rule, use the built-in service www, reference your desired source and destination addresses, and select the PROXY for PROXY_HTTP during rule definition (in the administration GUI) or the PROXY_HTTP keyword (for command-line rule creation).

The HTTP proxy allows further restrictions based on target port numbers. HTTP provides for user-specified references to arbitrary port numbers using the http://host:port/... construction. Because of the way in which the Screen operates, client browsers can be inadvertently allowed access to services that would otherwise be restricted save for this feature of HTTP.

The port restriction mechanism for the SunScreen HTTP proxy is controlled by the variable TargetSvcs. This variable can either be global or Screen-specific. It contains the following items:

As initially installed, a global version of this variable is created that restricts such access to port 80 (the www service).

The following is an example of what you would type to display this (initial) variable while logged into the primary Screen:


admin% ssadm -r primary edit Initial
edit> vars print prg=httpp name=TargetSvcs PRG="httpp" NAME="TargetSvcs" \ 
ENABLED VALUES={ svc="www" } DESCRIPTION="target TCP ports that the HTTP proxy can get to"

You may wish to be able to have access to a wider range of ports. One such configuration is obtained by configuring a new service object and an added variable (for example, this time, for a particular Screen). The following is an example of what you would type while logged in to the primary Screen: 


>admin% ssadm -r primary edit Initial
edit> add service www-targets SINGLE FORWARD "tcp" PORT
1024-1520 PORT 1522-3850 PORT 3856-5999 PORT 6064-65545 COMMENT "more TCP
port numbers to allow as targets in HTTP proxy URIs"
edit> vars add sys=screen prg=httpp name=TargetSvcs values={ svc=ssl  \ 
srv=www svc=www-targets } description="target TCP ports that the HTTP proxy can get to"
edit> save
edit> quit
Note -

The above definitions prevent access to ports that are below 1024 except for www and ssl. It also prevents access to port 1521 (SQLNET), ports 3851 through 3855 (the Screen's administrative and SecurID PIN server ports), and ports 6000 through 6063 (used by X Windows). Tailor your restrictions to suit your security needs.

The SunScreen HTTP proxy can also be configured to restrict Web content to be allowed through. Content can be blocked or allowed, or it can be configured to verify certain content (Java applets) based on digital signatures or hashes. These content-filtering features are configured as part of the rules employing the HTTP proxy.

HTTP -> FTP Proxy: The ftp:// Method

The HTTP proxy relays access for the ftp:// method to the FTP proxy. This enables users of the browser to list directories and download files. Most often, this facility is employed in conjunction with URLs embedded in web content designed to facilitate file downloading.

The standard form of an ftp:// method URL is as follows:

ftp://user:passwd@host:port/path...type

The user, passwd, port, and type are optional (and not often used by ftp:// method references.) The list of dir components specifies path name of the reference. SunScreen does not implement the port option for ftp:// URLs.

The default behavior of the user and passwd references is to use "anonymous" FTP. A typical URL would then look like:

ftp://codebloat.com/pub/dwnlds/exploder5.exe

Control over the defaulting of user and passwd is obtained using three variables.

  1. FtpPwdDomain contains the following items:

  1. FtpPwdUser contains:

  1. FtpUser contains:

To enable the HTTP proxy to use the ftp:// method, one or more rules are needed to allow the HTTP proxy itself to be a client of the FTP proxy. The HTTP proxy always connects to the FTP proxy using the LOOPBACK (127.0.0.1) address. So, for example, to enable the ftp:// method anonymous access to "outside" web servers:


edit> add address outside ...
edit> add address local127 RANGE 127.0.0.1 127.255.255.255 ...
edit> add rule ftp local127 outside ALLOW PROXY_FTP USER anonymous PROXY_FTP GET CHDIR ...

This enables anonymous FTP through the proxy for any user actually on the Screen itself as well.

HTTP Proxy Operation

When the HTTP proxy starts, it reads its policy files, starts a Java Virtual Machine (JVM) for processing Jar files, and then listens on the standard HTTP port (80) for connections. When a connection is made, the HTTP proxy starts a new thread to handle the connection, and the main thread resumes listening.

The child thread reads the first line of the HTTP header request from the client and parses the actual destination address. The method (for example, http:// or ftp://) is determined. If the ftp:// method has been requested, the request for file retrieval is forwarded to the FTP proxy as described above. Otherwise (for the http:// method) the thread searches the proxy policy rules for a match on the source and destination addresses.

Java Virtual Machine (JVM)

If the body contains a Jar file, the Jar is passed to the JVM, which extracts the signature components and calculates a hash for the Jar. The signatures are compared to the list of approved signatures and if the signatures match and signed Jars are allowed, the data are passed on to the client. If hashed Jars are allowed, the proxy compares the computed hash to the list of approved hash values, and, if a match is found, passes the response to the client.

After all of the data have been passed to the client, the proxy closes the connections to the client and the server and terminates the thread.

Jar Hashes and Signatures

The HTTP proxy is configured on a global basis in the configuration editor to verify the list of acceptable signatures and hash values on Jar content.

Both the Jar hashes and signatures are stored in the vars database.

Note -

Currently, there is no provision to create Screen-specific versions of the Jar hashes and signatures for the Screen

Jar Hashes

The following is an example of what you would type to manage Jar hashes:


edit> jar_hash parameters ...

You can add, delete, list, and rename Jar hashes. You assign the names, which are ephemeral strings. They are used only for purposes of reference to items when managing them using the jar_hash command.

Jar Signatures

You can add, delete, list, or rename Jar signatures. You assign the names, which are ephemeral strings. The names are used only for purposes of reference to items when managing them using the jar_sig command.

HTTP Proxy Limitations

Jar validation facilities acquire the hash and signature values that are added to the configuration.

ActiveX filtering currently blocks certain types of Java content.

SMTP Proxy

The SMTP proxy provides a basic level of control over incoming electronic mail that is based on the Simple Mail Transport Protocol (SMTP). It can be configured to allow or deny such email based on source addresses, the actual server name of the source host, or the server name of the (claimed) originator of a message. It can be further configured to allow or deny relaying of email based on the destined host or server of a message.

SMTP Proxy Operation

When the SMTP proxy starts, it reads its policy files, determines its local server name for use in relay checking, and listens on the standard SMTP port (25) for connections. When a connection is made, the SMTP proxy starts a new thread to handle the connection, and the main thread resumes listening.

The child thread takes control of the connection from the client. It then attempts to reverse-translate the address of the client (from the connection state) to yield a registered name.

If a registered name is discovered, then the suffixes in the mail_spam list are checked against that name. If a suffix matches (the end of) the name of the originating host, the connection is closed with a response (455) refusing reception.

If no name is registered for the address, then the address itself is sought in the mail_spam list (looking for items that contain a single address or a range). If a match is found, the connection is closed with a response (455) refusing reception.

Having passed the peer-address check, the proxy thread next attempts the typical proxy rule match steps (given earlier), except that only the source address is checked. For each rule that matches, an SMTP connection is attempted to the Mail Transfer Agents (MTA) listed as destination for the rule.

Once a connection to a destination server MTA has been established, data are relayed between the client and server MTAs. The content is scanned for commands that introduce source mailbox, destination mailboxes, and the data stream itself. Source mailboxes are checked against the spam list (if any). The destination mailboxes are checked against the relay list

Spam Control

Unsolicited electronic mail is colloquially known as spam. The restriction of mail based on originator is known as spam control. The SMTP proxy provides the ability to define a list of one or more restrictors that operate based on either server name (suffix) or nonserver (address range) criteria.

Spam restrictors have one of two syntactic forms:

server suffix is simply an ASCII character string.

See "SMTP Proxy Operation" for details regarding how these restrictors are used.

Spam restrictors are defined using the command-line interface, and the mail_spam subcommand of ssadm edit in the administration GUI.

The following is an example of what you would type to display the current set of spam restrictors while logged in to the primary Screen:


admin% ssadm -r primary edit Initial
edit> mail_spam list
"total-nonsense.org"
"0.0.0.0..255.255.255.255"

The above example listing shows two entries, one to refuse email from the server or servers with registered address in the domain total-nonsense.org, the other to refuse mail from any host that does not have a registered server name (in a reverse-mapping of IP address to DNS name).

The following is an example of what you would type to add an additional restriction while logged in to the primary Screen:


edit> mail_spam add complete-spam.net
edit> quit

The following is an example of what you would type to remove a restriction while logged in to the primary Screen:


edit> mail_spam delete lite-spam.com

From the command line, in addition to controlling incoming spam destined for your site, another important area of control over email is the limitation on accepting email and then relaying it to another location. Relayed mail is responsible for a great deal of the unsolicited email on the Internet. Improper relaying makes spam harder to defeat and leaves the relaying site open to various types of reprisal from the ultimate recipient-victims.

The SMTP proxy allows the configuration of a set of strings that, coupled with policy rules, enables you to restrict the destination domains that the proxy accepts.

Relay Control

Relay restrictions have one of two syntactic forms:

or

domain suffix is simply an ASCII character string.

See "SMTP Proxy Operation" for details regarding how these restrictors are used.

Relay restrictors are defined using the command-line interface, through the mail_relay subcommand of ssadm edit. The following is an example of what you would type to display the current set of relay restrictors while logged into the primary Screen:


admin% ssadm -r master edit Registry
edit> mail_relay list"your-domain.com"  "!private.your-domain.com"

This listing shows two entries, one to set a base domain to allow in recipients, the other to block a private subdomain in recipients.

The following is an example of what you would type to add an additional restriction (while logged into the primary Screen):


edit> mail_relay add !lists.your-domain.com
edit> quit

The following is an example of what you would type to remove a restriction while logged into the primary Screen


edit> mail_relay delete !test.your-domain.com
Note -

If relay checking is enabled (for example, NO_RELAY) and yet no relay restrictors are configured, the SMTP proxy defaults to allow only the domain configured for the Screen itself as the valid domain for inbound mail.

The SMTP proxy rules should use the smtp service, and specify the PROXY to be PROXY_SMTP during rule definition in the administration GUI. (Or the PROXY_SMTP keyword (for command-line rule creation). The RELAY (or NO_RELAY) flag is used to specify whether to perform unrestricted versus restricted relaying of mail. Use NO_RELAY in conjunction with the mail_relay restrictors shown above to effect relay control.

The following is an example of what you would type, presuming that you already have the following objects defined:


admin% ssadm -r primary edit Initial
edit> list address "mta-primary" HOST 1.2.3.4 ... 
"mta-secondary" HOST 1.2.3.5 ... "outside" GROUP { } { inside } ...

The following is an example of what you would type to define an address group to contain all inside MTAs:


edit> add address mtas GROUP { mta-primary mta-secondary } { ... }

The following is an example of what you would type to define relay restrictors to specify the servers (and perhaps hosts) to be allowed in recipient mailbox names:


edit> mail_relay add prime-server.com
edit> mail_relay add other-server.com
edit> mail_relay add !lists.prime-server.com
edit> mail_relay add !private.other-server.com

The following is an example of what you would type to define spam restrictors to deny mail from some mail originators you know to be sources of unsolicited mail:


edit> mail_spam add 0.0.0.0..255.255.255.255
edit> mail_spam add dialups.naughty-isp.net

Finally, the following is an example of what you would type to define a rule to cause inbound email to pass through the SMTP proxy:


edit> add rule smtp outside mtas ALLOW PROXY_SMTP NO_RELAY
edit> save
edit> quit
Note -

Because of the way that SunScreen represents addresses (in numerical order by IP address), rules that refer to multiple destination addresses give rise to attempting the MTA connection in numerical order. To obtain finer control over MTA connection ordering, use multiple rules.

Once a connection is established to a willing backend MTA, the proxy thread begins watching information passed by the client to the server (ordinarily, the proxy does not talk to the client). The proxy looks for a MAIL FROM: command from the client. (This command gives the name of the user who originated the message. It is often abused by spam message creators, so its use is often untrustworthy.) The mailbox name in this command is compared with the suffixes in the mail_spam list and if found there, the connection is aborted with a response (455) refusing reception.

Next, the proxy thread looks for one or more RCPT TO: commands from the client. (Such commands give one of the destination mailboxes to which the message is directed. Unlike the MAIL FROM: command, this mailbox name is always a real recipient.) If the rule specifies NO_RELAY, then the mailbox names in these commands are compared against the mail_relay list. The search can be conceptually thought of as a two-pass search. On the first pass, any denial suffixes (ones beginning with !) are sought and if matched, cause a connection abort with a response (454) refusing reception. On the second pass, allowance suffixes are sought (ones not beginning with !). If one matches, the recipient is allowed; if none matches, the connection is aborted with a response (454) refusing reception.

SMTP is designed to allow multiple messages (each with one or more recipients) to pass on a single connection. Barring a refusal of service, once all messages have been passed, the proxy closes the connection to the client and backend server and ends the child thread.

Other Mail Configuration Issues

In addition to specifying SunScreen SMTP proxy policy, configuration steps must be taken to cause SMTP-based email to arrive at the proxy for delivery to the servers it is to represent. The typical mechanism is to create MX records in the Domain Name System (DNS) for those servers. The procedure for altering DNS configuration is outside the scope of this document but should be very familiar to your DNS administrator.

More than one Screen can be configured to operate in parallel to service incoming mail. The multiple Screen management features of SunScreen make doing so a relatively straightforward task. These parallel Screens can then be used within MX records.

By configuring the SMTP proxy on a Screen, the actual SMTP (inbound email) service into that system becomes unavailable. (You can still send email out of the Screen, as necessary.)

SMTP Proxy Rules

After configuring the content filtering, the final step is to create one or more rules that actually allow SMTP-based email to be served. A typical configuration often allows outside email to be filtered through the proxy to one or more inside message transfer agents (MTA) such as Solaris mail servers.

The source address for SMTP proxy rules should allow mail from any potential mail-sending address. Restrictions on source addresses in the rule can be useful in blocking entirely-abusive mail-originating sites that are stationary with respect to IP addressing.

The destination address for SMTP proxy rules should contain the addresses of one or more MTAs to which the proxy will connect to actually store and forward the incoming email.

Telnet Proxy

The Telnet proxy provides a virtual terminal relay. It 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/password. If an invalid user name/password is sent, the Telnet proxy sends an error to the user and closes the connection. If the user name/password is valid, then 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(es) 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 (described in the section "Policy Rule Matching") is employed. 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 is relayed (uninspected) by the thread in both directions until either end terminates.

Other Telnet Proxy Issues

The Telnet proxy used 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.

Note -

By configuring the Telnet proxy on a Screen, the actual Telnet service into that system becomes unavailable. To avoid confusion, define the destination address of proxy rules so as to exclude all of your Screen(s) addresses. (You can still use the rlogin protocol to access the Screen, as necessary, as well as being able to 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.1
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 SKIP Encryption with Proxies

You can have the Screen decrypt incoming traffic from a client before passing it to the proxy. It requires 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