The Gauntlet Firewall can permit or deny access based not just on the host name, but also on the user name. In addition, your security policy may require that users use some form of strong authentication each time they access a particular host or service within their perimeter. To ease the integration of users, strong authentication, and the firewall, the Gauntlet Firewall provides a user authentication management system.
Use of the authentication management system is optional. You must use it any time you have configured the FTP, TELNET, rlogin, POP3, authenticating HTTP, and authenticating circuit proxies to require authentication, which is the default configuration for requests from untrusted networks.
This chapter describes the concepts behind the user authentication management system, and some common administrative tasks in the following sections:
As part of the security policy, many sites may require some form of strong authentication, which requires users to enter a one-time password or use an authentication token. There are many systems available that can be integrated into a networking environment, each with its own programming and management interface. These are described in more detail in “Understanding Strong Authentication” and in Appendix B, “Initializing Strong Authentication Tokens.”
The Gauntlet user authentication management system allows you to easily integrate several different strong authentication systems into your general firewall administration. You can create, modify, disable, delete, and examine users. The authentication system maintains a database for this information.
The various proxies use the information in the user authentication management system any time you configure the proxies to require authentication. Using the default Gauntlet service groups and rules, the authentication is required any time a user from an untrusted network tries to access a service inside the perimeter. Recall that untrusted networks are those from which the firewall will accept requests only after authentication by the user.
Remember that using the default service group and rules, the proxies do not authenticate requests from trusted networks. The proxies operate under the assumption that users coming from trusted networks are who they say they are.
Consider the situation of a user, Jane, working at a client site (blaze.clientsite.com) who needs information stored on a system at work (dimension.yoyodyne.com). When Jane tries to TELNET to dimension, which is within the security perimeter, she must first connect to and authenticate at the firewall (fire-out.yoyodyne.com).
When fire-out.yoyodyne.com receives the information, the TELNET proxy determines that the connection request is from an untrusted network, and that blaze.clientsite.com can access inside systems.
The TELNET proxy then prompts Jane for her authentication information (user name and password), which it verifies against the information in the user authentication database. If Jane provided the proper information, and her account is not disabled, the proxy provides a prompt. Jane can then connect to the dimension system on the inside network.
The login-sh program accesses the user authentication server to authenticate users logging into the firewall itself. This login shell authenticates the user before starting the user's normal shell (for example, csh, ksh or tcsh).
The authmgr program also uses the user authentication database to authenticate users. This program authenticates the user before allowing the user to do administration from a remote host.
This section explains what users and groups mean inside the authentication management system.
User names you create in the user authentication management system are used only for strong authentication.
The user names in the user authentication management system do not need to match user names on the firewall itself because you do not create user accounts on the firewall by default.The exception to this rule is the login-sh authentication wrapper program. The login-sh program authenticates users before logging them into the firewall. Then, the information in the user authentication management system must match the standard IRIX user information (in /etc/passwd) for these users.
The user names in the user authentication management system do not need to match any user names on your internal network. For example, John Whorfin might use john as his user name on internal networks. He could use whorfin for strong authentication at the firewall. You may wish to use the same names for the convenience of your users.
The Gauntlet user authentication management system also makes use of groups. Groups allow you to permit or deny services based on groups of user names, rather than individual user names. For example, you can configure the FTP proxy to permit service to everyone in group sales.
Just as is the case with user names, the groups that you create in the Gauntlet user authentication management system are not the same as the groups you create on the firewall or on the internal network. You can of course use the same names, for easier administration. Each user can be a member of only one group at a time.
The Gauntlet Firewall supports a variety of strong authentication options. The Gauntlet authentication management system understands the types of passwords these systems use, and provides a consistent user interface to these systems.
 | Note: Your Gauntlet system does not actually include the software or hardware for these products (except as noted below). You must purchase, install, and configure these systems separately. |
