What basic criteria can be used to define security policy rules to allow or reject traffic?

What can I do here?

Use this window to define the Access Policy.

Getting Here - Security Policies > Access Control

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:

• Firewall - Control access to and from the internal network.
• Application and URL Filtering - Block applications and sites.
• Content Awareness - Restrict the Data Types that users can upload or download.
• IPsec VPN and Mobile Access - Configure secure communication with Site-to-Site and Remote Access VPNs.
• Identity Awareness - Identify users, computers, and networks.

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:

• Security Zones
• Services
• Applications and URLs
• Data Types
• Access Roles

Information about these features is collected in one log:

• Network
• Protocol
• Application
• User
• Accessed resources
• Data Types

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:

• Allows only authorized connections and prevents vulnerabilities in a network.
• Gives authorized users access to the correct internal resources.
• Efficiently inspects connections.

Basic Rules

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

• Stealth rule that prevents direct access to the Security Gateway
• Cleanup rule that drops all traffic that is not matched by the earlier rules in the policy

Note - If you delete the cleanup rule, there will still be an 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 , and columns are not shown.)

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.

Configuring Site to Site VPN Rules in the Access Policy

You must configure rules to allow traffic to and from VPN Communities. Configure rules in SmartConsole > > . All layers of the Access Control Policy can contain VPN rules.

To make a rule apply to a VPN Community, the column of the Rule Base must contain one of these:

• - The rules applies to all VPN Communities and to non-VPN related traffic. If you configure a new VPN Community after the rule was created, the rule also applies to the new VPN Community.
• - For example, Right-click in the VPN column of a rule and select . The rule applies to the communities shown in the VPN column.

Examples:

• This rule allows encrypted traffic between domains of member gateways of "community_X."

  Name	Source	Destination	VPN	Services & Applications

• This rule allows traffic from all VPN Communities to the internal network on all services.

  Name	Source	Destination	VPN	Services & Applications

• This rule allows traffic between two VPN domains with all services.

  Name	Source	Destination	VPN	Services & Applications

Examples of VPN Access Rules for Remote Access

Examples:

This rule allows traffic from all VPN Communities to the internal network on all services:

This rule allows traffic from RemoteAccess VPN Community to the internal network on HTTP and HTTPS.

Name	Source	Destination	VPN	Services & Applications
Allow RemoteAccess community

This rule allows traffic from RemoteAccess VPN Community to the internal network on all services when the traffic starts from the Endpoint Security VPN client.

Name	Source	Destination	VPN	Services & Applications
Allow all from Endpoint Security VPN

See Access Roles for Remote Access for details of how to create Access Roles for Remote Access and VPN Clients to include them in rules in the Access Control Rule Base.

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 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 in the part of the 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 view in > > .

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 Policy.
2. Choose a Layer with enabled.
3. Click one of the 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:
   • - Give the rule a name, such as .
   • - Keep it as so that it applies to all traffic from the organization.
   • - Keep it as so that it applies to all traffic going to the internet or DMZ.
   • - Click the plus sign to open the Applicationviewer. Add the application to the rule:
     • Start to type "face" in the Search field. In the Available list, see the 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 are http, https, HTTP_proxy, and HTTPS_proxy.

   • - Select
   • - Select
   • - Keep it as 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 view, in the tab. To monitor how people use Facebook in your organization, see the 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 Policy.
2. Choose a Layer with enabled.
3. Create a rule that includes these components:
   • - Select the category.
   • - , and a UserCheck

     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.

   • -

     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 blockstraffic, with the and parameters defined as , 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:

• Add a object to a rule to limit the bandwidth that is permitted for the rule.
• Add one or more objects to a rule to make it active only during specified times.

The example rule below:

• Allows access to streaming media during non-peak business hours only.
• Limits the upload throughput for streaming media in the company to 1 Gbps.

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

1. In the Security Policies view of SmartConsole, go to the Policy.
2. Choose a Layer with enabled.
3. Click one of the toolbar buttons to add the rule in the position that you choose in the Rule Base.
4. Create a rule that includes these components:
   • - category.

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

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

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

     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 ClusterXL Load Sharing modes, the specified bandwidth limit is divided between all defined cluster members, regardless of the cluster state. For example, if a rule sets 1Gbps limit in a cluster with three members, 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:

