Before you create an administrator, you need to create a Permissions Profile. Go to the Manage | Permissions Profiles dialog and select New | Permissions Profiles, as in Figure 4.3.

Figure 4.3. The Permissions Profiles Dialog

In the General tab, you can name the profile, select a color, and enter a comment. In the Permissions tab, you can select among the following:

The administrators are the users that have access to the configuration of the firewall. Depending on the Permissions Profile assigned to the administrators, they may or may not have permission to read and write to different parts of the security policy. Once you create or edit an administrator, you’ll see the tabs outlined in the following sections.

General Tab

In the General tab of the Administrator Properties dialog, you can give a name to the administrator and select a previously created Permissions Profile. You can also click on New and directly create a new profile. View Permissions Profile allows you to view and edit existing profiles (see Figure 4.5).

Figure 4.5. Creating a New Administrator

You can create Administrator Groups and place administrators in them. You can use Administrator Groups by editing a Check Point gateway, using the Advanced | Permissions to Install tab. Here you can specify Administrator Groups to which you want to grant install access. Only administrators with Manage Administrators permission can modify these properties.

Before you create users, you have to understand templates. There are many options to configure for users, and templates save you time by preconfiguring options at the time of user creation. Let’s look at the different tabs you see once you select New | Template.

You can create user groups and place users in them. You can select a Name, Comment, and Color for the group, and Add and Remove them from the Not in Group box to the In Group box, as in Figure 4.6.

Figure 4.6. Creating a User Group

User groups can also contain other groups in a nested fashion. When you add a group to another group, NGX will ask Would you like to add each member of the group separately? and each group will be expanded in the new group. With nested groups, if you change a group the change will be reflected in the parent group, but that will not happen if you expand the group.

Check Point NGX does not reference individual users directly in rules or object properties, so if you have a user, you should place him or her in a group. If a user is not in a group, the user is still part of the All Users group.

When you want to create a user you have to work based on an existing template. Once you select New | User from Template as in Figure 4.7, you can select the initial template you want and then you will see a dialog box with many tabs. Let’s look at them.

Figure 4.7. Creating a User from a Template

If you’re working with external directory servers (RADIUS, TACACS, OS Password, or SecurID) you can create an External User Profile. If users are recognized by an external directory server they will be granted permissions based on the appropriate External User Profile. Still, using OS Password usually is not a good option due to the complexity of managing passwords in the OS on which the Security Gateway is installed.

Match by Domain

This profile allows you to selectively query an external user database based on the domain the user enters. The important properties are in the General tab. If you use Distinguished Name (DN) format, you can select a specific organizational unit, organization, or country to authorize. Alternatively, you can use Free Format, in which case the domain will be separated from the username by a character such as @ or (for Microsoft), either before or after the username. In Free Format, you can choose Any Domain is Acceptable, or a specific Domain Name. See Figure 4.8 for details.

Figure 4.8. External User Profiles | Match by Domain

The other tabs in the External User Profile (Personal, Groups, Authentication, Location, Time, and Encryption) function like they do in the normal user entity. Remember that in this scenario, you’re leaving authentication and authorization decisions to an external entity.

We will look at LDAP Groups in the upcoming “SmartDirectory” section.

You use the Undefined Authentication Scheme to disable the user’s ability to enter a password. This will force users to employ strong authentication with a digital certificate.

Selecting SecurID as the Authentication Scheme will enable Check Point NGX to become an ACE/Agent for RSA’s SecurID tokens. This integration will require use of a special sdconf.rec generated by the ACE server, and will allow you to enter new PINs and reauthenticate often to secure servers. However, it’s a lot more difficult to configure than through SecurID’s RADIUS interface.

If you select Check Point Password (previously called VPN-1 & Firewall-1 Password), you will enter the user’s password directly into NGX’s internal database. Passwords can be four to eight characters in length. Be aware that the only way to assign or change passwords is through the SmartDashboard interface.

RADIUS is a standard protocol that can authenticate users with a RADIUS server that holds a database. The RADIUS protocol is very flexible and relatively secure. It uses a specific secret key to secure the authentication and only authorized clients can request authentication from the server. You can also set up backup servers in case one of them is out of service.

To configure RADIUS authentication, first create a RADIUS server from the Manage | Servers and OPSEC Applications dialog, as in Figure 4.9. Select New | RADIUS to create the server. Input the appropriate data in the Name, Comment, and Color fields, as in Figure 4.10. For Host, select the physical server that is running the RADIUS server. If you don’t have the server created, use the New button to create a new node. Select the Service to use, either NEW-RADIUS (the official port number) or RADIUS (the most common port number used). The Shared Secret is a password used to secure the information sent between the Check Point Gateways and the RADIUS server(s). You can select the Version to use, either Version 1.0 or Version 2.0. Also select a Priority, to know which server to use first if more than one is available. You can also create RADIUS groups for high availability and load sharing.

