Authentication

Unless the user is employing a version of the FTP client program that has support for authentication through challenge/response, he or she will be required to employ the quote command to communicate directly with the proxy. For authentication, the proxy recognizes the following options:

authorize username
auth username (shorthand form)
response password
resp password (shorthand form)
If the proxy requires authentication, attempts to use the service requested
will  not be permitted.
% ftp gatekeeper
Connected to gatekeeper.
220 gatekeeper FTP proxy (Version 1.0 stable) ready.
Name (host:user): user@somplace
500 command requires user authentication
Login failed.
ftp> quote auth mjr
331 Challenge “655968”
ftp> quote response 82113
230 Login Accepted
ftp> user user!@somplace
331-(----GATEWAY CONNECTED TO someplace----)
331-(220 someplace FTP server (Version 5.60/mjr) ready.)
331 Password required for user.
Password:

Unfortunately, whenever the quote command is used passwords are visible. If authentication is being used, it should be of a changing-password or token authentication form, to eliminate the threat of passwords being seen or tapped through a network.

Installation

To install ftp-gw, place the executable in a system area, then modify /etc/inetd.conf. The TCP service port on which to install the FTP proxy will depend on local site configuration. If the gateway machine that is to run the proxy does not require the presence of local FTP service, the proxy can be installed on the FTP service port. If the firewall doubles as an anonymous FTP archive, the proxy should be installed at another port.

To use the proxy there, the FTP client application ftp must support the use of an alternate service port. Most BSD Unix versions of the FTP client do, but some PC or Macintosh versions do not. After inetd.conf has been modified, restart or reload inetd. Verify installation by attempting a connection, and then monitoring the system logs.

Typical configuration of the proxy in a firewall setup includes the use of rules, which block all systems that are not in the DNS from using the proxy, but permit all systems on the internal protected network to use the proxy. Here is an example:

ftp-gw:  deny-hosts unknown ftp-gw:  hosts 192.33.112.*

192.94.214.* -log { retr stor }

http-gw—Gopher/HTTP Proxy

Synopsis

http-gw [ options ] (invoked from inetd)

Description

http-gw provides Gopher and HTTP proxy services with logging and access control. This program allows Gopher and Gopher+ client to access Gopher, Gopher+, and FTP servers. It also allows WWW clients such as Mosaic to access HTTP, Gopher, and FTP servers. Both standard and proxy-aware WWW clients are supported. The proxy supports common use of the Gopher, Gopher+, and HTTP protocols. Except where noted, client means Gopher, Gopher+, WWW, or proxy-aware WWW clients; server means Gopher, Gopher+, HTTP, or FTP servers.

Proxy-aware clients should be configured to use the proxy. Non-proxy-aware clients should be set up so that their HOME PAGE is the proxy. If you are installing a firewall on a system that already includes users with Gopher or WWW access, these users need to edit their Hotlists to route the requests through the proxy.

•  WWW (URLs). Insert the string http://firewall/ in front of the existing URL.

•  Gopher. Change the Gopher menu information from

Host=somehost
Port=someport
Path=somepath

to

Host=firewall
Port=70
Path=gopher://somehost:someport/somepath

This example assumes that the proxy has been configured to be on the default HTTP and Gopher ports (80 and 70, respectively).

Options

•  -d file. This option can only be used if the proxy was compiled with BINDDEBUG. It allows debugging information to be written to the specified file.

•  -D. This option turns on the debugging log if specified. The proxy must be compiled with BINDDEBUG for the option to be recognized.

Operation

http-gw is invoked from inetd(8); it reads its configuration and checks to see if the system that has just connected is permitted to use the proxy. If not, it returns a message/menu and logs the connection. If the peer is permitted to use the proxy, http-gw reads in a single line request, which it then decodes. If needed, more lines are read from the client. Most requests carry the information that the proxy needs in the first line.

When a user initiates a request, the client determines three pieces of information: host, port, and a selector. The client then connects to the host on the port and sends the selector. When using a proxy, the host and port refer to the proxy itself. The proxy has to determine the host and port from information contained in the selector. The proxy does this by re-writing the information it passes back to the client. Both Gopher and WWW clients do none or only minimal processing on the selector. If the proxy cannot find its special information in the selector, it looks in its configuration file to see if a server has been defined to which it can hand off the request.

The proxy has to process three types of information:

•  Gopher menus. These contain a description (displays for the user), a selector, a host, and a port. The first character of the description tells the client the type of information to which the entry refers.

•  HTML files. Contains hypertext that can contain embedded links to other documents. The proxy has to parse the HTML file and rewrite the links so that the client routes the request through the proxy.

•  Other data files. Roughly classified as text or binary data. The proxy passes the data through without changing it.