Access Control

What can I do here?

Use this window to define the Access Policy.

Getting Here - Security Policies > Access Control

Understanding the Rule Base

The Access Control Policy is created and implemented in the Rule Base. A security policy consists of rules that define access control to and from the networks protected by Check Point Security Gateways. A well-defined access policy is essential for the Check Point Security Gateways to be an effective security solution.

The fundamental concept of the Rule Base is "a connection that is not explicitly allowed is denied".

The Rule Base specifies what communication will be allowed to pass and what will be blocked. It specifies the source and destination of the communication, what services can be used, at what times, whether to log the connection and the logging level.

Check Point Security Gateways work by inspecting packets in a sequential manner. When the Security Gateway receives a packet belonging to a connection, it compares it against the first rule in the Firewall Rule Base, then the second, then the third, and so on. When it finds a rule that matches, it stops checking and applies that rule. If the packet goes through all the rules without finding a match, then that packet is denied. It is important to understand that the first rule that matches is applied to the packet, not the rule that best matches.

Rule Base Structure

The Rule Base consists of horizontal rows and vertical columns. The rows display complete rules. The columns display the individual elements of a particular rule.

Workflow

Configure rules and rule elements by selecting the rule and right-clicking on the rule element.

Rule Base Structure

• No. is the number of the rule. The Rule number indicates its importance. The more critical a rule, the higher its place in the Rule Base.
• Hits shows the number of connections that each rule matches. For each rule in the Rule Base, the Hits column shows by default a visual indicator of matching connections together with the number of hits in K (thousands), M (millions), G (billions), or T (trillions).
• Name used to indicate the significance of the specific rule, and shows in logging and monitoring applications.
• Source is the network object which initiates the communication.
• Destination is the network object which receives the communication.
• VPN applies to either clear and encrypted connections. Specify if rules apply to any (all) connections, whether encrypted or clear, or only to VPN connections. To limit this rule to VPN connections, right-click and select Replace...
• Service & Applications can be one the predefined services and applications. It is also possible to define new services and applications
• Action specifies whether communication that matches this rule should or should not be allowed; and whether it should undergo some form of authentication. If a connection is Rejected, the firewall sends an RST packet to the originating end of the connection and the connection is closed. If a packet is Dropped then no response is sent and the connection will eventually time out.
  • When you use Identity Awareness and access role objects in the Source field, you can edit the properties of the action to redirect to the Captive Portal. Doing this redirects http communication of unidentified sources to the Captive Portal to check if there is a match. After the source is identified, the gateway decides whether the communication should or should not be allowed.

Note - Captive Portal is relevant only for http traffic.

• Time makes it possible to define a time period during which the rule is enforced.
• Track specifies if and how how communication that matches this rule is tracked in the SmartConsole Logs & Monitor view.
• Install On defines the installation targets that will enforce this rule.
• Comments is an optional field that allows explanation or remark about the rule. Consider naming the rule, explaining why needed, and under what circumstances.

Rule Base Operations

Operations that can be performed on the Rule Base include:

• Add rule above a rule to the Rule Base. Before adding the rule, decide where the rule fits. Rules need to be grouped in the following manner:
  • Hierarchically, for instance, rules affecting the security of the organization take precedence over all other rules.
  • Logically, according to the type of rule (consider authentication rules).
  • According to frequency of use. Rules that are implemented frequently should generally be placed higher up the Rule Base.
• Add rule below
• Delete rule

Right-clicking in the cell of a rule shows options to

• Disable
• Select All
• Negate
• Search
• Cut/Copy/Paste

You can also multi-select two or more items in a cell.

Introducing Policy Layers

To simplify Policy management, R80 organizes the policy into Policy Layers. A layer is a set of rules, or a Rule Base.

For example, when you upgrade to R80 from earlier versions:

• Gateways that have the Firewall and the Application Control Software Blades enabled will have their Access Control Policy split into two ordered layers: Network and Applications.

  When the gateway matches a rule in a layer, it starts to evaluate the rules in the next layer.

• Gateways that have the IPS and Threat Emulation Software Blades enabled will have their Threat Prevention policies split into two parallel layers: IPS and Threat Prevention.

  All layers are evaluated in parallel

For Pre-R80 Gateways, the enforcement is the same as with earlier management versions, but it looks different in the SmartConsole.

The layers concept opens more options for policy management. These include:

• Setting different view and edit permissions per layer for different administrator roles.
• Re-using a layer in different places: For example, use the same Application Control layer in different policy packages.
• Using additional benefits for Multi-Domain Security Management environments. See the Multi-Domain Security Management Administration Guide for details.

Future versions will include more options with layers, including Actions for Inline Layers.

Introducing the Access Control Policy

An Access Control Policy Rule Base consists of these types of rules:

• Firewall - Control access to the internal network through different access points (gateways)
• Application and URL Filtering - Prevent malicious applications from compromising any internal company data and the internal network resources

Types of Rules in the Rule Base

There are three types of rules in the Rule Base - explicit, implied and implicit.

Explicit rules

The rules that the administrator configures explicitly, to allow or to block traffic based on specified criteria.

Important - The Cleanup rule is a default explicit rule and is added with every new layer. You can change or delete the default Cleanup rule. We recommend that you have an explicit cleanup rule as the last rule in each layer.

Implied rules

The default rules that are available as part of the Global properties configuration and cannot be edited. You can only select the implied rules and configure their position in the Rule Base:

