Print Download PDF Send Feedback

Previous

Next

Creating an Access Control Policy

In This Section:

Introducing the Unified Access Control Policy

Creating a Basic Access Control Policy

Creating Application Control and URL Filtering Rules

Ordered Layers and Inline Layers

The Columns of the Access Control Rule Base

Unified Rule Base Use Cases

Rule Matching in the Access Control Policy

Best Practices for Access Control Rules

Installing the Access Control Policy

Analyzing the Rule Base Hit Count

Preventing IP Spoofing

Translating IP Addresses

UserCheck Interactions in the Access Control Policy

Blade Settings

Introducing the Unified Access Control Policy

Define one, unified Access Control Policy. The Access Control Policy lets you create a simple and granular Rule Base that combines all these Access Control features:

There is no need to manage separate Rule Bases. For example, you can define one, intuitive rule that: Allows users in specified networks, to use a specified application, but prevents downloading files larger than a specified size. You can use all these objects in one rule:

Information about these features is collected in one log:

Creating a Basic Access Control Policy

A firewall controls access to computers, clients, servers, and applications using a set of rules that make up an Access Control Rule Base. You need to configure a Rule Base with secure Access Control and optimized network performance.

A strong Access Control Rule Base:

Basic Rules

Best Practice - These are basic Access Control rules we recommend for all Rule Bases:

Note - There is also the implicit drop rule that drops all traffic that did not match all other rules. This rule does not create log entries. If you want to log the traffic, create an explicit Cleanup rule.

Use Case - Basic Access Control

This use case shows a Rule Base for a simple Access Control security policy. (The Hits, VPN and Content columns are not shown.)

No

Name

Source

Destination

Services & Applications

Action

Track

Install On

1

Admin Access to Gateways

Admins (Access Role)

Gateways-group

Any

Accept

Log

Policy Targets

2

Stealth

Any

Gateways-group

Any

Drop

Alert

Policy Targets

3

Critical subnet

Internal

Finance
HR
R&D

Any

Accept

Log

CorpGW

4

Tech support

TechSupport

Remote1-web

HTTP

Accept

Alert

Remote1GW

5

DNS server

Any

DNS

Domain UDP

Accept

None

Policy Targets

6

Mail and Web servers

Any

DMZ

HTTP
HTTPS
SMTP

Accept

Log

Policy Targets

7

SMTP

Mail

NOT Internal
net group

SMTP

Accept

Log

Policy Targets

8

DMZ & Internet

IntGroup

Any

Any

Accept

Log

Policy Targets

9

Cleanup rule

Any

Any

Any

Drop

Log

Policy Targets

Rule

Explanation

1

Admin Access to Gateways - SmartConsole administrators are allowed to connect to the Security Gateways.

2

Stealth - All internal traffic that is NOT from the SmartConsole administrators to one of the Security Gateways is dropped. When a connection matches the Stealth rule, an alert window opens in SmartView Monitor.

3

Critical subnet - Traffic from the internal network to the specified resources is logged. This rule defines three subnets as critical resources: Finance, HR, and R&D.

4

Tech support - Allows the Technical Support server to access the Remote-1 web server which is behind the Remote-1 Security Gateway. Only HTTP traffic is allowed. When a packet matches the Tech support rule, the Alert action is done.

5

DNS server - Allows UDP traffic to the external DNS server. This traffic is not logged.

6

Mail and Web servers - Allows incoming traffic to the mail and web servers that are located in the DMZ. HTTP, HTTPS, and SMTP traffic is allowed.

7

SMTP - Allows outgoing SMTP connections to the mail server. Does not allow SMTP connections to the internal network, to protect against a compromised mail server.

8

DMZ and Internet - Allows traffic from the internal network to the DMZ and Internet.

9

Cleanup rule - Drops all traffic that does not match one of the earlier rules.

Use Case - Inline Layer for Each Department

This use case shows a basic Access Control Policy with a sub-policy for each department. The rules for each department are in an Inline Layer. An Inline Layer is independent of the rest of the Rule Base. You can delegate ownership of different Layers to different administrators.

No

Name

Source

Destination

Services & Applications

Content

Action

Track

1

Critical subnet

Internal

Finance

HR

Any

Any

Accept

Log

2

SMTP

Mail

NOT internal network (Group)

SMTP

Any

Accept

Log

3

R&D department

R&D Roles

Any

Any

Any

TechSupport Layer

N/A

3.1

R&D servers

Any

R&D servers (Group)

QA network

Any

Any

Accept

 

Log

3.2

R&D source control

InternalZone

Source control servers (Group)

ssh, http, https

Any

Accept

Log

---

---

---

---

---

---

---

---

3.X

Cleanup rule

Any

Any

Any

Any

Drop

Log

4

QA department

QA network

Any

Any

Any

QA Layer

N/A

4.1

Allow access to R&D servers

Any

R&D Servers (Group)

Web Services

Any

Accept

Log

----

---

---

---

---

---

---

---

4.Y

Cleanup rule

Any

Any

Any

Any

Drop

Log

5

Allow all users to access employee portal

Any

Employee portal

Web Services

Any

Accept

None

---

---

---

---

---

---

---

---

9

Cleanup rule

Any

Any

Any

Any

Drop

Log


Rules

Explanation

1

2

General rules for the whole organization.

3

3.1
3.2
---
3.X

An Inline Layer for the R&D department.

Rule 3 is the parent rules of the Inline Layer. The Action is the name of the Inline Layer.

If a packet does not match on parent rule 3:

Matching continues to the next rule outside the Inline Layer (rule 4).

If a packet matches on parent rule 3:

Matching continues to 3.1, first rule inside the Inline Layer. If a packet matches on this rule, the rule action is done on the packet.

If a packet does not match on rule 3.1, continue to the next rule inside the Inline Layer, rule 3.2. If there is no match, continue to the remaining rules in the Inline Layer. --- means one or more rules.

The packet is matched only inside the inline layer. It never leaves the inline layer, because the inline layer has an implicit cleanup rule. It is not matched on rules 4, 5 and the other rules in the Ordered Layer.

Rule 3.X is a cleanup rule. It drop all traffic that does not match one of the earlier rules in the Inline Layer. This is a default explicit rule. You can change or delete it.

Best Practice - Have an explicit cleanup rule as the last rule in each Inline Layer and Ordered Layer.

4

4.1
---
4.Y

Another Inline Layer, for the QA department.

5

More general rules for the whole organization.

--

One or more rules.

9

Cleanup rule - Drop all traffic that does not match one of the earlier rules in the Ordered Layer. This is a default explicit rule. You can change or delete it.

Best Practice - Have an explicit cleanup rule as the last rule in each Inline Layer and Ordered Layer.

Creating Application Control and URL Filtering Rules

Create and manage the Policy for Application Control and URL Filtering in the Access Control Policy, in the Access Control view of SmartConsole. Application Control and URL Filtering rules define which users can use specified applications and sites from within your organization and what application and site usage is recorded in the logs.

To learn which applications and categories have a high risk, look through the Application Wiki in the Access Tools part of the Security Policies view. Find ideas for applications and categories to include in your Policy.

To see an overview of your Access Control Policy and traffic, see the Access Control view in Logs & Monitor > New Tab > Views.

Monitoring Applications

Scenario: I want to monitor all Facebook traffic in my organization. How can I do this?

To monitor all Facebook application traffic:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Choose a Layer with Applications and URL Filtering enabled.
  3. Click one of the Add rule toolbar buttons to add the rule in the position that you choose in the Rule Base. The first rule matched is applied.
  4. Create a rule that includes these components:
    • Name - Give the rule a name, such as Monitor Facebook.
    • Source - Keep it as Any so that it applies to all traffic from the organization.
    • Destination - Keep it as Internet so that it applies to all traffic going to the internet or DMZ.
    • Services & Applications - Click the plus sign to open the Application viewer. Add the Facebook application to the rule:
      • Start to type "face" in the Search field. In the Available list, see the Facebook application.
      • Click each item to see more details in the description pane.
      • Select the items to add to the rule.

      Note - Applications are matched by default on their Recommended services. You can change this. Each service runs on a specific port. The recommended Web Browsing Services are http, https, HTTP_proxy, and HTTPS_proxy.

    • Action - Select Accept
    • Track - Select Log
    • Install On - Keep it as Policy Targets for or all gateways, or choose specific Security Gateways on which to install the rule

The rule allows all Facebook traffic but logs it. You can see the logs in the Logs & Monitor view, in the Logs tab. To monitor how people use Facebook in your organization, see the Access Control view (SmartEvent Server required).

Blocking Applications and Informing Users

Scenario: I want to block pornographic sites in my organization, and tell the user about the violation. How can I do this?

To block an application or category of applications and tell the user about the policy violation:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Choose a Layer with Applications and URL Filtering enabled.
  3. Create a rule that includes these components:
    • Services & Applications - Select the Pornography category.
    • Action - Drop, and a UserCheck Blocked Message - Access Control

      The message informs users that their actions are against company policy and can include a link to report if the website is included in an incorrect category.

    • Track - Log

      Note - This Rule Base example contains only those columns that are applicable to this subject.

      Name

      Source

      Destination

      Services & Applications

      Action

      Track

      Install On

      Block Porn

      Any

      Internet

      Pornography (category)

      Drop
      Blocked Message

      Log

      Policy Targets

The rule blocks traffic to pornographic sites and logs attempts to access those sites. Users who violate the rule receive a UserCheck message that informs them that the application is blocked according to company security policy. The message can include a link to report if the website is included in an incorrect category.

Important - A rule that blocks traffic, with the Source and Destination parameters defined as Any, also blocks traffic to and from the Captive Portal.

Limiting Application Traffic

Scenario: I want to limit my employees' access to streaming media so that it does not impede business tasks.

If you do not want to block an application or category, there are different ways to set limits for employee access:

The example rule below:

To create a rule that allows streaming media with time and bandwidth limits:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Choose a Layer with Applications and URL Filtering enabled.
  3. Click one of the Add Rule toolbar buttons to add the rule in the position that you choose in the Rule Base.
  4. Create a rule that includes these components:
    • Services & Applications - Media Streams category.

      Note - Applications are matched on their Recommended services, where each service runs on a specific port, such as the default Application Control Web browsing Services: http, https, HTTP_proxy, and HTTPS_proxy. To change this see Services & Applications Column.

    • Action - Click More and select Action:Accept, and a Limit object.
    • Time - Add a Time object that specifies the hours or time period in which the rule is active.

      Note - The Time column is not shown by default in the Rule Base table. To see it, right-click on the table header and select Time.

      Name

      Source

      Destination

      Services and Applications

      Action

      Track

      Install On

      Time

      Limit Streaming Media

      Any

      Internet

      Media Streams (Category)

      Accept
      Upload_1Gbps

      Log

      All

      Off-Work