• You have already created an Access Role that represents all identified users in the organization. You can use this to allow access to applications only for users who are identified on the Security Gateway.
• You want to allow access to the Radmin Remote Access tool for all identified users.
• You want to block all other Remote Access tools for everyone within your organization. You also want to block any other application that can establish remote connections or remote control.

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

1. Create a rule and include these components:
   • - The access role
   • -
   • -
2. Create another rule below and include these components:
   • -
   • -
   • - The category:
   • -

     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:

• Because the rule that allows Radmin is above the rule that blocks other Remote Administration tools, it is matched first.
• The Source of the first rule is the access role. If you use an access role that represents the Technical Support department, then only users from the technical support department are allowed to use Radmin.
• Applications are matched on their Recommended services, where each service runs on a specific port, such as the default Application Control : http, https, HTTP_proxy, and HTTPS_proxy. To change this see Changing Services for Applications and Categories.

For more about Access Roles and Identity Awareness, see the R80.20 Identity Awareness Administration Guide.

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 and URL Filtering 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:

• You have already created
  • An Access Role that represents all identified users in the organization (Identified_Users).
  • A custom application for a site named FreeMovies.
• You want to block sites that can cause liability issues for everyone within your organization.
• You will create a custom group that includes Application and URL Filtering Database categories as well as the previously defined custom site named FreeMovies.

To create a custom group:

1. In the Object Explorer, click .
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 , and add the ones you want to block (for example Anonymizer, Critical Risk, and Gambling)
   • Click
4. Click .

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 Policy.

• - TheIdentified_Users access role
• -
• - Liability_Sites
• -

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

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:

• You have already created an Access Role (Identified_Users) that represents all identified users in the organization.
• You want to block sites related to pornography.

The procedure is similar to Blocking Applications and Informing Users.

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

• - The Identified_Users access role
• -
• - category
• - Drop

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

Policy 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 Policy Layers and Inline Layers.

The Need for Policy Layers and Inline Layers

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

• Simplify the Rule Base, or organize parts of it for specific purposes.
• Organize the Policy into a hierarchy, using Inline Layers, rather than having a flat Rule Base.

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

• Reuse Policy Layers in multiple Policy packages, and reuse Inline Layers in multiple Layers.
• Simplify the management of the Policy by delegating ownership of different Layers to different administrators.
• Improve performance by reducing the number of rules in a Layer.

Order of Rule Enforcement in Inline Layers

The Policy Layer can contain Inline Layers.

This is an example of an Inline Layer:

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 Policy Layer (Rule 3).

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

• If the packet matches a sub rule in the Inline Layer (Rule 2.1), no more rule matching is done.
• If none of the higher rules in the Policy Layer match the packet, the explicit Cleanup Rule is applied (Rule 2.2). If this rule is missing, the Implicit Cleanup Rule is applied. No more rule matching is done.

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

Order of Rule Enforcement in Policy Layers

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

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

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

Every Policy 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 Policy Layer, and make sure that its is the same as the 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 Policy Layer. This is the parent rule.
2. In the , , , and cells, define the match conditions for the Inline Layer.
3. Click the cell of the rule. Instead of selecting a standard action, select > .
4. The window opens.
5. Configure the properties of the Inline Layer:
   1. Enable one or more of these for the rules of Inline Layer:
   2. Optional: It is a best practice to share Layers with other Policy packages when possible. To enable this select
   3. Click .
   4. Configure the to Drop or Accept.
   5. Click .

   The name of the Inline Layer shows in the 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 Policy Layer

To create an Policy Layer:

1. In SmartConsole, click > .
2. In the left pane, click .

   You will see a list of the Layers. You can select .

3. Click the icon in the upper toolbar.
4. Configure the settings in the window.
5. Optional: It is a best practice to share Layers with other Policy packages when possible. To enable this select
6. Click .
7. Click .
8. the session.

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

To add an Policy Layer to the Access Control Policy:

1. In SmartConsole, click .
2. Right-click a Layer in the Policy section and select .

   The window opens.

3. In the section, click the plus sign.

   You will see a list of the Layers that you can add. These are Layers that have enabled.

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

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

1. In SmartConsole, click .
2. Right-click a Layer in the Policy section and select .

   The window opens.

3. In the section, click the plus sign.
4. Click .

   The window opens and shows the view.

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

      We recommend the name .

   2. In the section, select .
   3. Click and the window closes.
   4. Click and the window closes.
