|
|
| Previous | Table of Contents | Next |
When this type of setup is in operation, a user who is trying to use the proxy from this machine receives a Sorry, access denied error message.
The permit-host rules can include function definitions that are permitted or denied depending on the established criteria in the rule. The proxy characterizes each transaction as one of a number of functions. For the deny options the request is used; for filter options the returned selectors are used. These functions are listed in table 6.14.
| Function | Description |
|---|---|
| dir | Fetching Gopher menus. Getting a directory listing via FTP. Fetching an HTML document. |
| read | Fetching a file of any type. HTML files are treated as read even though they are also dir. |
| write | Putting a file of any type. Needs Gopher+ since only available to Gopher+ and HTTP/1.x. |
| ftp | Accessing an FTP server. |
| plus | Gopher+ operations. HTTP methods other than GET. |
| wais | WAIS index operations. |
| exec | Operations that require a program to be run; that is, telnet. |
Function controls enable the firewall administrator to specifically set up what will and will not be allowed to pass through the proxy. If no deny or permit functions are specified, every function is permitted. Consider, for example, a setup that would not allow file transfers using the -deny ftp command:
http-gw: userid www # http-gw: directory /usr/local/secure/www http-gw: timeout 1800 http-gw: default-httpd www.fonorola.net http-gw: default-gopher gopher.fonorola.net http-gw: permit-hosts 206.116.65.* -deny ftp # http-gw: deny-hosts 206.116.65.2 http-gw: deny-hosts unknown
By using this deny request to restrict the use of the ftp command, users can no longer request an FTP session through the http-gw proxy. A sample error message would look like:
use file fig11.pcx
In this configuration, any attempt to establish an FTP session using either the following syntax or a WWW page will result in failure:
ftp://ftp.somewhere.com
Note: If you are concerned about FTP transfers, and you have disabled the ftp-gw proxy to prevent FTP transfers, you need to carefully consider the value of disabling the ftp commands in the HTTP protocol set. Closing one door but leaving a related one open is not wise.
Few of the current Gopher clients are capable of interacting as well as proxy-aware WWW clients. To use a Gopher client, you must configure the default Gopher server that is used to establish the connection to the firewall. From here you will have to configure jumping off points to different Gophers.
Because of the looming difficulty associated with Gopher clients, the use of Gopher via the World Wide Web interface is popular and widely accepted. Clearly, this capability indicates that there is more flexibility within the HTTP architecture.
The x-gw X Windows proxy is provided to allow a user-level X Windows interface that operates under the tn-gw and rlogin-gw access control. Recall from the earlier discussion of the tn-gw command that this command enables an X session through the gateway.
The proxy operates by allowing clients to be started on arbitrary hosts outside the firewall, and then requesting a connection to the specified display. When the X connection request by the client is made, the x-gw proxy displays a window that is running on a virtual display on the firewall. Upon receiving the connection request, x-gw displays the window on the user’s real display. This display prompts for confirmation before proceeding with the connection. If the user agrees to accept the connection, x-gw passes the data from the virtual display to the user’s real display.
The x-gw proxy can be started from a telnet or rlogin sequence, as shown by this output:
% telnet pc Trying 206.116.65.3… Connected to pc.unilabs.org. Escape character is ‘^]’. pc.unilabs.org telnet proxy (Version V1.3) ready: tn-gw-> x tn-gw-> exit Disconnecting… Connection closed by foreign host.
At this point a window pops up on the user’s display that shows the port number of the proxy to use; the window also serves as the control window. Choosing the Exit button will close all multiple X connections.
Although the x-gw proxy is advanced and user-friendly, some issues concerning this proxy need to be mentioned. The major issue is that this proxy relies on the X11 Athena Widget set. If your system does not have the X11 libraries or the Athena Widget set, this proxy will not compile, and you will be forced to live without it. Fortunately, very few people allow the use of X windows applications through their firewall.
The TIS Firewall Toolkit includes extensive authentication mechanisms. The TIS authentication server consists of two components: the actual server itself, and a user authentication manager, which is used to interact with and configure the server.
The authentication server, known as authsrv, is designed to support multiple authentication processes independently. This server maintains an internal user database that contains a record for each user. The information stored for each user consists of:
Passwords may be plaintext for local users, or encrypted for all others. The only time plaintext passwords would be used is when the administrator wants to control access to firewall services by users on the protected network.
Warning: Plaintext passwords should never be used for authentication by users on non-secure networks.
Users in the authsrv database can belong to different groups; a group administrator can be named who can only manage the users in that group. authsrv also contains support for multiple forms of authentication, including:
Note: The Bellcore S/Key mechanism that is included with the Toolkit does not include the complete software. You can register for the S/Key distribution at http://www. bellcore.com/SECURITY/skey.html.
| Previous | Table of Contents | Next |