Note - In a cluster environment, the specified bandwidth limit is divided between all defined cluster members, whether active or not. For example, if a rule sets 1Gbps limit in a three member cluster, each member has a fixed limit of 333 Mbps.

Using Identity Awareness Features in Rules

Scenario: I want to allow a Remote Access application for a specified group of users and block the same application for other users. I also want to block other Remote Access applications for everyone. How can I do this?

If you enable Identity Awareness on a Security Gateway, you can use it together with Application Control to make rules that apply to an access role. Use access role objects to define users, machines, and network locations as one object.

In this example:

To do this, add two new rules to the Rule Base:

  1. Create a rule and include these components:
    • Source - The Identified_Users access role
    • Destination - Internet
    • Services & Applications - Radmin
    • Action - Accept
  2. Create another rule below and include these components:
    • Source - Any
    • Destination - Internet
    • Services & Applications - The category: Remote Administration
    • Action - Block

      Name

      Source

      Destination

      Services & Applications

      Action

      Track

      Install On

      Allow Radmin to Identified Users

      Identified_Users

      Internet

      Radmin

      Allow

      Log

      All

      Block other Remote Admins

      Any

      Internet

      Remote Administration

      Block

      Log

      All

Notes on these rules:

Blocking Sites

Scenario: I want to block sites that are associated with categories that can cause liability issues. Most of these categories exist in the Application Database but there is also a custom defined site that must be included. How can I do this?

You can do this by creating a custom group and adding all applicable categories and the site to it. If you enable Identity Awareness on a Security Gateway, you can use it together with URL Filtering to make rules that apply to an access role. Use access role objects to define users, machines, and network locations as one object.

In this example:

To create a custom group:

  1. In the Object Explorer, click New > More > Custom Application/Site > Application/Site Group.
  2. Give the group a name. For example, Liability_Sites.
  3. Click + to add the group members:
    • Search for and add the custom application FreeMovies.
    • Select Categories, and add the ones you want to block (for example Anonymizer, Critical Risk, and Gambling)
    • Click Close
  4. Click OK.

You can now use the Liability_Sites group in the Access Control Rule Base.

In the Rule Base, add a rule similar to this:

In the Security Policies view of SmartConsole, go to the Access Control Policy.


Name

Source

Destination

Services & Applications

Action

Track

Block sites that may cause a liability

Identified_Users

Internet

Liability_Sites

Drop

Log

Blocking URL Categories

Scenario: I want to block pornographic sites. How can I do this?

You can do this by creating a rule that blocks all sites with pornographic material with the Pornography category. If you enable Identity Awareness on a Security Gateway, you can use it together with URL Filtering to make rules that apply to an access role. Use access role objects to define users, machines, and network locations as one object.

In this example:

The procedure is similar to Blocking Applications and Informing Users.

In the Rule Base, add a rule similar to this:

Ordered Layers and Inline Layers

A policy is a set of rules that the gateway enforces on incoming and outgoing traffic. There are different policies for Access Control and for Threat Prevention.

You can organize the Access Control rules in more manageable subsets of rules using Ordered Layers and Inline Layers.

In This Section

The Need for Ordered Layers and Inline Layers

Order of Rule Enforcement in Inline Layers

Order of Rule Enforcement in Ordered Layers

Creating an Inline Layer

Creating a Ordered Layer

Enabling Access Control Features

Types of Rules in the Rule Base

Administrators for Access Control Layers

Sharing Layers

Visual Division of the Rule Base with Sections

Exporting Layer Rules to a .CSV File

Managing Policies and Layers

The Need for Ordered Layers and Inline Layers

Ordered Layers and Inline Layers helps you manage your cyber security more efficiently. You can:

Order of Rule Enforcement in Inline Layers

The Ordered Layer can contain Inline Layers.

This is an example of an Inline Layer:

No.

Source

Destination

VPN

Services

Action

1

 

 

 

 

 

2

Lab_network

Any

Any

Any

Lab_rules

 

2.1

Any

Any

Any

https

http

Allow

 

2.2

Any

Any

Any

Any

Drop

3

 

 

 

 

 

The Inline Layer has a parent rule (Rule 2 in the example), and sub rules (Rules 2.1 and 2.2). The Action of the parent rule is the name of the Inline Layer.

If the packet does not match the parent rule of the Inline Layer, the matching continues to the next rule of the Ordered Layer (Rule 3).

If a packet matches the parent rule of the Inline Layer (Rule 2), the Firewall checks it against the sub rules:

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

Order of Rule Enforcement in Ordered Layers

When a packet arrives at the gateway, the gateway checks it against the rules in the first Ordered 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 Ordered Layer.

Item

Description

 

1

Ordered Layer 1

 

2

Ordered Layer 2

 

3

Ordered Layer 3

 

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

Every Ordered Layer has its own implicit cleanup rule. You can configure the rule to Accept or Drop in the Layer settings.

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

Creating an Inline Layer

An Inline Layer is a sub-policy which is independent of the rest of the Rule Base. 

The workflow for making an Inline Layer is:

  1. Create a parent rule for the Inline Layer. Make a rule that has one or more properties that are the same for all the rules in the Inline Layer. For example, rules that have the same source, or service, or group of users.
  2. Create sub-rules for the Inline Layer. These are rules that define in more detail what to do if the Firewall matches a connection to the parent rule. For example, each sub-rule can apply to specified hosts, or users, or services, or Data Types.

To create an Inline Layer:

  1. Add a rule to the Ordered Layer. This is the parent rule.
  2. In the Source, Destination, VPN, and Services & Applications cells, define the match conditions for the Inline Layer.
  3. Click the Action cell of the rule. Instead of selecting a standard action, select Inline Layer > New Layer.
  4. The Layer Editor window opens.
  5. Configure the properties of the Inline Layer:
    1. Enable one or more of these Blades for the rules of Inline Layer:
      • Firewall
      • Application Control and URL Filtering
      • Content Awareness
      • Mobile Access
    2. Optional: It is a best practice to share Layers with other Policy packages when possible. To enable this select Multiple policies can use this layer.
    3. Click Advanced.
    4. Configure the Implicit Cleanup Rule to Drop or Accept.
    5. Click OK.

    The name of the Inline Layer shows in the Action cell of the rule.

  6. Under the parent rule of the Inline Layer, add sub-rules.
  7. Make sure there is an explicit cleanup rule as the last rule of the Inline Layer.

Creating a Ordered Layer

To create a Ordered Layer:

  1. In SmartConsole, click Menu > Manage Policies and Layers.
  2. In the left pane, click Layers.

    You will see a list of the Layers. You can select Show only shared Layers.

  3. Click the New icon in the upper toolbar.
  4. Configure the settings in the Layer Editor window.
  5. Optional: It is a best practice to share Layers with other Policy packages when possible. To enable this select Multiple policies can use this layer.
  6. Click OK.
  7. Click Close.
  8. Publish the session.

    This Ordered Layer is not yet assigned to a Policy Package.

To add a Ordered Layer to the Access Control Policy:

  1. In SmartConsole, click Security Policies.
  2. Right-click a Layer in the Access Control Policy section and select Edit Policy.

    The Policy window opens.

  3. In the Access Control section, click the plus sign.

    You will see a list of the Layers that you can add. These are Layers that have Multiple policies can use this layer enabled.

  4. Select the Layer.
  5. Click OK.
  6. Publish the session.

Pre-R80.10 Gateways: To create a Layer for URL Filtering and Application Control:

  1. In SmartConsole, click Security Policies.
  2. Right-click a Layer in the Access Control Policy section and select Edit Policy.

    The Policy window opens.

  3. In the Access Control section, click the plus sign.
  4. Click New Layer.

    The Layer Editor window opens and shows the General view.

  5. Enable Application Control and URL Filtering on the Layer.
    1. Enter a name for the Layer.

      We recommend the name Application.

    2. In the Blades section, select Applications & URL Filtering.
    3. Click OK and the Layer Editor window closes.
    4. Click OK and the Policy window closes.
  6. Publish the session.

Enabling Access Control Features

Before creating the Access Control Policy, you must enable the Access Control features that you will use in the Policy.

Enable the features on the:

Enabling Access Control Features on a Gateway

  1. In SmartConsole, go to Gateways & Servers and double-click the gateway object.

    The General Properties window of the gateway opens.

  2. From the navigation tree, click General Properties.
  3. In the Network Security tab, select one or more of these Access Control features:
    • IPsec VPN
    • Mobile Access
    • Application Control
    • URL Filtering
    • Content Awareness
    • Identity Awareness
  4. Click OK.

Enabling Access Control Features on a Layer

To enable the Access Control features on an Ordered Layer:

  1. In SmartConsole, click Security Policies.
  2. Under Access Control, right-click Policy and select Edit Policy.
  3. Click options for the Layer.
  4. Click Edit Layer.

    The Layer Editor window opens and shows the General view.

  5. Enable the Blades that you will use in the Ordered Layer:
    • Firewall.
    • Applications & URL Filtering
    • Content Awareness
    • Mobile Access
  6. Click OK.

To enable the Access Control features on an Inline Layer:

  1. In SmartConsole, click Security Policies.
  2. Select the Ordered Layer.
  3. In the parent rule of the Inline Layer, right-click the Action column, and select Inline Layer > Edit Layer.
  4. Enable the Blades that you will use in the Inline Layer:
    • Firewall.
    • Applications & URL Filtering
    • Content Awareness
    • Mobile Access

    Note - Do not enable a Blade that is not enabled in the Ordered Layer.

  5. Click OK.

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 default Cleanup rule is an explicit rule that is added by default to 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:

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:

Implicit cleanup rule

The default "catch-all" rule for the Layer that deals with traffic that does not match any explicit or implied rules in the Layer. It is made automatically when you create a Layer.

Implicit cleanup rules do not show in the Rule Base.

For R80.10 later version Security Gateways, the default implicit cleanup rule action is Drop. This is because most Policies have Whitelist rules (the Accept action). If the Layer has Blacklist rules (the Drop action), you can change the action of the implicit cleanup rule to Accept in the Layer Editor.

For R77.30 or earlier versions Security Gateways, the action of the implicit rule depends on the Ordered Layer:

Note - If you change the default values, the policy installation will fail on R77.30 or earlier versions Security Gateways.