6. 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:

• Security Gateways on which you will install the Policy.
• Policy Layers and Inline Layers of the Policy. Here you can enable:
  • Firewall. This includes VPN.
  • Applications & URL Filtering
  • Content Awareness
  • Mobile Access

Enabling Access Control Features on a Gateway

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

   The window of the gateway opens.

2. From the navigation tree, click .
3. In the tab, select one or more of these Access Control features:
4. Click .

Enabling Access Control Features on a Layer

To enable the Access Control features on an Policy Layer:

1. In SmartConsole, click .
2. Under , right-click and select .
3. Click options
   
   for the Layer.
4. Click .

   The window opens and shows the view.

5. Enable the that you will use in the Policy Layer:
6. Click .

To enable the Access Control features on an Inline Layer:

1. In SmartConsole, click .
2. Select the Policy Layer.
3. In the parent rule of the Inline Layer, right-click the column, and select >
4. Enable the that you will use in the Inline Layer:

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

5. Click .

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 configuration and cannot be edited. You can only select the implied rules and configure their position in the Rule Base:

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

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

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

Implicit cleanup rule

The default "catch-all" rule 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 Policy Layer:

• Drop - for the Layer
• Accept - for a Layer with enabled

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 Ruleare 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 > .

   The window opens.

3. In the left pane, click .
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: , , or .
6. Click and install the policy.

Showing the Implied Rules

To see the implied rules:

In , from the View, select > .

The 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 > .
2. In the left pane, click .
3. Select a Layer and click .

   The opens.

4. Click
5. Configure the to Drop or Accept.
6. Click .
7. Click .
8. 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.

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 the Inline Layer or Ordered layer in multiple policy packages or use the Inline Layer in multiple places in an Ordered Layer. This is useful, for example, if you are an administrator of a corporation and want to share some of the rules among multiple branches of the corporation:

• It saves time and prevents mistakes.
• To change a shared rule in all of the corporation's branches, you must only make the change once.

To mark a Layer as shared:

1. In SmartConsole, click > .
2. In the left pane, click .
3. Select a Layer in or in .
4. Right-click and select .
5. Configure the settings in the window.
6. In , select
7. Click .
8. Click .
9. the session.

To reuse a Threat Prevention Policy Layer:

1. In SmartConsole, go to > > .
2. Right-click the required policy and click . The policy properties window opens.
3. In the Threat Prevention box, click the sign.
4. Select the layer you want to include in this policy package.
5. Click .
6. Close the policy properties window.
7. .
8. Repeat this procedure for all policy packages.

For examples of Inline Layers and Policy Layer, see Unified Rule Base Use Cases.

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

   The window opens.

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

Managing Policies and Layers

To work with Policy Layers and Inline Layers in the Access Control Policy, select > in SmartConsole.

The window shows.

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

In the pane of the window, you can see:

• - Layer name
• - Number of rules in the Layer
• - The administrator who last changed the Layer configuration.
• Date the Layer was changed.
• - A shared Layer has the option selected.
• • - Policy packages that use the Layer
  • :
    • - An Policy Layer. In a Multi-Domain Security Management environment, it includes global rules and a placeholder for local, Domain rules.
    • - An Inline Layer, also known as a Sub-Policy.
    • - A Layer that is not used in a Policy package.

To see the rules in the Layer:

1. Select a Layer.
2. Right-click and select .

Including Mobile Access in the Unified Policy

After you configure rules for Mobile Access in the Unified Access Control Policy, configure the gateway to use the .

To make an R80.x Mobile Access gateway use the Unified Access Control Policy:

1. In SmartConsole, Gateways & Servers, open a Mobile Access gateway object.
2. From the tree, select .
3. In the area, select .
4. Install policy.

Configuring Mobile Access in the Unified Policy

• You can include Mobile Access rules in Policy Layers and Inline Layers. You must enable Mobile Access on each Layer that contains rule with Mobile Access applications.

  See the R80.20 Security Management Administration Guide for more about layers.

• To make a Mobile Access application show in the Mobile Access portal or in Capsule Workspace, you must put the application in the column.
  • If you put in the column, the application does not show in the portal but it is allowed. You can open it from the Mobile Access portal if you manually enter the URL, but not from Capsule Workspace. You can change this behavior. See sk112576 for details.
  • If you put an application's service, such as HTTPS, in the column, it does not match Mobile Access https applications.
