Using Identity Awareness in the Firewall Rule Base

The Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources. examines packets and applies rules in a sequential manner. When a Security Gateway receives a packet from a connection, it examines the packet against the first rule Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session. in the Rule Base All rules configured in a given Security Policy. Synonym: Rulebase.. If there is no match, it then goes on to the second rule and continues until it matches a rule. If there is no match to any of the explicit or implied rules, Security Gateway drops the packet.

Working with Access Role Objects in the Rule Base

In rules with Access Roles, if the source identity is unknown, and traffic is HTTP, configure the Action field to redirect traffic to the Captive Portal A Check Point Identity Awareness web portal, to which users connect with their web browser to log in and authenticate, when using Browser-Based Authentication.. This rule redirects the user to the Captive Portal.

In rules with Access Roles, if the source identity is known, the Action in the rule (Allow, Drop, or Reject) is enforced immediately, and the user is not redirected to the Captive Portal. After the system gets the credentials from the Captive Portal, it can examine the rule for the next connection.

In rules with Access Role Access Role objects let you configure network access according to: Networks, Users and user groups, Computers and computer groups, Remote Access Clients. After you activate the Identity Awareness Software Blade, you can create Access Role objects and use them in the Source and Destination columns of Access Control Policy rules. objects, criteria matching works like this:

• When identity data for an IP address is known:

  • If it matches an Access Role, the rule is enforced and traffic is allowed or blacked based on the action.

  • If it does not match an Access Role, it goes on to examine the next rule.

• When identity data for an IP address is unknown and:

  • All rule fields match, besides the Source field with an Access Role.

  • The connection is HTTP.

  • The action is set to redirect to the Captive Portal.

    If all the conditions apply, the traffic is redirected to the Captive Portal to get credentials and make sure there is a match.

    If not all conditions apply, there is no match, and the next rule is examined.

    Note - You can only redirect HTTP traffic to the Captive Portal.

To redirect HTTP traffic to the Captive Portal:

1. In an Access Control Policy rule that uses an Access Role in the Source column, right-click the Action cell > click More.

   The Action Settings window opens.

2. In the Action field, select Accept, Ask, or Inform.

3. At the bottom, select Enable Identity Captive Portal.

4. Click OK.

5. The Action cell shows that a redirect to the Captive Portal occurs:

   • Accept (display Captive Portal)

   • Ask (display Captive Portal)

   • Inform (display Captive Portal)

6. Install the Access Control Policy.

Important - When you set the option to redirect HTTP traffic from unidentified IP addresses to the Captive Portal, make sure to put the rule in the correct position in the Rule Base, to avoid unwanted behavior.

This is an example of a Firewall Rule Base that describes how matching works:

Example 1 - If an unidentified Finance user tries to get an access to the Finance Web Server over HTTP, a redirect to the Captive Portal occurs. After the user enters credentials, the Identity Awareness Check Point Software Blade on a Security Gateway that enforces network access and audits data based on network location, the identity of the user, and the identity of the computer. Acronym: IDA. Gateway allows access to the Finance Web Server. Access is allowed based on rule number 1, which identifies the user through the Captive Portal as belonging to the Finance Access Role.

Example 2 - If an unidentified administrator tries to get an access to the Finance Web Server over HTTP, a redirect to the Captive Portal occurs despite rule number 2. After the administrator is identified, rule number 2 matches. To let the administrator get an access to the Finance Web Server without redirection to the Captive Portal, switch the order of rules 1 and 2 or add a network restriction to the Access Role.