Order in which the Firewall Applies the Rules

  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 Layer match.

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, select the Access Control Policy.
  2. From the toolbar above the policy, select Actions > Implied Rules.

    The Implied Policy window opens.

  3. In the left pane, click Configuration.
  4. Select a rule to enable it, or clear a rule to disable it.
  5. For the enabled rules, select the position of the rules in the Rule Base: First, Last, or Before Last.
  6. Click OK and install the policy.

Showing the Implied Rules

To see the implied rules:

In SmartConsole, from the Security Policies View, select Actions > Implied Rules.

The Implied Policy window opens.

It shows only the implied rules, not the explicit rules.

Configuring the Implicit Cleanup Rule

To configure the Implicit Cleanup Rule:

  1. In SmartConsole, click Menu > Manage Policies and Layers.
  2. In the left pane, click Layers.
  3. Select a Layer and click Edit.

    The Layer Editor opens.

  4. Click Advanced
  5. Configure the Implicit Cleanup Rule to Drop or Accept.
  6. Click OK.
  7. Click Close.
  8. Publish the session.

Administrators for Access Control Layers

You can create administrator accounts dedicated to the role of Access Control, with their own installation and SmartConsole Read/Write permissions.

You can also delegate ownership of different Layers to different administrators.

To learn how to configure administrator permissions for Layers, see the R80.10 Security Management Administration Guide.

Sharing Layers

You may need to use the same rules in different parts of a Policy, or have the same rules in multiple Policy packages.

There is no need to create the rules multiple times. Define an Ordered Layer or an Inline Layer one time, and mark it as shared. You can then reuse it in multiple Policy packages. You can reuse an Inline Layer in multiple places in an Ordered Layers, or in multiple Layers.

Best Practice - Share Ordered Layers and Inline Layers with other Policy packages when possible.

To share a Layer:

  1. In SmartConsole, click Menu > Manage policies and layers.
  2. In the left pane, click Layers.
  3. Optional: Select Show only Shared Layers.
  4. Select a Layer.
  5. Right-click and select Edit Layer.
  6. Configure the settings in the Layer Editor window.
  7. Select Multiple policies and rules can use this layer.
  8. Click OK.
  9. Click Close.
  10. Publish the session.

Visual Division of the Rule Base with Sections

To better manage a policy with a large number of rules, you can use Sections to divide the Rule Base into smaller, logical components. The division is only visual and does not make it possible to delegate administration of different Sections to different administrators.

Exporting Layer Rules to a .CSV File

You can export Layer rules to a .csv file. You can open and change the .csv file in a spreadsheet application such as Microsoft Excel.

To export Layer rules to a .csv file:

  1. In SmartConsole, click Menu > Manage Policies and Layers.

    The Manage Layers window opens.

  2. Click Layers.
  3. Select a Layer, and then click Actions > Export selected Layer.
  4. Enter a path and file name.

Managing Policies and Layers

To work with Ordered Layers and Inline Layers in the Access Control Policy, select Menu > Manage policies and layers in SmartConsole.

The Manage policies and layers window shows.

To see the Layer in the policy package and their attributes:

In the Layers pane of the window, you can see:

To see the rules in the Layer:

  1. Select a Layer.
  2. Right-click and select Open layer in policy.

The Columns of the Access Control Rule Base

These are the columns of the rules in the Access Control policy. Not all of these are shown by default. To select a column that does not show, right-click on the header of the Rule Base, and select it.

Column

Description

No.

Rule number in the Rule Base Layer.

Hits

Number of times that connections match a rule.

Name

Name that the system administrator gives this rule.

Source

Destination

Network objects that define

  • Where the traffic starts
  • The destination of the traffic.

VPN

The VPN Community to which the rule applies.

Services & Applications

Services, Applications, Categories, and Sites.
If Application Control and URL Filtering is not enabled, only Services show.

Content

The data asset to protect, for example, credit card numbers or medical records.

You can set the direction of the data to Download Traffic (into the organization), Upload Traffic (out of the organization), or Any Direction.

Action

Action that is done when traffic matches the rule. Options include: Accept, Drop, Ask, Inform (UserCheck message), Inline Layer, and Reject.

Track

Tracking and logging action that is done when traffic matches the rule.

Install On

Network objects that will get the rule(s) of the policy.

Time

Time period that this rule is enforced.

Comment

An optional field that lets you summarize the rule.

Source and Destination Column

In the Source and Destination columns of the Access Control Policy Rule Base, you can add Network objects including groups of all types. Here are some of the network objects you can include:

To Learn More About Network Objects

To learn more about Network objects that you can add to the Source and Destination columns of the Access Control Policy, see the R80.10 Security Management Administration Guide.

VPN Column

You can configure rules for Site-to-Site VPN, Remote Access VPN, and the Mobile Access portal and clients.

To make a rule for a VPN Community, add a Site to Site Community or a Remote Access VPN Community object to this column, or select Any to make the rule apply to all VPN Communities.

When you enable Mobile Access on a gateway, the gateway is automatically added to the RemoteAccess VPN Community. Include that Community in the VPN column of the rule or use Any to make the rule apply to Mobile Access gateways. If the gateway was removed from the VPN Community, the VPN column must contain Any.

IPsec VPN

The IPsec VPN solution lets the Security Gateway encrypt and decrypt traffic to and from other gateways and clients. Use SmartConsole to easily configure VPN connections between Security Gateways and remote devices.

For Site to Site Communities, you can configure Star and Mesh topologies for VPN networks, and include third-party gateways.

The VPN tunnel guarantees:

IKE and IPsec

The Check Point VPN solution uses these secure VPN protocols to manage encryption keys, and send encrypted packets. IKE (Internet Key Exchange) is a standard key management protocol that is used to create the VPN tunnels. IPsec is protocol that supports secure IP communications that are authenticated and encrypted on private or public networks.

Mobile Access to the Network

Check Point Mobile Access lets remote users easily and securely use the Internet to connect to internal networks. Remote users start a standard HTTPS request to the Mobile Access Security Gateway, and authenticate with one or more secure authentication methods.

The Mobile Access Portal lets mobile and remote workers connect easily and securely to critical resources over the internet. Check Point Mobile Apps enable secure encrypted communication from unmanaged smartphones and tablets to your corporate resources. Access can include internal apps, email, calendar, and contacts.

To include access to Mobile Access applications in the Rule Base, include the Mobile Application in the Services & Applications column.

To give access to resources through specified remote access clients, create Access Roles for the clients and include them in the Source column of a rule.

To Learn More About VPN

To learn more about VPN and Remote Access, see these guides:

Services & Applications Column

In the Services & Applications column of the Access Control Rule Base, define the applications, sites, and services that are included in the rule. A rule can contain one or more:

Service Matching

The Firewall identifies (matches) a service according to IP protocol, TCP and UDP port number, and protocol signature.

To make it possible for the Firewall to match services by protocol signature, you must enable Applications and URL Filtering on the Gateway and on the Ordered Layer.

You can configure TCP and UDP services to be matched by source port.

Application Matching

If an application is allowed in the policy, the rule is matched only on the Recommended services of the application. This default setting is more secure than allowing the application on all services. For example: a rule that allows Facebook, allows it only on the Application Control Web Browsing Services: http, https, HTTP_proxy, and HTTPS_proxy.

If an application is blocked in the policy, it is blocked on all services. It is therefore blocked on all ports.

You can change the default match settings for applications.

Configuring Matching for an Allowed Application

You can configure how a rule matches an application or category that is allowed in the policy. You can configure the rule to match the application in one of these ways:

To do this, change the Match Settings of the application or category. The application or category is changed everywhere that it is used in the policy.

To change the matched services for an allowed application or category:

  1. In a rule which has applications or categories in the Services & Applications column, double-click an application or category.
  2. Select Match Settings.
  3. Select an option:
    • The default is Recommended services. The defaults for Web services are the Application Control Web Browsing Services.
    • To match the application with all services, click Any.
    • To match the application on specified services, click Customize, and add or remove services.
    • To match the application with all services and exclude specified services, click Customize, add the services to exclude, and select Negate.
  4. Click OK.

Configuring Matching for Blocked Applications

By default, if an application is blocked in the policy, it is blocked on all services. It is therefore blocked on all ports.

You can configure the matching for blocked applications so that they are matched on the recommended services. For Web applications, the recommended services are the Application Control Web browsing services.

If the match settings of the application are configured to Customize, the blocked application is matched on the customized services service. It is not matched on all ports.

To configure matching for blocked applications:

  1. In SmartConsole, go to Manage & Settings > Blades > Application Control and URL Filtering > Advanced Settings > Application Port Match
  2. Configure Match application on ‘Any’ port when used in ‘Block’ rule:
    • Selected - This is the default. If an application is blocked in the Rule Base, the application is matched to Any port.
    • Not selected - If an application is blocked in the Rule Base, the application is matched to the services that are configured in the application object of the application. However, some applications are still matched on Any. These are applications (Skype, for example) that do not limit themselves to a standard set of services.

Summary of Application Matching in a "Block" Rule

Application - Match Setting

Checkbox: Match web application on 'Any' port when used in 'Block' rule

Blocked Application is Matched on Service

Recommended services (default)

Selected (default)

Any

Recommended services (default)

Not selected

Recommended services

Customize

Not relevant

Customized

Any

Not relevant

Any

Adding Services, Applications, and Sites to a rule

You can add services, applications and sites to a rule.

Note - Rules with applications or categories do not apply to connections from or to the Security Gateway.

To add services, applications or sites to a rule:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. To add applications to a rule, select a Layer with Applications and URL Filtering enabled.
  3. Right-click the Services & Applications cell for the rule and select Add New Items.
  4. Search for the services, sites, applications, or categories.
  5. Click the + next to the ones you want to add.

Creating Custom Applications, Categories, and Groups

You can create custom applications, categories or groups, that are not included in the Check Point Application Database.

To create a new application or site:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Select a Layer with Applications and URL Filtering enabled.
  3. Right-click the Services & Applications cell for the rule and select Add New Items.

    The Application viewer window opens.

  4. Click New > Custom Applications/Site > Application/Site.
  5. Enter a name for the object.
  6. Enter one or more URLs.

    If you used a regular expression in the URL, click URLs are defined as Regular Expressions.

    Note - If the application or site URL is defined as a regular expression you must use the correct syntax.

  7. Click OK.

To create a custom category:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Select a Layer with Applications and URL Filtering enabled.
  3. Right-click the Services & Applications cell for the rule and select Add New Items.

    The Application viewer window opens.

  4. Click New > Custom Applications/Site > User Category.
  5. Enter a name for the object.
  6. Enter a description for the object.
  7. Click OK.

Services and Applications on R80 and Lower Gateways, and after Upgrade

