|
|
| Previous | Table of Contents | Next |
Gopher Functions
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.
| Function | Description |
|---|---|
| dir | Fetching Gopher menus Getting a directory listing via FTP Fetching an HTML document (this is being studied) |
| read | Fetching a file of any type HTML files are treated as read even though they are also of dir format |
| write | Putting a file of any type Needs plus because it is 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, such as telnet. (See “Security.”) |
Security
The most important security configuration you need to be aware of is the way certain functions are handled by the client, server, and proxy programs. When the client wants to perform certain actions, such as telnet, the client program often runs the telnet command to perform the function. If the client passes arguments to the program, there is a chance of rogue commands along with the intended command. Gopher requests to do FTP operations cause the server to run the FTP program. Again, the server could be tricked into running rogue commands with the commands to run the FTP program.
Most client programs only know how to display a small number of data types; they rely on external viewers to handle the other data types. Again, this arrangement jeopardizes security because of the chance that client programs can be tricked into running rogue commands.
Installation
To install http-gw place the executable in a system area, then modify /etc/inetd.conf. The TCP service port on which to install the Gopher/HTTP proxy depends on local site configuration. You would normally configure the proxy to be on ports 70 and 80. 70 is the normal Gopher port and 80 is the normal HTTP port. After inetd.conf has been modified, restart or reload inetd. Verify installation by attempting a connection and monitoring the system logs.
Typical configuration of the proxy in a firewall situation involves rules to block all systems that are not in the DNS from using the proxy, but to permit all systems on the internal protected network to use the proxy, as in this example:
http-gw: deny-hosts unknown http-gw: hosts 192.33.112.* 192.94.214.*
Synopsis
login-sh (invoked from /bin/login)
Description
login-sh provides a simple interface to the authentication service for login by replacing the user’s login shell with a “wrapper” that requires the user to authenticate first; the program then executes the real login shell. login-sh may be used in conjunction with or as a replacement for passwords in the password file /etc/passwd. The user’s actual login shell information is stored in an external file.
Note that login-sh runs as the user with his or her permissions. This is attractive because it separates the authentication policy from the permissions granting policy (/bin/login).
Options
login-sh reads its configuration rules and permissions information from the firewall configuration table netperm-table, retrieving all rules specified for “login-sh.” The following configuration rules are recognized:
authserver address port
This command specifies the network address and service port of the authentication server to use.
shellfile pathname
The shellfile command specifies a file containing information about users’ login shells (the shell configuration file). Empty lines and lines with a pound sign (#) as the first character are discarded or treated as comments. The format of the shell configuration file is a list of entries, one per line:
userid executable parameter-0 [parameter-1] [parameter-n]
The first three values must be defined. The userid field matches the login name of the user invoking login-sh from the /etc/passwd file. The second field should specify the executable pathname of the program to run after authentication is completed. The third and remaining fields are parameters to pass to the executable program, starting at parameter zero. Many command interpreters check the name of parameter zero (argv[0]) to determine if they are login shells. When you use these command interpreters, make sure you define them with their required format—typically a leading dash “-.”
Installation
To install login-sh place the executable in a system area, and then define the shellfile and authserver options in netperm-table. Systems that are using login-sh should have all programs that permit users to change their login shells disabled, or should have the setuid bit stripped.
File entries for users’ passwords should resemble this example:
mjr::100:10:Marcus J Ranum:/home/mjr:/usr/local/etc/login-sh
A sample shellfile entry for mjr is shown here:
mjr /usr/bin/ksh -ksh
Note in the example that the pathname (/usr/bin/ksh) and the first parameter for the program (“-ksh”) are different. A minimum of two parameters must exist for each login shell that is defined.
Users who want both password authentication and secondary authentication can set passwords on their entries in /etc/passwd and also use login-sh.
Synopsis
netacl servicename (invoked from inetd)
Description
netacl provides a degree of access control for TCP-based services invoked from inetd(8). When a server is started, inetd invokes netacl with the name of the service requested, rather than the actual server. netacl then searches its permissions information (read from netperm-table ) to see if the host initiating the connection is authorized. If the host is authorized, the real server process is invoked; otherwise, netacl exits. Acceptance or rejection of the service is logged through the syslog facility.
netacl duplicates functionality found in other tools such as log_tcp by Wietse Venema, but is included with the Toolkit because it is a simpler implementation, contains no support for UDP services, and shares a common configuration file with the rest of the Toolkit components.
| Previous | Table of Contents | Next |