Setting Up User Authentication

Setting Up User Authentication

Set up User Authentication by following these steps.

1. Create the necessary users and groups required for authentication, then install the user database.

2. Ensure that the appropriate Security Servers are enabled in $FWDIR/conf/fwauthd.conf .

3. Create the appropriate rule(s) in the rulebase.

4. Configure the User Authentication action properties.

5. Configure the Rulebase Properties Authentication frame.

6. Verify and install the policy.

After creating your users, verify that the appropriate Security Servers are enabled in $FWDIR/conf/fwauthd.conf . By default, they should be enabled, but it never hurts to check. The lines for the servers you want to enable should be present and not commented out (i.e., the line should not begin with a # ). The FTP, HTTP, Telnet, and rlogin servers are enabled if these lines are present in fwauthd.conf and are not commented out:

 21      fwssd       in.aftpd        wait    0 80      fwssd       in.ahttpd       wait    0 513     fwssd       in.arlogind     wait    0 23      fwssd       in.atelnetd     wait    0 

You then need to create the appropriate rule in the rulebase. When adding the source of the rule, right-click the source field, and select Add User Access. Select the appropriate group. The Location must also be set. The No restriction option means Any in the rulebase. The Restrict option allows you to select a network object or group that represents where you want to authenticate the connections from.

For example, if you want to authenticate all users in the group knights-of-the-roundtable from the network camelot to the host castle-anthrax via Telnet and HTTP, the rule would look like the one shown in Figure 8.30.

Figure 8.30. The Knights of the Round Table can go to Castle Anthrax

You must then edit the User Authentication properties by right-clicking the Action field of the rule and selecting Edit Properties. Figure 8.31 shows the screen that appears. For both the source and the destination, you can select one of two options:

Intersect with user database: This option means that if the user who authenticates is coming from a source or destination (as appropriate) that is not allowed as defined in the user's record, the user will actually be denied , even if the rule says the user should be allowed access. This option allows you to set up fairly granular access.

Ignore user database: This option means that users who would otherwise be denied as a result of the allowed sources or destinations defined in their user record are allowed anyway.

Figure 8.31. User Authentication Action Properties, General tab

To illustrate the way these options work, let's use the users sir-gallahad and sir-lancelot with the rule created earlier. The allowed sources and destinations for sir-gallahad are both Any. The allowed sources for sir-lancelot are Any, but his allowed destination does not include castle-anthrax (i.e., it is neither Any nor a group that includes castle-anthrax). If the User Authentication properties for the rule are defined using "intersect with user database" for the destination, when sir-lancelot tries to authenticate to access castle-anthrax, he will be denied, even if he is coming from camelot ^[2] and presents correct credentials. If the setting used is "ignore user database," sir-lancelot will be permitted to go to castle-anthrax, provided he supplies the correct credentials and is coming from camelot.

^[2] It's only a model.

For the HTTP section of this screen, there are two options:

All servers: This setting should be the default for this screen. It allows you to authenticate and go to any HTTP server without having to define it in the Policy Properties Security Servers tab. Of course, the connection must still match the rulebase. Unless you are using this rule to authenticate access to internal servers only, it is highly recommended that you use this setting (otherwise, the rule won't work).

Predefined Servers: This option is the actual default. It means you can go only to servers defined in the Policy Properties Security Servers tab. Using this setting makes sense only if you are using FireWall-1 as a reverse proxy server.

As part of setting up User Authentication, you must go to the gateway object and configure some related options. Recall that in the discussion of Figure 8.28 there were some options I did not explain. Two of these options come into play now.

User Authentication session timeout: If an authenticated Telnet, FTP, or rlogin connection is inactive for the specified number of minutes, the connection will be terminated . In HTTP, this option has a different meaning. If an OTP is used, this is the amount of time the user will be authenticated before a new OTP is requested . If a static password scheme is used with HTTP, this setting has no effect because Web browsers typically cache passwords until the client exits.

Use Next Proxy: If you are using the firewall as a proxy for your internal Web clients , this option controls which proxy server to forward authenticated or content-screened content to.

Also on that frame, the Authentication Failure Track provides three options that determine what happens when a user fails to authenticate successfully. The selected alert will be generated upon failure.

Finally, you must configure the global properties as appropriate for your needs.

Once the rules and the rulebase properties are set to your liking, install the security policy.

The Importance of Rule Order in User Authentication

There is one case where FireWall-1 does not process the rules in order but instead uses the rule that is most permissive. This occurs when User Authentication for HTTP, FTP, Telnet, and rlogin is used and such a rule is matched in the rulebase. If during the in-order rulebase evaluation the rule that matches the connection (based on source, destination, and service) is User Authentication, all rules in the rulebase are evaluated and the least restrictive one applies. Check Point refers to this as the Insufficient Information problem in the documentation.

To give you an idea of what this means, consider the security policy shown in Figure 8.32.

Figure 8.32. Sample rulebase

Based on the rules and how the rulebase rules are applied, the following list details how these rules will apply themselves .

• Everyone on the Internet will be able to access the HTTP, HTTPS, and SMTP servers without any authentication from the firewall.

• Everyone will have access via FTP to the ftp_server. Other rules (Rule 4 and Rule 7) could match this rule as well, but Rule 3 matches first because it is listed first and does not involve User Authentication. This is not a major problem, but worth noting.

• Users in the DMZAdmins group who Telnet or FTP from internal-networks to DMZ_net will not have authenticated access to all servers in DMZ_net for two reasons: Rule 3 and Rule 7. Rule 3 matches FTP connections to the FTP server before Rule 4. When Rule 4 is matched, because it is a User Authentication rule, the least restrictive rule applies and thus Rule 7 permits access.

• When people Telnet to the firewall, Rule 5 matches initially, but again because of the least restrictive rule for User Authentication, Rule 7 actually permits the communication without authentication.

• Rule 7 also permits these services to the firewall as well, which may not be desirable.

The major problem in this rulebase is that Rules 4 and 5 do not provide authentication in cases where you would expect them to because Rule 7 is too permissive. You can fix this by making Rule 7 a bit less permissive by excluding DMZ_net and Local_Gateway from the allowed destinations, as shown in Figure 8.33.

Figure 8.33. A more restrictive Rule 7