For R77.xx and lower Gateways:

When you upgrade the Security Management Server and the Gateway to R80 and higher, this change of behavior occurs:

Content Column

You can add Data Types to the Content column of rules in the Access Control Policy.

To use the Content column, you must enable Content Awareness, in the General Properties page of the Security Gateway, and on the Layer.

A Data Type is a classification of data. The Firewall classifies incoming and outgoing traffic according to Data Types, and enforces the Policy accordingly.

You can set the direction of the data in the Policy to Download Traffic (into the organization), Upload Traffic (out of the organization), or Any Direction.

There are two kinds of Data Types: Content Types (classified by analyzing the file content) and File Types (classified by analyzing the file ID).

Content Type examples:

File type examples:

Note these limitations:

To learn more about the Data Types, open the Data Type object in SmartConsole and press the ? button (or F1) to see the Help.

Note - Content Awareness and Data Loss Prevention (DLP) both use Data Types. However, they have different features and capabilities. They work independently, and the Security Gateway enforces them separately.

To learn more about DLP, see the R80.10 Data Loss Prevention Administration Guide.

Actions

Action

Meaning

Accept

Accepts the traffic

Drop

Drops the traffic. The Firewall does not send a response to the originating end of the connection and the connection eventually does a time-out. If no UserCheck object is defined for this action, no page is displayed.

Ask

Asks the user a question and adds a confirmatory check box, or a reason box. Uses a UserCheck object.

Inform

Sends a message to the user attempting to access the application or the content. Uses a UserCheck object.

To see these actions, right-click and select More:

Reject

Rejects the traffic. The Firewall sends an RST packet to the originating end of the connection and the connection is closed.

UserCheck Frequency

Configure how often the user sees the configured message when the action is ask, inform, or block.

Confirm UserCheck

Select the action that triggers a UserCheck message:

  • Per rule - UserCheck message shows only once when traffic matches a rule.
  • Per category - UserCheck message shows for each matching category in a rule.
  • Per application/Site - UserCheck message shows for each matching application/site in a rule.
  • Per Data type - UserCheck message shows for each matching data type.

Limit

Limits the bandwidth that is permitted for a rule. Add a Limit object to configure a maximum throughput for uploads and downloads.

Enable Identity Captive Portal

Redirects HTTP traffic to an authentication (captive) portal. After the user is authenticated, new connections from this source are inspected without requiring authentication.

Important - A rule that drops traffic, with the Source and Destination parameters defined as Any, also drops traffic to and from the Captive Portal.

UserCheck Actions

UserCheck lets the Security Gateways send messages to users about possible non-compliant or dangerous Internet browsing. In the Access Control Policy, it works with URL Filtering, Application Control, and Content Awareness. (You can also use UserCheck in the Data Loss Prevention Policy, in SmartDashboard). Create UserCheck objects and use them in the Rule Base, to communicate with the users. These actions use UserCheck objects:

UserCheck on a Security Gateway

When UserCheck is enabled, the user's Internet browser shows the UserCheck messages in a new window.

You can enable UserCheck on Security Gateways that use:

UserCheck on a computer

The UserCheck client is installed on endpoint computers. This client:

Tracking Column

These are some of the Tracking options:

Unified Rule Base Use Cases

Here are some use cases that show examples of rules that you can define for the Access Control Policy.

Use Cases In this section:

Use Case - Application Control and Content Awareness Ordered Layer

Use Case - Inline Layer for Web Traffic

Use Case - Content Awareness Ordered Layer

Use Case - Application Control and URL Filtering Ordered Layer

Use Case - Application Control and Content Awareness Ordered Layer

This use case shows an example unified Access Control Policy. It controls applications and content in one Ordered Layer.

No.

Name

Source

Destination

VPN

Services & Applications

Content

Action

Track

General compliance (1)

1

Block categories

Any

Internet

Any

Anonymizer

Critical Risk

Any

Drop

  Block Message

Log

Block risky executables (2)

2

Block download of executables files from uncategorized and high risk sites

InternalZone

Internet

Any

Uncategorized

High Risk

Download Traffic

  Executable File

Drop

Log

Credit card data (3-4)

3

Allow uploading of credit cards numbers, by finance, and only over HTTPS

Finance (Access Role)

Web Servers

Any

https

Upload Traffic

  PCI – Credit Card Numbers

Accept

Log

4

Block other credit cards from company Web servers

Any

Web Servers

Any

Any

Any Direction

  PCI – Credit Card Numbers

Drop

Log

Inform about sensitive data over VPN (5)

5

Inform the user about sensitive data from VPN sites

Any

Any

RemoteAccess

Any

Any Direction

  Salary Survey Report

Inform

Log

cleanup (6)

6

Cleanup rule

Any

Any

Any

Any

Any

Accept

Log


Rule

Explanation

1

General Compliance section - Block access to unacceptable Web sites and applications.

2

Block risky executables section - Block downloading of high risk executable files.

3-4

Credit card data section - Allow uploading of credit cards numbers only by the finance department, and only over HTTPS. Block other credit cards.

5

Block sensitive data over VPN section - A remote user that connects over the organization's VPN sees an informational message.

6

cleanup rule - Accept all traffic that does not match one of the earlier rules.

Use Case - Inline Layer for Web Traffic

This use case shows an example Access Control Policy that controls Web traffic. The Web server rules are in an Inline Layer.

No

Name

Source

Destination

Services &
Applications

Content

Action

Track

1

Headquarter WEB traffic - via proxy

HQ

Proxy

Web Proxy

Any

Ask

Web Access Policy
  Access Noti...
once a day
per applic...

Log

2

Allow Proxy to the Internet

Proxy

Internet

Web

Any

Accept

None

3

Allow local branch to access the internet directly

Local Branch

Internet

Web

Any

Ask

  Web Access Policy
  Access Noti...
once a day
per applic...

Log

4

Web Servers

InternalZone

Web Servers

Web

Any

Web Servers protection

N/A

4.1

Block browsing with unapproved browsers

Any

Any

NEGATED

Google Chrome
Internet Explorer 11
Firefox
Safari

Any

Drop

Log

4.2

Inform user when uploading Credit Cards only over HTTPS

Any

Any

https

Upload Traffic

PCI - Credit Card Numbers

Inform

  Access Noti...
once a day
per applic...

Log

4.3

Block Credit Cards

Any

Any

Any

Any Direction

PCI - Credit Card Numbers

Drop

Block Message

Log

4.4

Block downloading of sensitive content

Any

Any

Any

Download Traffic

HIPAA - Medical Record Headers

Drop

Log

4.5

Cleanup rule

Any

Any

Any

Any

Accept

None

5

Ask user when sending credit cards to PayPal

InternalZone

Internet

PayPal

Any Direction

PCI - Credit Card Numbers

Ask

Company Policy
  Access Noti...
once a day
per applic...

Log

6

Cleanup rule

Any

Any

Any

Any

Drop

Log


Rule

Explanation

4

This is the parent rule of the Inline Layer. The Action is the name of the Inline Layer. If a packet matches on the parent rule, the matching continues to rule 4.1 of the Inline Layer. If a packet does not match on the parent rule, the matching continues to rule 5.

4.1
-4.4

If a packet matches on rule 4.1, the rule action is done on the packet, and no more rule matching is done. If a packet does not match on rule 4.1, continue to rule 4.2. The same logic applies to the remaining rules in the Inline Layer.

4.5

If none of the higher rules in the Ordered Layer match the packet, the explicit Cleanup Rule is applied. The Cleanup rule is a default explicit rule. You can change or delete it. We recommend that you have an explicit cleanup rule as the last rule in each Inline Layer and Ordered Layer.

Use Case - Content Awareness Ordered Layer

This use case shows a Policy that controls the upload and download of data from and to the organization.

There is an explanation of some of the rules below the Rule Base.

No

Name

Source

Destination

Services & Applications

Content

Action

Track

 Regulatory compliance

1

Block the download of executable files

InternalZone

Internet

Any

Download Traffic

Executable file

Drop

Log

2

Allow uploading of credit cards numbers by finance users, only over HTTPS

Finance (Access Role)

Web Servers

https

Upload Traffic

  PCI – Credit Card Numbers

Accept

Log

3

Block other credit cards from company Web servers

InternalZone

Web Servers

Any

Any Direction

  PCI – Credit Card Numbers

Drop

  Block Message

Log

  Personally Identifiable Information

 4

Matches U.S. Social Security Numbers (SSN) allocated by the U.S. Social Security Administration (SSA).

InternalZone

Internet

Any

Upload Traffic

  U.S. Social Security Numbers - According to SSA

Inform

  Access Notifi...
once a day
per applicati...

Log

5

Block downloading of sensitive medical information

InternalZone

Internet

Any

Download Traffic

  HIPAA – Medical Records Headers

Drop

  Block Message

Log

  Human Resources

6

Ask user when uploading documents containing salary survey reports.

InternalZone

Internet

Any

Upload Traffic

  Salary Survey Report

Ask

  Company Policy
once a day
per applicati...

Log

  Intellectual Property

7

Matches data containing source code

InternalZone

Internet

Any

Any Direction

Source Code

Restrict source code

N/A

7.1

 

Any

Any

Any

Download Traffic

  Source Code

Accept

Log

7.2

 

Any

Any

Any

Upload Traffic

  Source Code

Ask

  Company Policy
once a day
per applicati...

Log

7.3

Cleanup Inline Layer

Any

Any

Any

Any

Drop

  Block Message

Log


Rule

Explanation

1-3

Regulatory Compliance section - Control the upload and download of executable files and credit cards.

You can set the direction of the Content. In rule 1 it is Download Traffic, in rule 2 it is Upload Traffic, and in rule 3 it is Any Direction.

Rule 1 controls executable files, which are File Types. The File Type rule is higher in the Rule Base than rules with Content Types (Rules 2 to 7). This improves the efficiency of the Rule Base, because File Types are matched sooner than Content Types.

4-5

Personally Identifiable Information section - Controls the upload and download of social security number and medical records.

The rule Action for rule 4 is Inform. When an internal user uploads a file with a social security number, the user sees a message.

6

Human resources section - controls the sending of salary survey information outside of the organization.

The rule action is Ask. If sensitive content is detected, the user must confirm that the upload complies with the organization's policy.

7

Intellectual Property section - A group of rules that control how source code leaves the organization.

Rule 7 is the parent rule of an Inline Layer. The Action is the name of the Inline Layer.

If a packet matches on rule 7.1, matching stops.

