test

SunScreen 3.2 Administrator's Overview

Chapter 10 Proxies

A proxy is a user-level application that runs on the Screen. The main purpose of proxies is to provide content filtering and user authentication. This chapter discusses the proxies used in the SunScreen application. It contains information on:

SunScreen Proxies

SunScreen enables you to 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 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.

With SunScreen 3.2, filtering of scripts, applets, and viruses in downloaded content is possible using VirusWall, which is separately licensed from TrendMicro, Inc. See information about VirusWall scanning in "HTTP Proxy", "SMTP Proxy", and "VirusWall Content Scanning".

The figure below 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 one that allows the proxy server program access to the backend servers. These rules are hidden. They 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.

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

  1. For FTP, Telnet, and (optionally) HTTP 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 ports on which it has been 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, Telnet, and (optionally) HTTP 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, Telnet, and (optionally) HTTP proxies of SunScreen provides 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:

Automatically-Saved Common Objects

The proxies use the following common objects:

Once these objects are added or edited, the change is stored immediately and cannot be reversed. The Save button in the administration GUI is greyed out to show that it is inactive. Although the changes made to these objects are saved immediately, they do not take effect until a policy is activated.

FTP Proxy

The FTP proxy functions as a relay for the File Transfer Protocol to enable 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 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 is used (see "Policy Rule Matching"). 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.


#ftp screen 
Connected to screen
220- Proxy: SunScreen FTP Proxy Version 3.2
	:Username to be given as proxy-user@FTP-server
 	:Password to be given as proxy-user@FTP-server-password@
220 Ready
Name (screen:edison): anonymous@ftp.cdrom.com
331-Proxy: Authenticate & connect
331 Password needed to authenticate 'anonymous'.
Password: [password is not echoed]
	: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 Password to server.
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.
Remote system type is UNIX.
Using binary mode to transfer files.

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 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 into 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 into 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 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.

The HTTP proxy:

Note -

When you use your HTTP proxy in conjunction with VirusWall scanning, your HTTP proxy examines Web content for malicious scripting language code and executable content, and scans downloaded data for possible computer viruses. The scanner instructs that the content be blocked, or altered (for example, clean viruses from the content), or returned unaltered. Scanning results are recorded in the SunScreen log entries regarding HTTP transfers. See "VirusWall Content Scanning" for detailed information about VirusWall.

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).

To require user authentication of HTTP traffic through the proxy, the USER keyword may be used in rule creation on the command line; equivalently, a proxyuser object may be associated with PROXY_HTTP rules within the rule manipulation facilities provided by the Admin GUI. This usage is similar to that of the FTP and Telnet proxies, but for the HTTP proxy, user authentication is optional.

HTTP Proxy Port Restrictions

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"

To have access to a wider range of ports configuring a new service object and an added variable (for example, this time, for a particular Screen) is one way of doing this. The following example show what you type while logged into 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   
svc=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 (which are used by X Windows). Tailor your restrictions to suit your security needs.

You can configure the SunScreen HTTP proxy to restrict Web content.You can block or allow content, or you can be configured to verify certain content (Java applets) based on digital signatures or hashes. You configure these content-filtering features as part of the rules employing the HTTP proxy.

HTTP Proxy Access for ftp://

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

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

ftp://user:passwd@host:/dir...type