Figure 4.9. The Manage Servers and OPSEC Applications Dialog

Figure 4.10. Creating a RADIUS Server

The Terminal Access Controller Access Control System is a standard protocol that can authenticate users with an external user database. To configure TACACS authentication, first create a TACACS server from the Manage | Servers and OPSEC Applications dialog. Select New | TACACS and input the appropriate data in the Name, Comment, and Color fields, as in Figure 4.11. For Host, select the physical server that is running the TACACS server. If you don’t have the server created, use the New button to create a new node. Select the Type of the server used, either TACACS, or TACACS+ which is more secure. If you select TACACS+ you can also enter a Secret Key for encryption. Finally, select the Service to use (UDP TACACS or TCP TACACSPLUS).

Figure 4.11. Creating a TACACS Server

Once you have configured an Account Unit, the Users and Administrators Object Tree will show the Account Unit at the bottom, as in Figure 4.19. Double-click on the Account Unit and it should expand to show the LDAP tree; double-click on any of the branches to retrieve the LDAP entities within that branch.

Figure 4.19. The Users and Administrators Object Tree

Within the branch information, if write permissions have been configured for the LDAP server, users and groups can be added, edited, and removed.

The preferred way to grant user access via SmartDirectory is to use LDAP groups. Figure 4.20 shows an example.

Figure 4.20. An LDAP Group

Select the Account Unit that contains the users to authenticate. In the Group’s Scope, you can select to recognize all of the Account Unit users, or only those in a certain subtree, or a group in a branch. You can also apply a filter to create a dynamic group (e.g., all users in ou=Access).

Once created, an LDAP group behaves like any other user group in the object database. We will now examine the different types of authentication and how to integrate groups into the rulebase.

User authentication for Telnet and rlogin is easy for the end-user to understand. When a user tries a command such as telnet 172.29.109.1, the firewall will intercept this command and present its own Telnet prompts, as in Figure 4.23. Once the user correctly authenticates, he or she will see the prompts from his or her original destination and can proceed accordingly.

Figure 4.23. Telnet User Authentication

User authentication for FTP is a bit more complex to understand. The user will still use the command ftp 172.29.109.1, which will be intercepted by the firewall’s FTP security server, but the username will have to reflect the user that is authenticating at the FTP server (i.e., the administrator), the user that is authenticating at the firewall (i.e., the user), and the final destination of the FTP connection (even though it was used in the original FTP command). For example, in this case, the username will be administrator@[email protected], and the password will be the passwords of the FTP user separated by an @ sign from the password of the firewall user (i.e., ftppassword@ fwpassword). Then a connection to the FTP server will be established. Figure 4.24 shows the details.

Figure 4.24. FTP User Authentication

User authentication for HTTP is simple to use. When activated, an HTTP connection that should be authenticated is modified by the firewall in such a way that the user’s browser displays an authentication dialog box or prompt, using HTTP’s authentication mechanism. The prompt reads FW-1: No user. Once the user authenticates with this prompt, the requested site is displayed in the browser. Figures 4.25 and 4.26 show examples that use Microsoft Internet Explorer and Mozilla Firefox.

Figure 4.25. HTTP User Authentication with Microsoft Internet Explorer

Figure 4.26. HTTP User Authentication with Mozilla Firefox

In Figure 4.27, you can see the entry in the SmartView Tracker generated from the authenticated HTTP access.

Figure 4.27. SmartView Tracker Entry for HTTP User Authentication

Check Point rules are sequential, which means that once a rule can be applied to traffic passing through the firewall, that rule is applied and the rest of the rulebase is ignored. However, there is one exception to this. If a rule allows traffic to a destination, even a rule that would require authentication before that rule, the traffic will pass through without the need for users to authenticate. Remember: An authentication rule accepts traffic that is authenticated, but doesn’t block traffic that fails authentication.

Traffic that is intercepted by the firewall, be it FTP, Telnet, rlogin, or HTTP, displays a message from Check Point NGX requesting authentication. It is advisable to change this default message to a generic one that doesn’t broadcast the firewall’s identity, and that can include additional information for users. You can select a file to be presented instead of the regular banner for FTP, Telnet, and rlogin (not for HTTP) in the SmartDashboard’s Global Properties | Firewall | Security Servers dialog box.