If a packet does not match on rule 7.1, continue to rule 7.2. In a similar way, if there is no match, continue to 7.3. The matching stops on the last rule of the Inline Layer. We recommend that you have an explicit cleanup rule as the last rule in each Inline Layer

Use Case - Application Control and URL Filtering Ordered Layer

This use case shows some examples of URL Filtering and Application Control rules for a typical policy that monitors and controls Internet browsing. (The Hits, VPN and Install On columns are not shown.)

No.

Name

Source

Destination

Services & Applications

Action

Track

Time

1

Liability sites

Any

Internet

Potential
liability (group)

Drop

Blocked Message

Log

Any

2

High risk applications

Any

Internet

High Risk

iTunes

Anonymizer (category)

Drop

Blocked Message

Log

Any

3

Allow IT department Remote Admin

IT (Access Role)

Any

Radmin

Allow

Log

Work-
Hours

4

Allow Facebook for HR

HR(Access Role)

Internet

Facebook

Allow

Download_1Gbps

Log

Any

5

Block these categories

Any

Internet

Streaming Media Protocols

Social Networking

P2P File Sharing

Remote Administration

Drop

Blocked Message

Log

Any

6

Log all applications

Any

Internet

Any

Allow

Log

Any


Rule

Explanation

1

Liability sites- Blocks traffic to sites and applications in the custom Potential_liability group. The UserCheck Blocked Message is shown to users and explains why their traffic is blocked.

2

High risk applications - Blocks traffic to sites and applications in the High Risk category and blocks the iTunes application. The UserCheck Block Message is shown to users and explains why their traffic is blocked.

3

Allow IT department Remote Admin - Allows the computers in the IT department network to use the Radmin application. Traffic that uses Radmin is allowed only during the Work-Hours (set to 8:00 through 18:30, for example).

4

Allow Facebook for HR - Allows computers in the HR network to use Facebook. The total traffic downloaded from Facebook is limited to 1 Gbps, there is no upload limit.

5

Block these categories - Blocks traffic to these categories: Streaming Media, Social Networking, P2P File Sharing, and Remote Administration. The UserCheck Blocked Message is shown to users and explains why their traffic is blocked.

Note - The Remote Administration category blocks traffic that uses the Radmin application. If this rule is placed before rule 3, then this rule can also block Radmin for the IT department.

6

Log all applications- Logs all traffic that matches any of the URL Filtering and Application Control categories.

Rule Matching in the Access Control Policy

The Firewall determines the rule to apply to a connection. This is called matching a connection. Understanding how the firewall matches connections will help you:

Examples of Rule Matching

These example Rule Bases show how the Firewall matches connections.

Note that these Rule Bases intentionally do not follow Best Practices for Access Control Rules . This is to make the explanations of rule matching clearer.

Rule Base Matching - Example 1

For this Rule Base:

No.

Source

Destination

Services &
Applications

Content

Action

1

InternalZone

Internet

ftp-pasv

Download executable file

Drop

2

Any

Any

Any

Executable file

Accept

3

Any

Any

Gambling (Category)

Any

Drop

4

Any

Any

Any

Any

Accept

This is the matching procedure for an FTP connection:

Part of connection

Firewall action

Inspection result

SYN

Run the Rule Base:

Look for the first rule that matches:

  • Rule 1 – Match.

Final match (drop on rule 1).

Shows in the log.

The Firewall does not turn on the inspection engines for the other rules.

Rule Base Matching - Example 2

For this Rule Base:

No.

Source

Destination

Services &
Applications

Content

Action

1

InternalZone

Internet

Any

Download executable file

Drop

2

Any

Any

Gambling (category)

Any

Drop

3

Any

Any

ftp

Any

Drop

4

Any

Any

Any

Any

Accept

This is the matching procedure when browsing to a file sharing Web site. Follow the rows from top to bottom. Follow each row from left to right:

Part of connection

Firewall action

Inspection result

SYN

Run the Rule Base.

Look for the first rule that matches:

  • Rule 1 - Possible match.
  • Rule 2 - Possible match.
  • Rule 3 - No match.
  • Rule 4 - Match.

Possible match (Continue to inspect the connection).

HTTP Header

The Firewall turns on inspection engines to examine the data in the connection.

In this example turn on the:

  • URL Filtering engine – Is it a gambling site?
  • Content Awareness engine - Is it an executable file?

Application: File sharing (category).

Content: Don’t know yet.

 

 

Optimize the Rule Base matching.

Look for the first rule that matches:

  • Rule 1 - Possible match.
  • Rule 2 - No match.
  • Rule 3 - No match.
  • Rule 4 - Match.

Possible match (Continue to inspect the connection).

HTTP Body

Examine the file.

Data: PDF file.

 

Optimize the Rule Base matching.

Look for the first rule that matches:

  • Rule 1 - No match.
  • Rule 2 - No match.
  • Rule 3 - No match.
  • Rule 4 - Match.

Final match (accept on rule 4).

Shows in the log.

Rule Base Matching - Example 3

For this Rule Base:

No.

Source

Destination

Services &
Applications

Content

Action

1

InternalZone

Internet

Any

Download executable file

Drop

2

Any

Any

Gambling (Category)

Any

Drop

3

Any

Any

Any

Any

Accept

This is the matching procedure when downloading an executable file from a business Web site. Follow the rows from top to bottom. Follow each row from left to right:

Part of connection

Firewall action

Inspection result

SYN

Run the Rule Base.

Look for the first rule that matches:

  • Rule 1 – Possible match.
  • Rule 2 – Possible match.
  • Rule 3 – Match.

Possible match (Continue to inspect the connection).

HTTP Header

The Firewall turns on inspection engines to examine the content in the connection.

In this example turn on the:

  • URL Filtering engine – Is it a gambling site?
  • Content Awareness engine - Is it an executable file?

Application: Business (Category).

Content: Don’t know yet.

 

 

Optimize the Rule Base matching.

Look for the first rule that matches:

  • Rule 1 – Possible match.
  • Rule 2 – No match.
  • Rule 3 – Match.

Possible match (Continue to inspect the connection).

 

HTTP Body

Examine the file.

Content: Executable file.

 

Optimize the Rule Base matching.

Look for the first rule that matches:

  • Rule 1 – Match.
  • Rule 2 – No match.
  • Rule 3 – Match.

Final match (accept on rule 1).

Shows in the log.

The matching examples show that:

Best Practices for Access Control Rules

  1. Make sure you have these rules:
    • Stealth rule that prevents direct access to the Security Gateway
    • Cleanup rule that drops all traffic that is not allowed by the earlier rules in the policy.
  2. Use Layers to add structure and hierarchy of rules in the Rule Base.
  3. Add all rules that are based only on source and destination IP addresses and ports, in a Firewall/Network Ordered Layer at the top of the Rule Base.
  4. Create Firewall/Network rules to explicitly accept safe traffic, and add an explicit cleanup rule at the bottom of the Ordered Layer to drop everything else.
  5. Create an Application Control Ordered Layer after the Firewall/Network Ordered Layer. Add rules to explicitly drop unwanted or unsafe traffic. Add an explicit cleanup rule at the bottom of the Ordered Layer to accept everything else.

    Alternatively, put Application Control rules in an Inline Layer as part of the Firewall/Network rules. In the parent rule of the Inline Layer, define the Source and Destination.

  6. For R80.10 Gateways and higher: If you have one Ordered Layer for Firewall/Network rules, and another Ordered Layer for Application Control - Add all rules that examine applications, Data Type, or Mobile Access elements, to the Application Control Ordered Layer, or to an Ordered Layer after it.
  7. Turn off XFF inspection, unless the gateway is behind a proxy server. For more, see: sk92839.
  8. Disable a rule when working on it. Enable the rule when you want to use it. Disabled rules do not affect the performance of the Gateway. To disable a rule, right click in the No. column of the rule and select Disable.

Best Practices for Efficient rule Matching

  1. Place rules that check the source, destination, and port (network rules) higher in the Rule Base.

    Reason: Network rules are matched sooner, and turn on fewer inspection engines.

  2. Place rules that check applications and content (Data Types) below network rules.
  3. Do not define a rule with Any in the Source and in the Destination, and with an Application or a Data Type. For example these rules are not recommended:

    Source

    Destination

    Services &
    Applications

    Content

    Any

    Any

    Facebook

     

    Any

    Any

     

    Credit Card numbers

    Instead, define one of these recommended rules:

    Source

    Destination

    Services &
    Applications

    Content

    Any

    Internet

    Facebook

     

    Any

    Server

     

    Credit Card numbers

    Reason for 2 and 3: Application Control and Content Awareness rules require content inspection. Therefore, they:

    • Allow the connection until the Firewall has inspected connection header and body.
    • May affect performance.
  4. For rules with Data Types: Place rules that check File Types higher in the Rule Base than rules that check for Content Types.

    Reason: File Types are matched sooner than Content Types.

To see examples of some of these best practices, see the Unified Rule Base Use Cases and Creating a Basic Access Control Policy.

Installing the Access Control Policy

  1. On the Global Toolbar, click Menu > Install Policy.

    The Install Policy window opens showing the Security Gateways.

  2. If there is more than one Policy package: From the Policy drop-down list, select a policy package.
  3. Select Access Control. You can also select other Policies.
  4. If there is more than one gateway: Select the gateways on which to install the Policy.
  5. Select the Install Mode:
    • Install on each selected gateway independently - Install the policy on each target gateway independently of others, so that if the installation fails on one of them, it doesn't affect the installation on the rest of the target gateways.

      Note - If you select For Gateway Clusters, if installation on a cluster member fails, do not install on that cluster, the Security Management Server makes sure that it can install the policy on all cluster members before it begins the installation. If the policy cannot be installed on one of the members, policy installation fails for all of them.

    • Install on all selected gateways, if it fails do not install on gateways of the same version - Install the policy on all the target gateways. If the policy fails to install on one of the gateways, the policy is not installed on other target gateways.
  6. Click Install.

Analyzing the Rule Base Hit Count

Use the Hit Count feature to show the number of connections that each rule matches. Use the Hit Count data to:

You can show Hit Count for the rules in these options:

These options are configured in the Access Control Policy Rule Base and also changes how Hit Count is shown in other supported Software Blades.

When you enable Hit Count, the Security Management Server collects the data from supported Security Gateways (from version R75.40 and up). Hit Count works independently from logging and tracks the hits even if the Track option is None.

Enabling or Disabling Hit Count

By default, Hit Count is globally enabled for all supported Security Gateways (from R75.40). The timeframe setting that defines the data collection time range is configured globally. If necessary, you can disable Hit Count for one or more Security Gateways.