• In the column, you must use Mobile Access Application objects in rules to match Mobile Access traffic. You can define these applications in:
  • In SmartConsole: >
  • In SmartConsole > tab > define an application

  Application objects defined for Application Control, for example, are not supported in Mobile Access rules.

• When you enable Mobile Access on a gateway, the gateway is automatically added to the VPN Community. Include that Community in the column of the rule or use to make the rule apply to Mobile Access gateways. If the gateway was removed from the VPN Community, the column must contain .
• Use Access Roles as the or for a rule to make the rule apply to specified users or networks. You can also use an Access Role to represent Mobile Access or other remote access clients.

  You must enable Identity Awareness on each gateway that is an installation target for rules with Access Roles.

Creating Mobile Access Rules in the Unified Access Control Policy

Create Mobile Access rules in the Access Control Policy with these requirements:

Column	Value	Explanation
	Make sure that the rule position is logical.	The order of rules in the Rule Base is important. The first rule that matches the traffic is enforced.
	All	We recommend that you use a descriptive name.
	Access Role	Create an Access Role that includes the Users, User Groups, or Mobile/Remote Access Client that the rule applies to. See Access Roles for Remote Access.
	The internal server on which the Mobile Access application is set.	Mobile Access Applications are defined in the column.
	or a Remote Access Community that includes the Mobile Access gateway	When you enable the Mobile Access or IPsec Software Blade on a gateway, the gateway is automatically added to the default VPN Community. By default the community also contains a user group that contains all users. If you remove the gateway from the VPN Community, you must select .
	Mobile Applications Do not include applications or service objects that are not specified as Mobile Access.	To create a Mobile Application: Click > click > > select an application type and define it. To select an existing Mobile Application: Click > > and select one. Mobile Applications only show in the list if Mobile Access is enabled on the Layer
Content		Content Awareness is not relevant for Mobile Access rules.
	or	Only and are supported. is also supported but acts the same as . You can also select Inline Layer to send all traffic that matches the rule to an Inline Layer under it.
	All log options	Right-click in the cell and select >
	One or more gateways	Each gateway must have Mobile Access and Identity Awareness enabled and have selected as the .

Mobile Access Applications in the Unified Access Control policy

To use a Mobile Access application in the Unified Access Control Policy, you must define it as a from the SmartConsole or define it in the in SmartConsole > tab.

Other application objects, such as URL Filtering applications, are not relevant for Mobile Access. For example: To authorize Facebook as a web application in Mobile Access, you must create a new Web Application and specify Facebook’s URL. You cannot use the URL Filtering Facebook application, because it is not for Mobile Access.

To create a Mobile Application object to use in the Access Control Policy:

1. In SmartConsole, expand the pane.
2. Select > > >.
3. Select a type of Mobile Application.
4. Define theand .
5. Optional: Define more settings for the Application.
6. Click .

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.

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:

• Network
• Host
• Zones
• Dynamic Objects
• Domain Objects
• Access Roles
• Updatable Objects

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 to make the rule apply to all VPN Communities.

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

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:

• Authenticity - Uses standard authentication methods
• Privacy - All VPN data is encrypted
• Integrity - Uses industry-standard integrity assurance methods

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 in the column.

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

To Learn More About VPN

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

• R80.20 Site-to-Site VPN Administration Guide
• R80.20Remote Access VPN Administration Guide
• R80.20 Mobile Access Administration Guide

Services & Applications Column

In the 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:

• Services
• Applications
• Mobile Applications for Mobile Access
• Web sites
• Default categories of Internet traffic
• Custom groups or categories that you create, that are not included in the Check Point Application and URL Filtering Database.

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 on the Gateway and on the Policy 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 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 : 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:

• On any service
• On a specified service

To do this, change theof 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 column, double-click an application or category.
2. Select .
3. Select an option:
   • The default is services. The defaults for Web services are the Application Control .
   • To match the application with all services, click .
   • To match the application on specified services, click , and add or remove services.
   • To match the application with all services and exclude specified services, click , add the services to exclude, and select .
4. Click .

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 , 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 > > > >
2. Configure :
   • 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

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 Policy.
2. To add applications to a rule, select a Layer with enabled.
3. Right-click the cell for the rule and select .
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, which are not included in the Check Point Application and URL Filtering Database.

