Several host patterns may follow the “hosts” keyword; the last pattern appears right before the optional parameter, which begins with “-”. Optional parameters include:

-dest pattern
-dest pattern1 pattern2 …

-dest specifies a list of valid destinations. If no list is specified, all destinations are considered valid. The -dest list is processed in the order it appears on the options line. -dest entries preceded with a “!” character are treated as negation entries. For example, the following rule permits hosts that are not in the domain “mit.edu” to be connected.

-dest !*.mit.edu -dest *
-auth

The -auth option specifies that the proxy should require a user to authenticate with a valid user-id prior to being permitted to use the gateway.

-passok

The -passok option specifies that the proxy should permit users to change their passwords if they are connected by the designated host. Only hosts on a trusted network should be allowed to change passwords, unless token-type authenticators are distributed to all users.

Installation

To install tn-gw place the executable in a system area, then modify inetd.conf to reflect the appropriate executable path. The telnet proxy must be installed on the telnet port (port 23) to function properly. This is because many client-side implementations of the telnetd command disable options processing unless they are connected to port 23. In some installations this may cause a dilemma.

In a conventional firewall, where the proxy server is running on a system that does not support user access, one solution is to install tn-gw on the telnet port, and to install telnetd on another port so that the systems administrator still can access the machine. Another option is to permit rlogind to run with netacl protecting it so that only a small number of administrative machines can even attempt to log in. Verify installation by attempting a connection, and monitoring the system logs.

x-gw—X Gateway Service

Synopsis

x-gw [display/hostname]

Description

x-gw provides a user-level X connection service under tn-gw and rlogin-gw access control. Clients can be started on arbitrary Internet hosts, and can then request to display on a virtual display running on the firewall. When the connection request arrives, x-gw pops up a window on the user’s real display asking for confirmation before permitting the connection. If granted, x-gw passes data between the virtual display and the user’s real display.

To run X through the firewall, exceptions have to be made in router configuration rules to permit direct connectivity to ports from 6,000 to 6,100 on internal systems. x-gw searches for an unused lowest port for the X connection, starting from 6,010 and listening for connections.

Each time an X client application on a remote system starts, a control connection window pops up on the user’s screen asking for confirmation before permitting the connection. If granted, the connection is handled by an individual x-gw child daemon to serve multiple simultaneous connections separately with its own buffed data flow. The child daemon cleans up the buffed data and exits if a connection is closed by either end.

Example

The following example illustrates establishing a connection through the telnet proxy, and starting the X gateway:

sol-> telnet wxu
Trying 192.33.112.194…
Connected to wxu.tis.com.
Escape character is ‘^]’.
wxu.tis.com telnet proxy (Version V1.3) ready:
tn-gw-> x
tn-gw-> exit
Disconnecting…
Connection closed by foreign host.

A window pops up on the user’s screen showing the port number of the proxy to use, and acts as the control window. Clicking on the exit button will close all multiple simultaneous X connections.

Options

display/hostname

The display option specifies a destination display where the user wants applications to appear. By default x-gw will use the connecting host name followed by port number: 0.0, if the argument is not specified. The 0.0 port is also a default number if the user sets the display to a host name.

Installation

To install x-gw place the executable in a system area, then modify netperm-table to reflect the appropriate executable path. The location of x-gw is compiled into the components of the firewall Toolkit in tn-gw and rlogin-gw, based on the netperm-table.