If you are making HTTP connections, once the connection is authenticated the firewall needs to redirect the original query to the intended destination. It does so by looking at the original URL’s IP address, and redirecting the user’s browser to that IP. However, if the firewall resolves the destination URL to a nonroutable IP (i.e., the non-NATed IP), or if the Web server is configured to need the Host Header for access (i.e., a Web hosting service that shares one IP with multiple Web pages), the connection will fail. To solve this, enable the setting http_use_host_h_as_dst using Policy | Global Properties | SmartDashboard Customization | Configure | Firewall-1 | Web Security | HTTP Protocol, as in Figure 4.28.

Figure 4.28. Changing Advanced Properties with SmartDashboard Customization

As in other authentication actions, Source is used to control whether the source of the rule has to intersect the configured Location of the user, or whether it takes precedence. Select Ignore if you want to override the location configured for the user.

Client authentication cannot determine the final destination of a connection, because users are authenticating directly to the firewall. Therefore, the destination field is grayed out and cannot be selected.

Checking this box will allow the client to access resources granted in the rule, once the user authenticates, only if the user is using Check Point SecureClient and the Secure Configuration Verification (SCV) has succeeded.

If you select Standard sign-on, users will be able to access all resources permitted in the rule at which they authenticated. If you select Specific sign-on, users will have to explicitly specify, through a form or a sequence of prompts, the services and destinations allowed for the client. Specific sign-on is useful for a kiosk machine, where an administrator can authorize access to certain sites or services only, without interacting with the firewall administrator.

The Sign On Method is one of the most important settings when using client authentication. Be sure you know how each method works so that you select the most appropriate to your environment.

Manual Sign-On

The Manual sign-on method activates two ports on the firewall gateway for receipt of the authentication. They are port 900 using HTTP and port 259 using Telnet. Because users need to access these ports on the firewall, you must place the Client Authentication rule above the Stealth rule (the one that drops all connections to the firewall module).

This method is nontransparent, meaning that users will know they are first authenticating to a firewall and then be able to access the appropriate resources.

If you want to HTTP to port 900, you can look at Figures 4.32 through 4.36.

Figure 4.32. HTTP Manual Client Authentication: Entering the Username

Figure 4.33. HTTP Manual Client Authentication: Entering the Password

Figure 4.34. HTTP Manual Client Authentication: Selecting the Sign-On

Figure 4.35. HTTP: Manual Client Authentication: Specific Sign-On

Figure 4.36. HTTP Manual Client Authentication: Successful Sign-On

If you want to telnet to port 259, see Figures 4.37 through 4.40.

Figure 4.37. Telnet Manual Client Authentication: Standard Sign-On

Figure 4.38. Telnet Manual Client Authentication: Specific Sign-On

Figure 4.39. Telnet Manual Client Authentication: Sign-Off

Figure 4.40. Configuring Client Authentication Limit Properties

Here you can select whether you want information or alerts sent to the log when a user successfully authenticates. If you select Alert it will also write the information to the log.

Here you can select how long the user authorization will last. Select Indefinite to require an explicit sign-off from the user (via HTTP to port 900 or Telnet to port 259) to cancel the authorization. Select a specific time limit, in Hours and Minutes, if you want to require reauthentication after a time has lapsed. Select Refreshable timeout if you want the user to not be required to reauthenticate as long as the connection is being used. This is useful in that if a user leaves his machine, someone else can’t sit down and use it.

This limits the number of open connections an authenticated user can make through the firewall. If you’re using FTP, Telnet, or rlogin connections, you could limit the number of sessions through here. However, if you’re using HTTP connections, you will need to select Infinite sessions because a browser will normally open many sessions.

There are some properties that you need to configure and verify per gateway, to fine-tune the authentication experience for your users, as in Figure 4.41.

Figure 4.41. Check Point Gateway | Authentication

Certain properties are configured globally for all authentication performed by the Check Point gateways. Appropriately enough, you access them from the Global Properties | Authentication tab, as in Figure 4.42.

Figure 4.42. Global Properties | Authentication

Now we’ll discuss registry settings.

New Interface

The default client authentication HTTP interface requires four pages for a successful login: the username page, password page, method page, and optional specific sign-on page. If you enable the hclient_enable_new_interface setting by selecting Policy Menu | Global Properties | SmartDashboard Customization | Firewall-1 | Authentication | Client Authentication | HTTP, the HTTP interface will combine the username and password pages into one, and will streamline the user experience, as in Figure 4.43.

Figure 4.43. Client Authentication HTTP New Interface

Now we’ll discuss configuration files.