After you enable or disable Hit Count you must install the Policy for the Security Gateway to start or stop collecting data.

To enable or disable Hit Count globally:

  1. In SmartConsole, click Menu > Global properties.
  2. Select Hit Count from the tree.
  3. Select the options:
    • Enable Hit Count - Select to enable or clear to disable all Security Gateways to monitor the number of connections each rule matches.
    • Keep Hit Count data up to - Select one of the time range options. The default is 3 months. Data is kept in the Security Management Server database for this period and is shown in the Hits column.
  4. Click OK.
  5. Install the Policy.

To enable or disable Hit Count on each Security Gateway:

  1. From the Gateway Properties for the Security Gateway, select Hit Count from the navigation tree.
  2. Select Enable Hit Count to enable the feature or clear it to disable Hit Count.
  3. Click OK.
  4. Install the Policy.

Configuring the Hit Count Display

These are the options you can configure for how matched connection data is shown in the Hits column:

To show the Hit Count in the Rule Base:

Right-click the heading row of the Rule Base and select Hits.

To configure the Hit Count in a rule:

  1. Right-click the rule number of the rule.
  2. Select Hit Count and one of these options (you can repeat this action to configure more options):
    • Timeframe - Select All, 1 day, 7 days, 1 month, or 3 months
    • Display. - Select Percentage, Value, or Level

To update the Hit Count in a rule:

  1. Right-click the rule number of the rule.
  2. Select Hit Count > Refresh.

Preventing IP Spoofing

IP spoofing replaces the untrusted source IP address with a fake, trusted one, to hijack connections to your network. Attackers use IP spoofing to send malware and bots to your protected network, to execute DoS attacks, or to gain unauthorized access.

Anti-Spoofing detects if a packet with an IP address that is behind a certain interface, arrives from a different interface. For example, if a packet from an external network has an internal IP address, Anti-Spoofing blocks that packet.

Example:

The diagram shows a Gateway with interfaces 2 and 3, and 4, and some example networks behind the interfaces.

For the Gateway, anti-spoofing makes sure that

If an incoming packet to B has a source IP address in network 192.168.33.0, the packet is blocked, because the source address is spoofed.

When you configure Anti-Spoofing protection on a Check Point Security Gateway interface, the Anti-Spoofing is done based on the interface topology. The interface topology defines where the interface Leads To (for example, External (Internet) or Internal), and the Security Zone of interface.

Configuring Anti-Spoofing

Make sure to configure Anti-Spoofing protection on all the interfaces of the Security Gateway, including internal interfaces.

To configure Anti-Spoofing for an interface:

  1. In SmartConsole, go to Gateways & Servers and double-click the Gateway object.

    The General Properties window of the Gateway opens.

  2. From the navigation tree, select Network Management.
  3. Click Get Interfaces.
  4. Click Accept.

    The gateway network topology shows. If SmartConsole fails to automatically retrieve the topology, make sure that the details in the General Properties section are correct and the Security Gateway, the Security Management Server, and the SmartConsole can communicate with each other.

  5. Select an interface and click Edit.

    The Interface properties window opens.

  6. From the navigation tree, select General.
  7. In the Topology section of the page, click Modify.

    The Topology Settings window opens.

  8. Select the type of network that the interface Leads To:
    • Internet (External) or This Network (Internal) - This is the default setting. It is automatically calculated from the topology of the gateway. To update the topology of an internal network after changes to static routes, click Network Management > Get Interfaces in the General Properties window of the gateway.
    • Override - Override the default setting.

    If you Override the default setting:

    • Internet (External) - All external/Internet addresses
    • This Network (Internal) -
      • Not Defined - All IP addresses behind this interface are considered a part of the internal network that connects to this interface
      • Network defined by the interface IP and Net Mask - Only the network that directly connects to this internal interface
      • Specific - A specific network object (a network, a host, an address range, or a network group) behind this internal interface
      • Interface leads to DMZ - The DMZ that directly connects to this internal interface
  9. Optional: In the Security Zone section, choose the zone of the interface.
  10. Configure Anti-Spoofing options. Make sure that Perform Anti-Spoofing based on interface topology is selected.
  11. Select an Anti-Spoofing action:
    • Prevent - Drops spoofed packets
    • Detect - Allows spoofed packets. To monitor traffic and to learn about the network topology without dropping packets, select this option together with the Spoof Tracking Log option.
  12. Configure Anti-Spoofing exceptions (optional). For example, configure addresses, from which packets are not inspected by Anti-Spoofing:
    1. Select Don't check packets from.
    2. Select an object from the drop-down list, or click New to create a new object.
  13. Configure Spoof Tracking - select the tracking action that is done when spoofed packets are detected:
    • Log - Create a log entry (default)
    • Alert - Show an alert
    • None - Do not log or alert
  14. Click OK twice to save Anti-Spoofing settings for the interface.

For each interface, repeat the configuration steps. When finished, install the policy.

Anti-Spoofing Options

Translating IP Addresses

NAT (Network Address Translation) is a feature of the Firewall Software Blade and replaces IPv4 and IPv6 addresses to add more security. You can enable NAT for all SmartConsole objects to help manage network traffic. NAT protects the identity of a network and does not show internal IP addresses to the Internet. You can also use NAT to supply more IPv4 addresses for the network.

The Firewall can change both the source and destination IP addresses in a packet. For example, when an internal computer sends a packet to an external computer, the Firewall translates the source IP address to a new one. The packet comes back from the external computer, the Firewall translates the new IP address back to the original IP address. The packet from the external computer goes to the correct internal computer.

SmartConsole gives you the flexibility to make necessary configurations for your network:

How Security Gateways Translate Traffic

A Security Gateway can use these procedures to translate IP addresses in your network:

To Learn More About NAT

To learn more about NAT, see the R80.10 Security Management Guide. Search for Configuring the NAT Policy.

UserCheck Interactions in the Access Control Policy

UserCheck objects lets the Security Gateway communicate with users. Use them in the Rule Base to:

If a UserCheck object is set as the action on in a policy rule, the user's browser redirects to the UserCheck web portal on port 443 or 80. The portal shows the notifications to the user.

UserCheck client adds the option to send notifications for applications that are not in a web browser. The UserCheck client can also work together with the UserCheck portal to show notifications on the computer itself when the notification cannot be displayed in a browser.

Configuring the Security Gateway for UserCheck

Enable or disable UserCheck directly on the Security Gateway. Make sure that the UserCheck is enabled on each Security Gateway in the network.

The Security Gateway has an internal persistence mechanism that preserves UserCheck notification data if the Security Gateway or cluster reboots. Records of a user answering or receiving notifications are never lost.

To configure UserCheck on a Security Gateway:

  1. In SmartConsole, click Gateways & Servers and double-click the Security Gateway.

    The Gateway Properties window opens.

  2. From the navigation tree, click UserCheck.

    The UserCheck page opens.

  3. Make sure Enable UserCheck for active blades is selected
  4. In the UserCheck Web Portal section:

    In the Main URL field, enter the primary URL for the web portal that shows the UserCheck notifications.

    If users connect to the Security Gateway remotely, make sure that the Security Gateway internal interface (in the Network Management page) is the same as the Main URL.

    Note - The Main URL field must be manually updated if:

    • The Main URL field contains an IP address and not a DNS name.
    • You change a gateway IPv4 address to IPv6 or vice versa.
  5. Optional: Click Aliases to add URL aliases that redirect different hostnames to the Main URL.

    The aliases must be resolved to the portal IP address on the corporate DNS server

  6. In the Certificate section, click Import to import a certificate that the portal uses to authenticate to the Security Management Server.

    By default, the portal uses a certificate from the Check Point Internal Certificate Authority (ICA). This might generate warnings if the user browser does not recognize Check Point as a trusted Certificate Authority. To prevent these warnings, import your own certificate from a recognized external authority.

  7. In the Accessibility section, click Edit to configure interfaces on the Security Gateway through which the portal can be accessed. These options are based on the topology configured for the Security Gateway. The topology must be configured.

    Users are sent to the UserCheck portal if they connect:

    • Through all interfaces
    • Through internal interfaces (default)
      • Including undefined internal interfaces
      • Including DMZ internal interfaces
      • Including VPN encrypted interfaces (default)

      Note: Make sure to add a rule to the Firewall Rule Base that allows the encrypted traffic.

    • According to the Firewall Policy. Select this option if there is a rule that states who can access the portal.

    If the Main URL is set to an external interface, you must set the Accessibility option to one of these:

    • Through all interfaces - necessary in VSX environment
    • According to the Firewall Policy
  8. In the Mail Server section, configure a mail server for UserCheck. This server sends notifications to users that the Gateway cannot notify using other means, if the server knows the email address of the user. For example, if a user sends an email which matched on a rule, the Gateway cannot redirect the user to the UserCheck portal because the traffic is not http. If the user does not have a UserCheck client, UserCheck sends an email notification to the user.
    • Use the default settings - Click the link to see which mail server is configured.
    • Use specific settings for this gateway - Select this option to override the default mail server settings.
    • Send emails using this mail server - Select a mail server from the list, or click New and define a new mail server.
  9. Click OK.
  10. If there is encrypted traffic through an internal interface, add a new rule to the Firewall Layer of the Access Control Policy. This is a sample rule:

    Source

    Destination

    VPN

    Services & Applications

    Action

    Any

    Security Gateway on which UserCheck client is enabled

    Any

    UserCheck

    Accept

  11. Install the Access Control Policy.

Blocking Applications and Informing Users

Scenario: I want to block pornographic sites in my organization, and tell the user about the violation. How can I do this?

To block an application or category of applications and tell the user about the policy violation:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Choose a Layer with Applications and URL Filtering enabled.
  3. Create a rule that includes these components:
    • Services & Applications - Select the Pornography category.
    • Action - Drop, and a UserCheck Blocked Message - Access Control

      The message informs users that their actions are against company policy and can include a link to report if the website is included in an incorrect category.

    • Track - Log

      Note - This Rule Base example contains only those columns that are applicable to this subject.

      Name

      Source

      Destination

      Services & Applications

      Action

      Track

      Install On

      Block Porn

      Any

      Internet

      Pornography (category)

      Drop
      Blocked Message

      Log

      Policy Targets

The rule blocks traffic to pornographic sites and logs attempts to access those sites. Users who violate the rule receive a UserCheck message that informs them that the application is blocked according to company security policy. The message can include a link to report if the website is included in an incorrect category.

Important - A rule that blocks traffic, with the Source and Destination parameters defined as Any, also blocks traffic to and from the Captive Portal.

UserCheck for Access Control Default Messages

