|
|
| Previous | Table of Contents | Next |
When compiling authsrv,the administrator needs to decide which authentication forms will be supported locally. It is typical to find multiple forms in use by a single company depending on cost and availability. For each proxy in the Toolkit, authentication can be enabled or disabled, or fit certain criteria, such as incoming must authenticate, and outgoing requires no authentication.
Authsrv should be run on as secure a host as possible, which is generally the firewall itself. To configure the authentication server, you must find an unused TCP/IP port number and add it to /etc/services. For example, if you use port 7777 as the TCP port, the following line would be added to the /etc/services file.
authsrv 7777/tcp # TIS Toolkit Authentication
Authsrv is not a daemon. It runs whenever a connection request is made on the specified TCP port. Consequently, it is necessary to add an entry to the /etc/inetd.conf file, such as this example:
authsrv stream tcp nowait root /usr/local/etc/authsrv authsrv
After the required entries are placed in the /etc/services and /etc/inetd.conf files, inetd must be reloaded or restarted using the kill command. At this point, individual clients must be configured to use the authentication server when required. Keep in mind that not all operations need to require authentication.
To configure a given proxy, you must use the port number and the authserver keyword specifying the host to connect to the authentication server. To see this in action, consider adding authentication to the FTP proxy. For the FTP proxy to be able to use the authentication server, you must tell it to use authserver rule:
# Use the following lines to use the authentication server ftp-gw: authserver localhost 7777
When the FTP proxy is activated, requests must be authenticated. The permit-hosts entry, however, has the flexibility to take advantage of the authentication system. For example, consider the permit-hosts entry in the following:
ftp-gw: permit-hosts 206.116.65.* -log { retr stor } -auth { stor }
The permit-hosts entry says that all retrieve and store file requests to the FTP proxy are logged, and all store file requests are blocked until the user has authenticated. This process will be demonstrated later in this chapter after you learn how to configure the users in the authentication database.
The authentication server must also be configured to accept connections from specific clients. This prevents unwanted attempts to probe the authentication server from hosts running software that needs no authentication. The authentication server reads its rules from the netperm-table, which can include rules listed in table 6.15.
| Rule | Description |
|---|---|
| database pathname | Specifies the pathname of the authsrv database. The database is stored as a dbm(3) file with a third file used for locking. If the software is built with a compiled-in database name, this option need not be set; otherwise, it is mandatory. |
| nobogus true | Indicates that authsrv should return “user-friendly” error messages when users attempt to authenticate and fail. The default message is to simply respond, “Permission Denied.” or to return a bogus challenge. If nobogus is set, attempts to log on will return more explicit error messages. Sites that are concerned about attempts to probe the authentication server should leave this option disabled. |
| badsleep seconds | Establishes a “sleep time” for repeated bad logins. If a user attempts to authenticate five times and fails, his user record is marked as suspicious, and he cannot log on again. If the badsleep value is set, the user may attempt to log in again after the set number of seconds has expired. If the badsleep value is 0, users can attempt to log in as many times as they would like. The default value is to effectively disable the account until an administrator re-enables it manually. |
| userid name | Specifies the userid under which authsrv should run. The name can be either a name from the password database, or a numeric user-ID. |
| hosts host-pattern [key] | Specifies that authsrv should permit the named host or addresses to use the service. Hosts that do not have a matching entry are denied use of the service. If the optional key is specified, and the software is compiled with DES-encrypted communications, all traffic with that client will be encrypted and decrypted with the specified key. |
| operation user id telnet-gw host operation user id ftp-gw host put | Operation rules are stored in netperm-table. For each user/group, the name is specified and followed by the service destination [optional tokens] [time start end]. The user/group field indicates whether the record is for a user or a group. The name is either the username or the group name. The service can be a service specified by the proxy (usually ftp-gw, tn-gw, or rlogin-gw). The destination can be any valid domain name. The optional tokens are checked for a match, permitting a proxy to send a specific operation check to the authentication server. The time field is optional and must be specified time start_time end_time; start_time and end_time can be in the range 00:00 to 23:59. |
If no other systems on the private network require access to the authsrv, then clients and the server should be configured to accept connections only using the localhost name or IP address 127.0.0.1. The authentication server configuration rules shown earlier illustrate a sample configuration for the server.
The example shown here establishes the following rules for the authentication server:
authsrv: hosts 127.0.0.1 authsrv: database /usr/local/etc/fw-authdb authsrv: badsleep 1200 authsrv: nobogus true
| Previous | Table of Contents | Next |