The user, passwd, and type are optional (and not often used by ftp:// method references.) The list of dir components specifies path name of the reference. Note that 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 -- FtpPwdDomain, FtpPwdUser, and FtpUser -- each of which is described below.

FtpPwdDomain contains the following items:

FtpPwdUser contains:

FtpUser contains:

T:o 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 FTP_GET FTP_CHDIR

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

HTTP Proxy User Authentication

As previously stated, the HTTP proxy can optionally require users to authenticate themselves. The addition of a USER attribute to a rule, along with an associated proxyuser object name, will cause requests to require authentication (based on the source and/or destination addresses within the rule).

HTTP proxy authentication uses the same mechanisms as other proxies. See Chapter 9, Authentication for information about SunScreen user authentication mechanisms.

The SunScreen HTTP proxy supports the Basic HTTP authentication method and provides several HTTP proxy authentication variables for configuring the method.

These variables do not normally need alteration, and come prefigured for immediate operation. The variables are:

The Basic authentication mechanism allows use of a Realm name; this realm name is displayed by the user's browser as part of the authentication, and is intended to be useful in identifying the collection of resources being protected by authentication. It is an authentication mechanism between the user and the programs he or she wants to access. The administrator knows about this and other kinds of authentication associated with a firewall, but an end user may not. The realm variable identifies who or what is interposing this authentication on the proxy. What the user sees in the password process of the browser varies depending on how these variables are set. The word "SunScreen" could be replaced with some company-specific term, for instance.

authttl is a timeout, constructed of an unsigned number, followed optionally by one of the scaling characters (d, h, m, or s). These indicate time units of days, hours, minutes, or seconds, respectively. The scaling characters are case-insensitive, and the default unit scale is seconds.

Credentials for proxy authentication are stored by the browser and offered repeatedly with subsequent requests. This functionality prevents annoying the user with many such challenges, which would otherwise render web browsing unusable. However, the SunScreen administrator is allowed to place a reasonable upper limit on the amount of time a given browser instance (or group of instances) will be allowed to reuse the same credentials without requalification. Tailoring this variable restricts the time which an unattended browser might be usable by another party before the latter would be required to re-authenticate. The AuthBasicTTL variable controls this time-to-live setting for credentials using the Basic authentication method.

HTTP Proxy Operation

When the HTTP proxy starts, it reads its policy files, starts a Java Virtual Machine (JVM) for processing Jar (Java archive) 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 is 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 type to manage Jar hashes:


edit> jar_hash parameters 

You can add, delete, list, and rename Jar hashes. You assign names, which are ephemeral strings. Names are used only to reference 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.

The SMTP proxy can be configured to scan the content of incoming electronic mail messages for virus and other malicious content.

Note -

When you use your SMTP proxy in conjunction with VirusWall scanning, your SMTP proxy examines email attachments for malicious scripting language code and executable content, and scans downloaded data for possible computer viruses. The scanner instructs that the content be blocked, or altered (for example, clean viruses from the content), or returned unaltered. Scanning results are recorded in the SunScreen log entries regarding SMTP transfers. See "VirusWall Content Scanning" for detailed information about VirusWall.

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, 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.

If it passes the peer-address check, the proxy thread next attempts the typical proxy rule match steps ("Policy Rule Matching"), except that only the source address is checked. For each rule that matches, an SMTP connection is attempted to the message 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.

If configured for content scanning, the body of the e-mail messages which pass the above-mentioned spam and access control mechanisms, are fed to the scanner for inspection. The scanner may instruct that the content be blocked, or may alter the content (clean viruses from it, for example) , or may return it unaltered. Scanning which results in content alteration is reflected in the e-mail messages so modified.. Scanning results are recorded in the SunScreen log entries regarding SMTP transfers.

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 configuration editor, and the mail_spam subcommand of ssadm edit in the administration GUI.

Examples

Below are examples of working with spam restrictors.

Relay Control

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 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 configuration editor, through the mail_relay subcommand of ssadm edit. The following is an example of what you 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 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 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 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 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 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

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 attempt 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 information 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 allows 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 centralized management group feature of SunScreen makes 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 allow SMTP-based email to be served. A typical configuration often allows filtering outside email 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 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 store and forward the incoming email.

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.

Note -

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

VirusWall Content Scanning

This section describes how to configure your SunScreen HTTP or SMTP proxy to use the separately-licensed TrendMicro VirusWall content scanning option. Once you have installed and configured the VirusWall product on a server platform, you can direct your SunScreen HTTP or SunScreen SMTP proxy to use it for content examination. See "VirusWall Setup Issues" for information about installing, configuring, and using VirusWall.

HTTP Proxy Access to VirusWall

Access to the VirusWall server from within the HTTP proxy is controlled by a service common object (viruswall-http)and a pair of variables (VirusWallServerHTTP and scan.0). The service object and variables are preconfigured as much as possible during installation, but the variables must be altered to activate the interface for scanning. In addition, you may need one or more access rules to allow your Screen access to the VirusWall scanner server; see "To Add an Administrative Access Rule for Remote Administration" in SunScreen 3.2 Administration Guide for more information.

The viruswall-http service common object is employed by the interface between SunScreen's HTTP proxy and VirusWall. The TCP service port defined for this object is set to that used by the default VirusWall installation.

VirusWallServerHTTP Variable

The VirusWallServerHTTP variable configures the interface between your Screen and VirusWall:

Options for the vwvalues portion of the VirusWallServerHTTP variable are:

Note -

Multiple addr items can be configured to allow the use of secondary scanning servers. Each addr item can designate address common objects by name or it can designate a naked (dotted-quad) IP address.

scan.0 Variable

The second variable, scan.0, connects the first variable to the proxy and specifies it as the first scanning facility to be used by that proxy. Because VirusWall scanning is optional, scan.0 is predefined as DISABLED. To turn on scanning, you must set the scan.0 variable to ENABLED.

For the variable scan.0, the scvalues portion is name=VirusWallServerHTTP. Note that the value of this variable is the name of the first variable.

Both variables--VirusWallServerHTTP and scan.0--are pre-defined. If you display their values from the command line configuration editor, you see:


admin% ssadm -r primary edit Initial
edit> vars print prg=scan name=VirusWallServerHTTP
PRG="scan" NAME="VirusWallServerHTTP" ENABLED
VALUES={ type="VirusWall" svc="viruswall-http" addr="viruswall-server" }
DESCRIPTION="TrendMicro HTTP scanning server(s)" 
edit> vars print prg=httpp name=scan.0 
PRG="httpp" NAME="scan.0" DISABLED VALUES={ name="VirusWallServerHTTP" }
DESCRIPTION="HTTP proxy content scanner"

HTTP Access Rules

One or more access rules may be needed to allow your Screen access to the VirusWall scanner server (see "To Add a New Rule" in SunScreen 3.2 Administration Guide.

Because VirusWall scanning is optional, and because the viruswall-server address object cannot be preconfigured during installation, the following example shows prototypical post-installation steps to enable VirusWall scanning of HTTP content:


admin% ssadm --r primary edit Initial
edit> add address viruswall-server 10.73.176.13
edit> add rule viruswall-http localhost viruswall-server ALLOW
edit> add rule www 'inside' web-scanner ALLOW PROXY_HTTP 
edit> vars add prg=httpp name=scan.0 ENABLED 
VALUES={ name=VirusWallServerHTTP } DESCRIPTION="HTTP proxy content scanner"

This example:

If content scanning has been configured, and once proxy-based content checks have been performed, the resulting content is passed to the scanner for inspection. The scanner may instruct that the content be blocked, or may alter (for example, clean viruses from) the content, or may return it unaltered. You receive scanning results (as being blocked, if so determined) that are reflected in SunScreen log entries regarding the HTTP request and its results.

SMTP Proxy Access to VirusWall

Access to the VirusWall server from within the SMTP proxy is controlled by a service common object (viruswall-smtp)and a pair of variables (VirusWallServerSMTP and scan.0). The service object and variables are preconfigured as much as possible during installation, but the variables must be altered to activate the interface for scanning. In addition, you may need one or more rules to allow SunScreen firewall access to a VirusWall scanner that is operating on a separate server platform.

The viruswall-smtp service common object is employed by the interface between SunScreen's SMTP proxy and VirusWall. The TCP service port defined for this object is set to that used by the default VirusWall installation.

VirusWallServerSMTP Variable

The VirusWallServerSMTP variable configures the interface between your Screen and VirusWall:

Options for the vwvalues portion of the VirusWallServerSMTP variable are:

Note that multiple addr items can be configured, allowing the use of secondary scanning servers. Each addr item can designate address common objects by name, or may give a naked (dotted-quad) IP address.

scan.0 Variable

The second variable, scan.0, connects the first variable to the proxy and specifies it as the first scanning facility to be used by that proxy:

For the variable scan.0, the scvalues portion is name=VirusWallServerSMTP. Note that the value of this variable is the name of the first variable.

Both variables--VirusWallServerSMTP and scan.0--are pre-defined. If you display their values from the command line configuration editor, you would see:


admin% ssadm -r primary edit Initial
edit> vars print prg=scan name=VirusWallServerSMTP
PRG="scan" NAME="VirusWallServerSMTP" ENABLED
VALUES={ type="VirusWall" svc="viruswall-smtp" addr="viruswall-server" }
DESCRIPTION="TrendMicro SMTP scanning server(s)" 
edit> vars print prg=smtpp name=scan.0 
PRG="smtpp" NAME="scan.0" DISABLED VALUES={ name="VirusWallServerSMTP" }
DESCRIPTION="SMTP proxy content scanner"

SMTP Access Rules

One or more access rules may be needed to allow your Screen access to the VirusWall scanner server.

Because VirusWall scanning is optional, and because the viruswall-server address object cannot be preconfigured during installation, the following example shows prototypical post-installation steps to enable VirusWall scanning of SMTP content:


admin% ssadm --r primary edit Initial
edit> add address viruswall-server 10.73.176.13
edit> add rule viruswall-smtp localhost viruswall-server ALLOW
edit> add rule smtp 'inside' mail-server ALLOW PROXY_SMTP 
edit> vars add prg=smtpp name=scan.0 ENABLED 
VALUES={ name=VirusWallServerSMTP } 
DESCRIPTION="SMTP proxy content scanner"

If content scanning has been configured, and once the aforementioned proxy-based content checks have been performed, the resulting content is passed to the scanner for inspection. The scanner may instruct that the content be blocked, or may alter (for example, clean viruses from) the content, or may return it unaltered. You receive scanning results (as being blocked, if so determined) that are reflected in SunScreen log entries regarding the SMTP request and its results.

VirusWall Setup Issues

This section discusses the general issues of using SunScreen in conjunction with the VirusWall content scanning option once you have set up and configured your SunScreen HTTP or SMTP proxy.

Currently, SunScreen interoperates with VirusWall, version 3.32, for the Lucent Managed Firewall specifically. Only this version contains the necessary interface protocol that allows SunScreen to use the scanning facilities of VirusWall for HTTP or SMTP content. Aside from representing some hardware and software duplication issues, it also creates some additional security risks that you must minimize.

Windows environments are apt to imbed the need to run the Internet Explorer (IE) Web browser and can further require you to run Active-X as well as enable other executable content within the browser. Because Active-X and its kindred effectively run as root on an Administration Station, the potential for security compromise is immediately obvious. To minimize the potential for viral infection of the VirusWall platform, restrict the access that platform has to net traffic to the extent possible.

This restriction takes two forms:

Place VirusWall on its own, separate SunScreen interface to effect physical isolation of the VirusWall platform. Should your system be compromised, this isolation defeats the possibilities that VirusWall:

To effect access restrictions, your system only needs to interact with other hosts in the following ways:

Only the first three access paths are mandatory for the scanning operation of the product, and only the first five access paths are mandatory for full operation of the product.

Note -

It is recommended that you not use this system for any other purpose.

For you to effect the above security environment, contact TrendMicro for a definitive list of servers to which your VirusWall server needs access. Also, you can request written disclosures or privacy policies regarding all interactions between the VirusWall server you are deploying and TrendMicro's servers.

Once the Viruswall and related software is fully loaded, consult your product documentation or TrendMicro technical support for any questions regarding VirusWall configuration settings or options.

To test the access paths from the HTTP or SMTP proxy, browse the Web or cause inbound email to flow through your VirusWall-enabled SunScreen proxy. The SunScreen logs contain annotation of the added scanning activities.

Also, set LOG_SESSION on the rules to enable the downloading of pattern files from TrendMicro, and any other outbound connections you elect to allow for optional paths. More detailed information about pattern downloads can be obtained from the VirusWall configuration facilities (either Windows application or browser based).