These are the default UserCheck messages in the Access Tools > UserCheck page of the Access Control Policy:

Name

Action Type

Description

Access Approval

Inform

 

Access Notification

Inform

Shows when the action for the rule is inform. It informs users what the company policy is for that site.

Blocked Message - Access Control

Block

Shows when the action for the rule is Block, when a request is blocked.

Cancel Page - Access Control

Cancel

Shows after a user gets an Inform or Ask message and clicks Cancel.

Company Policy

Ask

Shows when the action for the rule is ask. It informs users what the company policy is for that site and they must click OK to continue to the site.

If the default UserCheck messages do not fit your needs, you can create a UserCheck Interaction object.

For example, you can create a message with Content Awareness fields.

You can show these UserCheck message previews:

Creating a UserCheck Interaction Object

If the default UserCheck messages do not fit your needs, you can create a UserCheck Interaction object.

To create a UserCheck object that includes a message:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Click Access Tools > UserCheck.
  3. Click New, and select one of these interaction modes:
    • Ask UserCheck- Show a message to users that asks them if they want to continue with the request or not.
    • Block UserCheck- Show a message to users and block the application request.
    • Inform UserCheck - Show an informative message to users. Users can continue to the application or cancel the request.

    The UserCheck Interaction window opens on the Message page.

  4. Enter a name for the UserCheck object and, optionally, a comment.
  5. Select a language (English is the default) from the Languages tabs.
  6. Enter the message content. You can:
    • Use the formatting toolbar to change text color, alignment, add or remove bullets.
    • Use the Insert field variables. These include fields for Content Awareness.
  7. In the Settings tab, configure optional settings. For example:
    • Fallback Action - For a Block action type, when UserCheck notification cannot be displayed, this action is taken.
    • External Portal - When selected, redirects the user to the specified External Portal (enter the URL), and the UserCheck message is not shown to the end-user
      Select Add UserCheck Incident ID to the URL query, to log the incident
  8. Click OK.

    This creates the UserCheck object and web page notification for the portal.

Example UserCheck Message Using Field Variables

If you define a custom UserCheck message, you can use predefined Field variables in the message.

Here is an example of a UserCheck message that you can define. This example uses some of the Insert Field variables for Application Control and Content Awareness rules:

According to the company policy, this action is intended for work-related use only.

Details:

- File Name is classified as Data Types

- Access to Application name

- Category Category

[ ] I will use this site/application and data in accordance with company policy.

Reference: Incident ID

Localizing and Customizing the UserCheck Portal

After you set the UserCheck interaction object language, you can translate the Portal OK and Cancel buttons to the applicable language. For more information, see sk83700.

Some of the UserCheck predefined notifications are translated to more than one language. For example, Access Notification is translated to English, French, Spanish, and Japanese.

To support more languages:

  1. In the Security Policies view of SmartConsole, go to the Access Control Policy.
  2. Click Access Tools > UserCheck.
  3. Double-click the UserCheck object to edit it.
  4. In the Message page, click Languages.
  5. Select the Languages from the list.

UserCheck Frequency and Scope

You can set the number of times that users get UserCheck messages for accessing applications that are not permitted by the policy. You can also set if the notifications are based on accessing the rule, application category, or application itself.

To set how often UserCheck notifications show:

  1. Select the Action cell of a rule in the Access Control Policy, and click More.
  2. In the Action Settings window, select the UserCheck Frequency.

    The options are:

    • Once a day
    • Once a week
    • Once a month
    • Custom frequency
  3. Select Confirm UserCheck. This sets if the notifications are:
    • Per rule
    • Per category
    • Per application
    • Per data type

Example:

In a rule that contains:

Services & Applications

Action

Social Networking category

Inform

If you select a UserCheck Frequency of Once a day, and Confirm UserCheck of Per rule:

A user who accesses Facebook and then LinkedIn on the same day gets one Inform message.

If you select a UserCheck Frequency of Once a day, and Confirm UserCheck of Per application:

A user who accesses Facebook and then LinkedIn on the same day gets one Inform message for Facebook and one for LinkedIn.

In new installations, the Confirm UserCheck Scope default is Per category.

In upgrades from a version before R75.40, the Confirm UserCheck default is Per Rule.

UserCheck Settings

For each UserCheck interaction object you can configure these options from the Settings page UserCheck object:

UserCheck CLI

You can use the usrchk command in the gateway command line to show or clear the history of UserCheck objects.

To use the usrchk commands, you must enable UserCheck on the gateway, and create a rule with a UserCheck interaction object.

Description

usrchk

Syntax

usrchk [debug] [hits]

Parameters

Parameter

Description

debug

Controls debug messages

hits

Shows user incident options:

list - Options to list user incidents

  • all - List all existing incidents.
  • user <username> - List incidents of a specified user.
  • uci <name of interaction object> - List incidents of a specified UserCheck interaction object

clear - Options to clear user incidents

  • all - Clear all existing incidents
  • user <username> - Clear incidents for a specified user
  • uci <name of interaction object> - Clear incidents of a specified UserCheck interaction object

db - user hits database options

Examples:

Notes:

Revoking Incidents

The Revoke Incidents URL can revoke a user's responses to UserCheck notifications. The URL is:

://<IP of gateway>/UserCheck/RevokePage

If users regret their responses to a notification and contact their administrator, the administrator can send users the URL.

After a user goes to the URL, all of the user's responses to notifications are revoked. The logs in the SmartConsole Logs & Monitor view Logs tab will show the user's activity, and that the actions were revoked afterwards.

Administrators can use the usrchk command of the CLI to revoke incidents for one user, all users, or a specified interaction object.

UserCheck Client

UserCheck Client Overview

The UserCheck client is installed on endpoint computers to communicate with the gateway and show UserCheck interaction notifications to users.

It works with the Data Loss Prevention and Content Awareness Software Blades.

Notifications of incidents can be sent by email (for SMTP traffic) or shown in a popup from the UserCheck client in the system tray (for SMTP, HTTP and FTP).

UserCheck client adds the option to send notifications for applications that are not in a web browser, such as Skype, iTunes, or browser add-ons (such as radio toolbars). The UserCheck client can also work together with the UserCheck portal to show notifications on the computer itself when:

Users select an option in the notification message to respond in real-time.

For Data Loss Prevention (DLP), administrators with full permissions or the View/Release/Discard DLP messages permission can also send or discard incidents from the SmartConsole Logs & Monitor > Logs view.

Workflow for installing and configuring UserCheck clients:

  1. Configure how the clients communicate with the gateway and create trust with it.
  2. Enable UserCheck and the UserCheck client on the gateway.
  3. Download the UserCheck client MSI file.
  4. Install the UserCheck client on the endpoint computers.
  5. Make sure that the UserCheck clients can connect to the gateway and receive notifications.

UserCheck Requirements

See UserCheck Client Requirements in the R80.10 Release Notes.

Enabling UserCheck Client

Enable UserCheck and the UserCheck client on the gateway in the Properties window of the gateway object in SmartConsole. This is necessary to let clients communicate with the gateway.

To enable UserCheck and the UserCheck client on the gateway:

  1. In SmartConsole, click Gateways & Servers and double-click the Security Gateway.

    The gateway window opens and shows the General Properties page.

  2. From the navigation tree, click UserCheck.
  3. Select Enable UserCheck for active blades.

    This enables UserCheck notifications from the gateway.

  4. In the UserCheck Client section, select Activate UserCheck Client support.

    This enables UserCheck notifications from the client.

  5. Click OK and Install Policy.

Client and Gateway Communication

In an environment with UserCheck clients, the gateway acts as a server for the clients. Each client must be able to discover the server and create trust with it.

To create trust, the client makes sure that the server is the correct one. It compares the server fingerprint calculated during the SSL handshake with the expected fingerprint. If the server does not have the expected fingerprint, the client asks the user to manually confirm that the server is correct.

Here is a summary of the methods that you can use for clients to discover and trust the server. More details are described later in this section.

Option Comparison

Requires AD

Manual User Trust (one time) Required?

Multi-
Site

Client Remains Signed?

Still works after Gateway Changes

Level

Recommended for...

File name based

No

Yes

No

Yes

No

Very Simple

Single Security Gateway deployments

AD based

Yes

No

Yes

Yes

Yes

Simple

Deployments with AD that you can modify

DNS based

No

Yes

Partially (per DNS server)

Yes

Yes

Simple

Deployments without AD

With an AD you cannot change, and a DNS that you can change

Remote registry

No

No

Yes

Yes

Yes

Moderate

Where remote registry is used for other purposes

File Name Based Server Discovery

This option is the easiest to deploy, and works out-of-the-box. It requires that users manually click Trust to trust the server the first time they connect. You can use this option if your deployment has only one Security Gateway with the relevant Software Blades.

How does it work?

When a user downloads the UserCheck client, the address of the Security Gateway is inserted in the filename. During installation, the client finds if there is a different discovery method configured (AD based, DNS based, or local registry). If no method is configured, and the gateway can be reached, it is used as the server. In the UserCheck Settings window, you can see that the server you connect to is the same as the Security Gateway in the UserCheck client filename.

Users must manually make sure that the trust data is valid, because the filename can be easily changed.

Renaming the MSI

You can manually change the name of the MSI file before it is installed on a computer. This connects the UserCheck client to a different gateway.

To rename the MSI file:

  1. Make sure the gateway has a DNS name.
  2. Rename the MSI using this syntax: UserCheck_~GWname.msi

    Where GWname - is the DNS name of the gateway.

    Optional: Use UserCheck_~GWname-port.msi

    Where port is the port number of notifications. For example, UserCheck_~mygw-18300.msi.

Notes - The prefix does not have to be "UserCheck". The important part of the syntax is underscore tilde (_~), which indicates that the next string is the DNS of the gateway.

If you want to add the port number for the notifications to the client from the gateway, the hyphen (-) indicates that the next string is the port number.

Active Directory Based Configuration

If your client computers are members of an Active Directory domain and you have administrative access to this domain, you can use the Distributed Configuration tool to configure connectivity and trust rules.

The Distributed Configuration tool has three windows:

To enable Active Directory based configuration for clients:

  1. Download and install the UserCheck client MSI on a computer.

    From the command line on that computer, run the client configuration tool with the AD utility.

    For example, on a Windows 7 computer:

    "C:\Users\<user name>\Local Settings\Application Data\Checkpoint\UserCheck\UserCheck.exe" -adtool

    The Check Point UserCheck - Distributed Configuration tool opens.

  2. In the Welcome page, enter the credentials of an AD administrator.

    By default, your AD username is shown. If you do not have administrator permissions, click Change user and enter administrator credentials.

  3. In the Server Configuration page, click Add.

    The Identity Server Configuration window opens.

  4. Select Default and then click Add.
  5. Enter the IP address or Fully Qualified Domain Name (FQDN) and the port of the Security Gateway.
  6. Click OK.

    The identity of the AD Server for the UserCheck client is written in the Active Directory and given to all clients.