• First - Applied first, before all other rules in the Rule Base - explicit or implied
• Last - Applied last, after all other rules in the Rule Base - explicit or implied, but before the Implicit Cleanup Rule
• Before Last - Applied before the last explicit rule in the Rule Base

Implied rules are configured to allow connections for different services that the Security Gateway uses. For example, the Accept Control Connections rules allow packets that control these services:

• Installation of the security policy on a Security Gateway
• Sending logs from a Security Gateway to the Security Management Server
• Connecting to third party application servers, such as RADIUS and TACACS authentication servers

Implicit cleanup rule

The default "catch-all" rule that deals with traffic that does not match any explicit or implied rules in the Policy Layers. For R77.30 or earlier versions Security Gateways, the action of the implicit rule depends on the Policy Layer:

• Drop - for the Network Layer
• Accept - for the Application Control Layer

Note - If you change the default values, the policy installation will fail.

The implicit rules do not show in the Rule Base.

Order of Rule Enforcement

When a packet arrives at the gateway, the gateway checks it against the rules in the top Policy Layer, sequentially from top to bottom, and enforces the first rule that matches a packet.

If the Action of the matching rule is Drop, the gateway stops matching against later rules in the Policy Rule Base and drops the packet. If the Action is Accept, the gateway continues to check rules in the next Policy Layer down.

If none of the rules in the Policy Layer match the packet, the explicit Default Cleanup Rule is applied. If this rule is missing, the Implicit Cleanup Rule is applied.

Important - Always add an explicit Default Cleanup Rule at the end of each Policy Layer, and make sure that its Action is the same as the Action of the Implicit Cleanup Rule.

Order in which the rules in each Access Control Policy Layer are applied:

1. First Implied Rule - No explicit rules can be placed before it.
2. Explicit Rules - These are the rules that you create.
3. Before Last Implied Rules - Applied before the last explicit rule.
4. Last Explicit Rule - We recommend that you use a Cleanup rule as the last explicit rule.

   Note - If you use the Cleanup rule as the last explicit rule, the Last Implied Rule and the Implicit Cleanup Rule are not enforced.

5. Last Implied Rule - Remember that although this rule is applied after all other explicit and implied rules, the Implicit Cleanup Rule is still applied last.
6. Implicit Cleanup Rule - The default rule that is applied if none of the rules in the Policy Layer match.

Best practices for performance-efficient Access Control Policy

• Add all rules that are based only on source and destination IP addresses and ports in a Firewall/Network Policy Layer at the top of the Rule Base
• Create Firewall/Network rules to explicitly accept safe traffic, and add the Explicit Cleanup Rule at the bottom of the Policy Layer to drop everything else
• Create Application Control rules to explicitly drop unwanted or unsafe traffic, and add the Explicit Cleanup Rule at the bottom of the Policy Layer to accept everything else
• Turn XFF inspection off, unless the gateway is behind a proxy server. For more, see: sk92839.

Configuring the Implied Rules

Some of the implied rules are enabled by default. You can change the default configuration as necessary.

To configure the implied rules:

1. In SmartConsole, from the Menu, select Global Properties.

   The Global Properties window opens.

2. Select a rule to enable it, or clear a rule to disable it.
3. For the enabled rules, select the position of the rules in the Rule Base:
   • First - The rule is applied before any other rule in the Rule Base
   • Last - The rule is applied if all other rules in the Rule Base were applied and none of them matched
   • Before Last - The rule is applied before the last explicit rule, if none of the other rules in the Rule Base matched
4. Click OK and install the policy.

Choosing Rules to Track

Logs are useful if they show the traffic patterns you are interested in. Make sure your Security Policy tracks all necessary rules. But when you track multiple rules, the log file will be large, and will require more disk space and management operations.

To balance these requirements, track rules that can help you improve your network security, help you understand of user behavior, and are useful in reports.

Configuring Tracking in a policy Rule

To configure tracking in a rule:

1. Right-click in the Track column.
2. Select a tracking option.
3. Install the policy.

Tracking Options

• Network Log - Generates a log with only basic Firewall information: Source, Destination, Source Port, Destination Port, and Protocol.
• Log - Equivalent to the Network Log option, but also includes the application name (for example, Dropbox), and application information (for example, the URL of the Website). This is the default Tracking option.
• Full Log - Equivalent to the log option, but also records data for each URL request made.
  • If suppression is not selected, it generates a complete log (as defined in pre-R80 management).
  • If suppression is selected, it generates an extended log (as defined in pre-R80 management).
• None - Do not generate a log.

You can add these options to a Log, Full Log, or Network Log:

• Accounting - If selected, update the log every 10 minutes, to show how much data has passed in the connection: Upload bytes, Download bytes, and browse time.
• Suppression - If selected, one log is generated every three hours for all the connections.

Alert:

If an Alert is selected, Log is selected automatically.

• None - Do not generate an alert.
• Alert - Generate a log and run a command, such as: Show a popup window, send an email alert or an SNMP trap alert, or run a user-defined script as defined in the Menu > Global Properties > Log and Alert > Alerts.
• SNMP - Send an SNMP alert to the SNMP GUI, or run the script defined in: Menu > Global Properties > Log and Alert > Alerts.
• Mail - Send an email to the administrator, or run the mail alert script defined in: Menu > Global Properties > Log and Alert > Alerts.
• User Defined Alert - Send one of three possible customized alerts. The alerts are defined by the scripts specified in the Menu > Global Properties > Log and Alert > Alerts.