To create a new application or site:

1. In the Security Policies view of SmartConsole, go to the Policy.
2. Select a Layer with enabled.
3. Right-click the cell for the rule and select .

   The Application viewer window opens.

4. Click > .
5. Enter a name for the object.
6. Enter one or more URLs.

   If you used a regular expression in the URL, click .

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

7. Click .

To create a custom category:

1. In the Security Policies view of SmartConsole, go to the Policy.
2. Select a Layer with enabled.
3. Right-click the cell for the rule and select .

   The Application viewer window opens.

4. Click > .
5. Enter a name for the object.
6. Enter a description for the object.
7. Click .

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

For R77.xx and lower Gateways:

• The Firewall matches TCP and UDP services by port number. The Firewall cannot match services by protocol signature.
• The Firewall matches applications by the application signature.

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

• Applications that were defined in the Application and URL Filtering Rule Base are accepted on their recommended ports

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 ,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  (into the organization), (out of the organization), or .

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:

• PCI - credit card numbers
• HIPAA - Medical Records Number - MRN
• International Bank Account Numbers - IBAN
• Source Code - JAVA
• U.S. Social Security Numbers - According to SSA
• Salary Survey Terms

File type examples:

• Viewer File - PDF
• Executable file
• Database file
• Document file
• Presentation file
• Spreadsheet file

Note these limitations:

• Websocket content is not inspected.
• HTTP connections that are not RFC-compliant are not inspected.

To learn more about the Data Types, open the Data Type object in SmartConsole and press the button (or ) 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.20 Data Loss Prevention Administration Guide.

Actions

Action	Meaning
	Accepts the traffic
	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.
	Asks the user a question and adds a confirmatory check box, or a reason box. Uses a UserCheck object.
	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 :
	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.
	Select the action that triggers a UserCheck message: - UserCheck message shows only once when traffic matches a rule. - UserCheck message shows for each matching category in a rule. - UserCheck message shows for each matching application/site in a rule. - UserCheck message shows for each matching data type.
	Limits the bandwidth that is permitted for a rule. Add a Limit object to configure a maximum throughput for uploads and downloads.
	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 dropstraffic, with the and parameters defined as , 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 SmartConsole). 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:

• Access Control features:
  • Application Control
  • URL Filtering
  • Content Awareness
• Threat Prevention features:
  • Anti-Virus
  • Anti-Bot
  • Threat Emulation
  • Threat Extraction
• Data Loss Prevention

UserCheck on a computer

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

• Sends messages for applications that are not based on Internet browsers, such as Skype and iTunes, and Internet browser add-ons and plug-ins.
• Shows a message on the computer when it cannot be shown in the Internet browser.

Tracking Column

These are some of the options:

• - Do not generate a log.
• This is the default option. It shows all the information that the Security Gateway used to match the connection.
• - Select this to update the log at 10 minute intervals, to show how much data has passed in the connection: Upload bytes, Download bytes, and browse time.

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 Case - Application Control and Content Awareness Policy Layer

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

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.

Use Case - Content Awareness Policy 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.

Use Case - Application and URL Filtering Policy 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 and columns are not shown.)

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:

• Get better performance from the Rule Base.
• Understand the logs that show a matched connection.

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:

This is the matching procedure for an FTP connection:

Rule Base Matching - Example 2

For this Rule Base:

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:

Rule Base Matching - Example 3

For this Rule Base:

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:

The matching examples show that:

• The Firewall sometimes runs the Rule Base more than one time. Each time it runs, the Firewall optimizes the matching, to find the first rule that applies to the connection.
• If the rule includes an application, or a site, or a service with a protocol signature (in the column), or a Data Type (in the column), the Firewall:
  • Turns on one or more inspection engines.
  • Postpones making the final match decision until it has inspected the body of the connection.
• The Firewall searches for the first rule that applies to (matches) a connection. If the Firewall does not have all the information it needs to identify the matching rule, it continues to inspect the traffic.

Best Practices for Efficient Rule Matching