Currently supported systems are described below.
This system, from VASCO Data Security, uses a random-challenge password. When the firewall prompts for authentication Access Key II provides a challenge. The user enters the PIN (if one is required) and the challenge into the Access Key II. The Access Key II responds with a password. The user enters this value at the Gauntlet prompt, and the Gauntlet authentication server verifies this value.
You must purchase the Access Key II tokens from VASCO (http://www.vasco.com) or their authorized reseller.
See “Access Key II Authentication” for more information.
This system, included with APOP-compliant applications, uses an MD5 secure hash algorithm. The application generates a random challenge and includes it as part of the initial banner.
This option is currently only used by the POP3 proxy.
You must use an APOP-compliant POP3 server and an APOP-compliant POP3 client. Check with the vendors of your POP3 server and client software to determine if their software understands APOP authentication.
This system, from CYPTOCard, uses a random-challenge password. When the firewall prompts for authentication it provides a challenge. The user enters their PIN and the challenge into the CRYPTOCard RB-1. The CRYPTOCard RB-1 encrypts this information to produce a response. The user enters this value at the Gauntlet prompt, and the Gauntlet authentication server verifies this value.
You must purchase the CRYPTOCard RB-1 tokens from CRYPTOCard (http://www.cryptocard.com) or their authorized reseller.
This system, from Digipass, uses a time-based password. The Digipass card generates a passcode. When the firewall prompts for authentication, the user selects the appropriate authentication application and enters a personal identification number (PIN) on the card. The card displays a passcode, which the user enters at the Gauntlet prompt. The Gauntlet authentication server verifies this value.
You must purchase the Digipass tokens from Digipass (http://www.digipass.com) or their authorized reseller.
See “Digipass Authentication” for more information.
This system, from Secure Computing, provides an interface to the SafeWord Authentication Server for Gauntlet authentication. The SafeWord Authentication Server works with a variety of different tokens. The Gauntlet authentication server uses the authentication information registered for a user with the SafeWord Authentication Server.
You must purchase the SafeWord Authentication Server and tokens from Secure Computing (http://www.securecomputing.com/) or their authorized reseller.
This system, from Security Dynamics, uses a time-based password. The SecurID card generates a passcode. When the firewall prompts for authentication, the user enters a PIN, if one is required, and the passcode shown on the card. The Gauntlet authentication server verifies this value with the Security Dynamics ACE/Server.
You must purchase the ACE/Server and SecurID tokens from Security Dynamic (http://www.securitydynamics.com) or their authorized reseller.
See “SecurID System Authentication” for more information.
This system, from Bellcore, uses a one-time password. Users generate a set of passwords based on a “seed” word or phrase. Each time they need to authenticate, they use a different password. When the firewall prompts for authentication, it provides a challenge value. The user enters the appropriate password for that challenge. The Gauntlet authentication server verifies this value.
The Gauntlet Firewall distribution includes a portion of the S/Key package. You can purchase the full S/Key package, which supports both MD4 and MD5 authentication, from Bellcore (http://www.bellcore.com). You can also download a freeware version of the full S/Key package that supports only MD4 authentication from Bellcore (ftp://ftp.bellcore.com/pub/nmh/skey).
You can also use the Naval Research Lab One-Time Password in Everything (OPIE), which is downward-compatible with Bellcore's S/Key Version 1 software. The OPIE package is available from the Naval Research Lab (ftp://ftp.nrl.navy.mil/pub/security/opie).
See “S/Key System” for more information.
RADIUS stands for Remote Authentication Dial-In User Service, an authentication protocol specified by the IETF. RADIUS authentication can be used with your Gauntlet Firewall in conjunction with a strong authentication method such as Safeword or CRYPTO, or by itself using a plain RADIUS password.
See “RADIUS Authentication” for more information.
The Gauntlet Firewall includes a reusable password as part of its authentication system. Reusable passwords are intended for administrator testing only. Every time users need to authenticate; they use the same password.
 | Caution: Do not use the reusable passwords option for authentication from untrusted networks. Reusable passwords are discouraged. Reusable passwords are vulnerable to password sniffers and are easy to crack. This feature is provided for convenience and audit capability only. |
See “Reusable Passwords” for more information.
Configuring users consists of the following potential tasks:
The process for creating users varies depending on the authentication scheme you are using. Remember that the users that you create in the Gauntlet system are not necessarily the same as the users you create on the firewall or on your internal network. You can of course use the same names, for easier administration. Refer to Appendix B, “Initializing Strong Authentication Tokens,” for specific instructions on creating users using your authentication system.
Modifying users can mean one of the following activities, which are all discussed in this section:
Select the name of the user you wish to modify.
Click Modify.
The Modify User window displays.
Enter a new user name for the user.
Click OK.
You cannot change a user ID. Instead, create a new user ID with the appropriate information and delete the old user ID.
Remember that a user can be a member of only one group.
To change the group of which the user is a member:
Select the name of the user you wish to modify.
Click Modify.
The Modify User window displays.
If the group already exists, select the name of the group to which you want to assign the user.
If the group does not exist, enter a new group name and click Add. Then select that group name.
Click OK.
To change authentication methods:
Make sure that you have configured your Gauntlet Firewall to work with the authentication system. Refer to Appendix B, “Initializing Strong Authentication Tokens,” for specific instructions.
Select the name of the user you wish to modify.
Click Modify.
The Modify User window displays.
Select the new authentication method.
Check the Set Password box to set the user's password.
Reenter the same new password in the Verify field.
If you would also like to set a POP3 password at this time, check the Set Pop3 Password field and also enter the new POP3 password.
Enter the new password in the password field.
Click OK.
Several of the strong authentication systems allow passwords to be set (and reset) by the user:
CRYPTOCard
S/Key
Reusable password
To change passwords as an administrator:
Select the name of the user you wish to modify.
Click Modify.
The Modify User window displays.
Check the Set Password box to set the user's password.
Enter the new password in the Password field.
Reenter the same new password in the Verify field.
Click OK.
Provide the user with the new password.
Because users are generally not allowed to log directly into the firewall, they need to change their password from another system. The default configuration allows users connecting to the firewall from the inside (trusted) network to change their passwords.
Users can change their passwords through either the TELNET or rlogin proxies. Users should be allowed to change their password only when accessing the firewall from the trusted network.
To change passwords as a user:
From a system on the inside network, connect to the firewall using TELNET or rlogin.
Use the password command.
Authenticate to the proxy.
Enter the new password.
Verify the new password.
The following example shows a sample S/Key password change from the TELNET proxy:
dimension-83: telnet fire-in Trying... Connected to fire-in.yoyodyne.com Escape character is '^]'. tn-gw-> password Changing passwords Username: john Skey Challenge: s/key 644 fi58297 LOAM WOOD BOIL VASE TELL TINY New Password: ############## Retype New Password: ############## ID john s/key is 664 fi582901 |
Enabling users allows users who have been disabled to use the system again.
To enable a user:
Select the name of the user you wish to modify.
Click Modify.
The Modify User window displays.
To enable the user for multiple logins, select Enabled. To enable the user ID to login once, select Enable One Time Only.
Disabling users allows you to keep the user information in the system, but does not allow the user to use the system. The user authentication system disables users after a set number (configurable by the administrator) of failed login attempts.
To disable a user:
Select the name of the user you wish to modify.
Click Modify.
The Modify User window displays.
Click Disabled.
You can also configure the number of consecutive incorrect attempts before the authentication system disables a user's account and you can set the amount of time the account is disabled.
To configure the number of consecutive incorrect attempts, add the maxbad attribute to the netperm table. Refer to the Gauntlet Netperm Table Reference Guide for more information.
To configure the amount of time disabled, add the badsleep attribute to the netperm table. Refer to the Gauntlet Netperm Table Reference Guide for more information.
As with IRIX systems, the Gauntlet user authentication management system makes use of groups. Groups allow you to permit or deny services based on groups, rather than individual user names. For example, you can configure the TELNET proxy to deny access to a certain destination for everyone in the group Sales.
Remember that the groups that you create in the Gauntlet system are not necessarily the same as the groups you create on the firewall or on your internal network. You can, of course, use the same names for easier administration.
To create a group:
Assign a user to a group that did not exist before.
Remember that you may want to make group names the same as existing IRIX groups.
You cannot disable entire groups. You must disable usage based on individual users.