Note - The entire configuration is written under a hive named Check Point under the Program Data branch in the AD database that is added in the first run of the tool. Adding this hive does not affect other AD based applications or features.

Server Configuration Rules

If you use the Distributed Configuration tool and you configure the client to Automatically discover the server, the client fetches the rule lists. Each time it must connect to a server, it tries to match itself against a rule, from top to bottom.

When the tool matches a rule, it uses the servers shown in the rule, according to the priority specified.

The configuration in this example means:

  1. If the user is coming from ‘192.168.0.1 – 192.168.0.255’, then try to connect to US-GW1. If it is not available, try BAK-GS2 (it is only used if US-GW1 is not available, as its priority is higher).
  2. If the user is connected from the Active Directory site ‘UK-SITE’, connect either to UK-GW1 or UK-GW2 (choose between them randomly, as they both have the same priority). If both of them are not available, connect to BAK-GS2.
  3. If rules 1 and 2 do not apply, connect to BAK-GS2 (the default rule is always matched when it is encountered).

Use the Add, Edit and Remove buttons to change the server connectivity rules.

Trusted Gateways

The Trusted Gateways window shows the list of servers that are trusted - no messages open when users connect to them.

You can add, edit or delete a server. If you have connectivity to the server, you can get the name and fingerprint. Enter its IP address and click Fetch Fingerprint in the Server Trust Configuration window. If you do not have connectivity to the server, enter the same name and fingerprint that is shown when you connect to that server.

DNS Based Configuration

If you configure the client to Automatic Discovery (the default), it looks for a server by issuing a DNS SRV query for the address of the gateway (the DNS suffix is added automatically). You can configure the address in your DNS server.

To configure DNS based configuration on the DNS server:

  1. Go to Start > All Programs > Administrative Tools > DNS.
  2. Go to Forward lookup zones and select the applicable domain.
  3. Go to the _tcp subdomain.
  4. Right click and select Other new record.
  5. Select Service Location, Create Record.
  6. In the Service field, enter CHECKPOINT_DLP.
  7. Set the Port number to 443.
  8. In Host offering this server, enter the IP address of the Security Gateway.
  9. Click OK.

To configure Load Sharing for the Security Gateway, create multiple SRV records with the same priority.

To configure High Availability, create multiple SRV records with different priorities.

Note - If you configure AD based and DNS based configuration, the results are combined according to the specified priority (from the lowest to highest).

Troubleshooting DNS Based Configuration

@@f [DH 8 Jan 2018] Changed code table

To troubleshoot issues in DNS based configuration, you can see the SRV records that are stored on the DNS server.

To see SRV records on the DNS server:

Run:

C:\> nslookup
> set type=srv
> checkpoint_dlp._tcp

The result is:

C:\> nslookup
> set type=srv
> checkpoint_dlp._tcp

Server: dns.company.com
Address: 192.168.0.17

checkpoint_dlp._tcp.ad.company.com SRV service location:
priority = 0
weight = 0
port = 443
svr hostname = dlpserver.company.com

dlpserver.company.com internet address = 192.168.1.212

> 

Remote Registry

If you have a way to deploy registry entries to your client computers, for example, Active Directory or GPO updates, you can deploy the Security Gateway addresses and trust parameters before you install the clients. Clients can then use the deployed settings immediately after installation.

To configure the remote registry option:

  1. Install the client on one of your computers. The agent installs itself in the user directory, and saves its configuration to HKEY_CURRENT_USER.
  2. Connect manually to all of the servers that are configured, verify their fingerprints, and click Trust on the fingerprint verification dialog box.
  3. Configure the client to manually connect to the requested servers (use the Settings window).
  4. Export these registry keys (from HKEY_CURRENT_USER):
    1. SOFTWARE\CheckPoint\UserCheck\TrustedGateways (the entire tree)
    2. SOFTWARE\CheckPoint\UserCheck\
      1. DefaultGateway
      2. DefaultGatewayEnabled
  5. Import the exported keys to the endpoint computers before you install the UserCheck client.

Getting the MSI File

To get the MSI file:

  1. In SmartConsole, in the Gateways & Servers view, open the General Properties window of the gateway object.
  2. From the navigation tree, select UserCheck.
  3. In the UserCheck Client section, click Download Client.

    Important - Before you can download the client msi file, the UserCheck portal must be up. The portal is up only after a Policy installation.

Distributing and Connecting Clients

After configuring the clients to connect to the gateway, install the clients on the user machines. You can use any method of MSI or EXE mass deployment and installation that you choose. For example, you can send users an email with a link to install the client. When a user clicks the link, the MSI file automatically installs the client on the computer.

Alternatively, users can download the installation package from the regular DLP UserCheck notifications.

To install the client for all user accounts on a Windows computer, see sk96107.

The installation is silent and generally, no reboot is required.

When the client is first installed, the tray icon indicates that it is not connected. When the client connects to the gateway, the tray icon shows that the client is active.

The first time that the client connects to the gateway, it asks for verification from the user and approval of the fingerprint.

Best Practices:

If UserCheck for DLP is enabled on the gateway, users are required to enter their username and password after the client installs.

Example of message to users about the UserCheck client installation (for DLP):

Dear Users,

Our company has implemented a Data Loss Prevention automation to protect our confidential data from unintentional leakage. Soon you will be asked to verify the connection between a small client that we will install on your computer and the computer that will send you notifications.

This client will pop up notifications if you try to send a message that contains protected data. It might let you to send the data anyway, if you are sure that it does not violate our data-security guidelines.

When the client is installed, you will see a window that asks if you trust the DLP server. Check that the server is SERVER NAME and then click Trust.

In the next window, enter your username and password, and then click OK.


Note - If the UserCheck client is not connected to the gateway, the behavior is as if the client was never installed. Email notifications are sent for SMTP incidents and the Portal is used for HTTP incidents.

UserCheck and Check Point Password Authentication

You can see and edit Check Point users from Users and Administrators in the navigation tree.

To enable Check Point password authentication:

SmartConsole Configuration

  1. Open SmartConsole and open the Manage & Settings view.
  2. Click Permissions & Administrators > Administrators, and select an existing user or create a new user.
  3. In the General Properties page of the user, make sure that an email address is defined.
  4. In the Authentication Properties page of the user, set Authentication Scheme to Check Point Password and enter the password and password confirmation.
  5. Click OK.

UserCheck Client Configuration

Ask your users to configure their UserCheck client:

  1. On the UserCheck client computer, right click the UserCheck icon in the Notification Area (next to the system clock).
  2. Select Settings.
  3. Click Advanced.
  4. Select Authentication with Check Point user accounts defined internally in SmartDashboard.

Helping Users

If users require assistance to troubleshoot issues with the UserCheck client, you can ask them to send you the logs.

To configure the client to generate logs:

  1. Right-click the UserCheck tray icon and select Settings.

    The Settings window opens.

  2. Click Log to and browse to a pathname where the logs are saved.
  3. Click OK.

To send UserCheck logs from the client:

  1. Right-click the UserCheck tray icon and select Status.

    The Status window opens.

  2. Click Advanced and then click the Collect information for technical support link.

    The default email client opens, with an archive of the collected logs attached.

Blade Settings

To configure Global Properties, Inspection Settings and Advanced Settings for Blades:

  1. In SmartConsole, go the Manage & Settings view.
  2. Click Blades.

Inspection Settings

You can configure inspection settings for the Firewall:

The Security Management Server comes with two preconfigured inspection profiles for the Firewall:

When you configure a Security Gateway, the Default Inspection profile is enabled for it. You can also assign the Recommended Inspection profile to the Security Gateway, or to create a custom profile and assign it to the Security Gateway.

To activate the Inspection Settings, install the Access Control Policy.

Note - In a pre-R80 SmartDashboard, Inspection Settings are configured as IPS Protections.

Configuring Inspection Settings

To configure Inspection Settings:

  1. In SmartConsole, go to the Manage & Settings > Blades view.
  2. In the General section, click Inspection Settings.

    The Inspection Settings window opens.

You can:

To edit a setting:

  1. In the Inspection Settings > General view, select a setting.
  2. Click Edit.
  3. In the window that opens, select a profile, and click Edit.

    The settings window opens.

  4. Select the Main Action:
    • Default Action - preconfigured action
    • Override with Action - from the drop-down menu, select an action with which to override the default - Accept, Drop, Inactive (the setting is not activated)
  5. Configure the Logging Settings

    Select Capture Packets, if you want to be able to examine packets that were blocked in Drop rules.

  6. Click OK.
  7. Click Close.

To view settings for a certain profile:

  1. In the Inspection Settings > General view, click View > Show Profiles.
  2. In the window that opens, select Specific Inspection settings profiles.
  3. Select profiles.
  4. Click OK.

    Only settings for the selected profiles are shown.

You can add, edit, clone, or delete custom Inspection Settings profiles.

To edit a custom Inspection Settings profile:

  1. In the Inspection Settings > Profiles view, select a profile.
  2. Click Delete, to remove it, or click Edit to change the profile name, associated color, or tag.
  3. If you edited the profile attributes, click OK to save the changes.

To clone an Inspection Settings profile:

  1. In the Inspection Settings > Profiles view, select the profile, and click Clone.
  2. In the New Profile window that opens, edit the profile attributes:
  3. Click OK.

To add a new Inspection Settings profile:

  1. In the Profiles view, click New.
  2. In the New Profile window that opens, edit the profile attributes:
  3. Click OK.

To assign an Inspection Settings profile to a Security Gateway:

  1. In the Inspection Settings > Gateways view, select a gateway, and click Edit.
  2. In the window that opens, select an Inspection Settings profile.
  3. Click OK.

To configure exceptions to inspection settings:

  1. In the Inspection Settings > Exceptions view, click New to add a new exception, or select an exception and click Edit to modify an existing one.

    The Exception Rule window opens.

  2. Configure the exception settings:
    • Apply To - select the Profile to which to apply the exception
    • Protection - select the setting
    • Source - select the source Network Object, or select IP Address and enter a source IP address
    • Destination - select the destination Service Object
    • Service - select Port/Range, TCP or UDP, and enter a destination port number or a range of port numbers
    • Install On - select a gateway on which to install the exception
  3. Click OK.

To enforce the changes, install the Access Control Policy.