Be sure to follow the other Best Practices for the Access Control Policies Rule Base.

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 Policy 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 Policy Layer to drop everything else.
5. Create an Application Control Policy Layer after the Firewall/Network Policy Layer. Add rules to explicitly drop unwanted or unsafe traffic. Add an explicit cleanup rule at the bottom of the Policy 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. Share Ordered Layers and Inline Layers when possible.
7. For R80.10 Gateways and higher: If you have one Policy Layer for Firewall/Network rules, and another Policy Layer for Application Control - Add all rules that examine applications, Data Type, or Mobile Access elements, to the Application Control Policy Layer, or to an Policy Layer after it.
8. Turn off XFF inspection, unless the gateway is behind a proxy server. For more, see: sk92839.
9. 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 column of the rule and select .

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.

Managing Pre-R80.10 Security Gateways

When you upgrade a pre-R80 Security Management Server that manages pre-R80.10 Security Gateways to R80 or higher, the existing Access Control policies are converted in this way:

• The pre-R80 policy is converted into the Policy Layer of the R80 Access Control Policy. The implicit cleanup rule for it is set to all traffic that is not matched by any rule in this Layer.
• The pre-R80 policy is converted into the Policy Layer, which is the second Layer of the R80 Access Control Policy. The implicit cleanup rule for it is set to all traffic that is not matched by any rule in this Layer.

Important – After upgrade, do not change the of the implicit cleanup rules, or the order of the Policy Layers. If you do, the policy installation will fail.

New Access Control Policy for pre-R80 Security Gateways on an R80 Security Management Server must have this structure:

1. The first Policy Layer is the Network Layer (with the blade enabled on it).
2. The second Policy Layer is the Application and URL Filtering Layer (with the blade enabled on it).
3. There are no other Policy Layers.

If the Access Control Policy has a different structure, the policy will fail to install.

You can change the names of the Layers, for example, to make them more descriptive.

Each new Policy Layer will have the explicit default rule, added automatically and set to all the traffic that does not match any rule in that Policy Layer. We recommend that the is set to for the Network Policy Layer and for the Application Control Policy Layer.

If you remove the default rule, the will be enforced. The is configured in the Policy configuration window and is not visible in the Rule Base table. Make sure the is configured to the unmatched traffic for the Network Policy Layer and to the unmatched traffic for the Application Control Policy Layer.

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:

• Analyze a Rule Base - You can delete rules that have no matching connections

  Note - If you see a rule with a zero hit count it only means that in the Security Gateways enabled with Hit Count there were no matching connections. There can be matching connections on other Security Gateways.

• Better understand the behavior of the Access Control Policy

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

• The percentage of the rule hits from total hits
• The indicator level (very high, high, medium, low, or zero)

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 option is .

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 > .
2. Select from the tree.
3. Select the options:
   • - Select to enable or clear to disable all Security Gateways to monitor the number of connections each rule matches.
   • - 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 .
5. Install the Policy.

To enable or disable Hit Count on each Security Gateway:

1. From the for the Security Gateway, select from the navigation tree.
2. Select to enable the feature or clear it to disable Hit Count.
3. Click .
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 column:

• - Shows the number of matched hits for the rule from supported Security Gateways. Connection hits are not accumulated in the total hit count for:
  • Security Gateways that are not supported
  • Security Gateways that have disabled the hit count feature

  The values are shown with these letter abbreviations:

  • K = 1,000
  • M = 1,000,000
  • G = 1,000,000,000
  • T = 1,000,000,000,000

  For example, 259K represents 259 thousand connections and 2M represents 2 million connections.

• Shows the percentage of the number of matched hits for the rule from the total number of matched connections. The percentage is rounded to a tenth of a percent.
• The hit count level is a label for the range of hits according to the table.

  The hit count range = Maximum hit value - Minimum hit value (does not include zero hits)

  Hit Count Level	Icon	Range
  Zero		0 hits
  Low		Less than 10 percent of the hit count range
  Medium		Between 10 - 70 percent of the hit count range
  High		Between 70 - 90 percent of the hit count range
  Very High		Above 90 percent of the hit count range

To show the Hit Count in the Rule Base:

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

To configure the Hit Count in a rule:

1. Right-click the rule number of the rule.
2. Select and one of these options (you can repeat this action to configure more options):
   • - Select , , , , or
   • - Select , , or

To update the Hit Count in a rule:

1. Right-click the rule number of the rule.
2. Select .

What types of criteria can you use to define security policy rules on the Palo Alto firewall?

Which of the following parameters are used in a firewall security policy to match traffic?

Which two items describe configuration conditions that enable the firewall to generate traffic log entries?

Which policy describes the security controls that apply to network and firewalls?