What can I do here?
Use this window to define the Access Policy.
Getting Here - Security Policies > Access Control |
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:
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:
Best Practice - These are basic Access Control rules we recommend for all Rule Bases:
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.
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 |
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 |
Accept |
Log |
Policy Targets |
7 |
SMTP |
NOT Internal |
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. |
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 |
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 |
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 Policy Layer. Rule 3.X is a cleanup rule. It drops 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 Policy Layer. |
4 4.1 |
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 Policy 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 Policy Layer. |
You must configure rules to allow traffic to and from VPN Communities. Configure rules in SmartConsole > Security Policies > Access Control. All layers of the Access Control Policy can contain VPN rules.
To make a rule apply to a VPN Community, the VPN column of the Rule Base must contain one of these:
Examples:
Name |
Source |
Destination |
VPN |
Services & Applications |
---|---|---|---|---|
Allow traffic within community |
* Any |
*Any |
MyCommunity |
* Any |
Name |
Source |
Destination |
VPN |
Services & Applications |
---|---|---|---|---|
Allow all VPN |
* Any |
Internal_Network |
* Any |
* Any |
Name |
Source |
Destination |
VPN |
Services & Applications |
---|---|---|---|---|
Site to Site VPN |
Local_VPN_Domain Peer_VPN_Domain |
Local_VPN_Domain Peer_VPN_Domain |
Site2Site |
* Any |
You must configure rules to allow users in the Remote Access VPN Community to access the LAN. You can limit the access to specified services or specified clients. Configure rules in SmartConsole > Security Policies > Access Control.
To make a rule apply to a VPN Community, the VPN column of the Rule Base must contain one of these:
Examples:
Name |
Source |
Destination |
VPN |
Services & Applications |
---|---|---|---|---|
Allow all remote access |
* Any |
Internal_Network |
* Any |
* Any |
Name |
Source |
Destination |
VPN |
Services & Applications |
---|---|---|---|---|
Allow RemoteAccess community |
* Any |
Internal_Network |
RemoteAccess |
HTTP |
Name |
Source |
Destination |
VPN |
Services & Applications |
---|---|---|---|---|
Allow all from Endpoint Security VPN |
Endpoint Security VPN Access Role |
Internal_Network |
RemoteAccess |
* Any |
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.
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.
Scenario: I want to monitor all Facebook traffic in my organization. How can I do this?
To monitor all Facebook application traffic:
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
.
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).
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:
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 |
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. |
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:
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.
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 |
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.
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:
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:
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.10 <idaware> Administration Guide.
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:
To create a custom group:
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.
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 Changing Services for Applications and Categories.
Name |
Source |
Destination |
Services & Applications |
Action |
Track |
---|---|---|---|---|---|
Block sites that may cause a liability |
Identified_Users |
Internet |
Liability_Sites |
Drop |
Log |
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:
Note - Categories 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 Changing Services for Applications and Categories.
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.
In This Section |
Policy Layers and Inline Layers helps you manage your cyber security more efficiently. You can:
An Inline Layer is a sub-policy which is independent of the rest of the Rule Base.
The Policy 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 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:
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.
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 Action of the matching rule is Drop, the gateway stops matching against later rules in the Policy Rule Base and drops the packet. If the Action is Accept, the gateway continues to check rules in the next Policy Layer.
Item |
Description |
|
---|---|---|
1 |
Policy Layer 1 |
|
2 |
Policy Layer 2 |
|
3 |
Policy Layer 3 |
|
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 Action is the same as the Action of the Implicit Cleanup Rule.
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:
To create an Inline Layer:
The name of the Inline Layer shows in the Action cell of the rule.
To create an Policy Layer:
You will see a list of the Layers. You can select Show only shared Layers.
This Policy Layer is not yet assigned to a Policy Package.
To add an Policy Layer to the Access Control Policy:
The Policy window opens.
You will see a list of the Layers that you can add. These are Layers that have Multiple policies can use this layer enabled.
Pre-R80.10 Gateways: To create a Layer for URL Filtering and Application Control:
The Policy window opens.
The Layer Editor window opens and shows the General view.
We recommend the name Application.
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:
The General Properties window of the gateway opens.
To enable the Access Control features on an Policy Layer:
The Layer Editor window opens and shows the General view.
To enable the Access Control features on an Inline Layer:
Note - Do not enable a Blade that is not enabled in the Policy Layer.
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 Policy Layer:
Note - If you change the default values, the policy installation will fail on R77.30 or earlier versions Security Gateways.
Note - If you use the Cleanup rule as the last explicit rule, the Last Implied Rule and the Implicit Cleanup Rule are not enforced.
Some of the implied rules are enabled by default. You can change the default configuration as necessary.
To configure the implied rules:
The Implied Policy window opens.
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.
To configure the Implicit Cleanup Rule:
The Layer Editor opens.
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.
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:
To mark a Layer as shared:
To reuse a Threat Prevention Policy Layer:
For examples of Inline Layers and Policy Layer, see Unified Rule Base Use Cases.
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.
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:
The Manage Layers window opens.
To work with Policy 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:
After you configure rules for Mobile Access in the Unified Access Control Policy, configure the gateway to use the Unified Access Policy.
To make an R80.x Mobile Access gateway use the Unified Access Control Policy:
See the R80.10 Next Generation Security Gateway Guide for more about layers.
Application objects defined for Application Control, for example, are not supported in Mobile Access rules.
You must enable Identity Awareness on each gateway that is an installation target for rules with Access Roles.
Create Mobile Access rules in the Access Control Policy with these requirements:
Column |
Value |
Explanation |
---|---|---|
No. |
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. |
Name |
All |
We recommend that you use a descriptive name. |
Source |
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. |
Destination |
The internal server on which the Mobile Access application is set. |
Mobile Access Applications are defined in the Services & Applications column. |
VPN |
Any 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 RemoteAccess 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 Any. |
Services & Applications |
Mobile Applications Do not include applications or service objects that are not specified as Mobile Access. |
To create a Mobile Application: Click > click > Mobile Applications > select an application type and define it. To select an existing Mobile Application: Click > *All > Mobile Applications and select one. Mobile Applications only show in the list if Mobile Access is enabled on the Layer |
Content |
Any |
Content Awareness is not relevant for Mobile Access rules. |
Action |
Accept or Drop |
Only Accept and Drop are supported. Reject is also supported but acts the same as Drop. You can also select Inline Layer to send all traffic that matches the rule to an Inline Layer under it. |
Track |
All log options |
Right-click in the cell and select More > Extended log |
Install On |
One or more gateways |
Each gateway must have Mobile Access and Identity Awareness enabled and have Unified Access Policy selected as the Policy Source. |
To use a Mobile Access application in the Unified Access Control Policy, you must define it as a Mobile Application from the SmartConsole or define it in the in SmartConsole > Mobile Access 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:
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 |
|
Name |
Name that the system administrator gives this rule. |
Source |
Network objects that define
|
VPN |
|
Services & Applications |
Services, Applications, Categories, and Sites. |
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 |
|
Time |
Time period that this rule is enforced. |
Comment |
An optional field that lets you summarize the rule. |
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:
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.
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.
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 Site to Site VPN and Remote Access VPN, see these guides:
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:
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 Policy Layer.
You can configure TCP and UDP services to be matched by source port.
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.
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:
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:
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 |
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:
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:
The Application viewer window opens.
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.
To create a custom category:
The Application viewer window opens.
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:
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.
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:
|
||||
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 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:
UserCheck on a computer
The UserCheck client is installed on endpoint computers. This client:
These are some of the Tracking options:
Here are some use cases that show examples of rules that you can define for the Access Control Policy.
Use Cases In this section: |
This use case shows an example unified Access Control Policy. It controls applications and content in one Policy 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 executable 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. |
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 & |
Content |
Action |
Track |
---|---|---|---|---|---|---|---|
1 |
Headquarter WEB traffic - via proxy |
HQ |
Proxy |
Web Proxy |
Any |
Ask Web Access Policy |
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 |
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 |
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... |
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 |
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 |
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 Policy 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 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.
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... |
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 |
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 |
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 |
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 |
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- |
4 |
Allow Facebook for HR |
HR(Access Role) |
Internet |
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 |
4 |
Allow Facebook for HR - Allows computers in the |
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 |
6 |
Log all applications- Logs all traffic that matches any of the URL Filtering and Application Control categories. |
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:
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.
For this Rule Base:
No. |
Source |
Destination |
Services & |
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:
|
Final match (drop on rule 1). Shows in the log. The Firewall does not turn on the inspection engines for the other rules. |
For this Rule Base:
No. |
Source |
Destination |
Services & |
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:
|
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:
|
Application: File sharing (category). Content: Don’t know yet.
|
|
Optimize the Rule Base matching. Look for the first rule that matches:
|
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:
|
Final match (accept on rule 4). Shows in the log. |
For this Rule Base:
No. |
Source |
Destination |
Services & |
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:
|
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:
|
Application: Business (Category). Content: Don’t know yet.
|
|
Optimize the Rule Base matching. Look for the first rule that matches:
|
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:
|
Final match (accept on rule 1). Shows in the log. |
Recommendation |
Reason |
Place rules that check the source, destination, and port (network rules) higher in the Rule Base. |
Network rules:
|
Place rules that check applications and content (Data Types) below network rules.
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: Any | Destination: Any | Application: Facebook Or Source: Any | Destination: Any | Content: Credit Card numbers Instead, define these recommended rules: Source: Any | Destination: Internet | Application: Facebook Or Source: Any | Destination: Server | Content: Credit Card numbers |
Application Control and Content Awareness rules require content inspection. Therefore, they:
|
For rules that check content (Data Types): Place rules that check File Types higher in the Rule Base than rules that check for Content Types. |
File Types are matched sooner than Content Types. |
Be sure to follow the other Best Practices for the Access Control Policies Rule Base.
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.
Best Practices for Efficient rule Matching
Reason: Network rules are matched sooner, and turn on fewer inspection engines.
Source |
Destination |
Services & |
Content |
---|---|---|---|
Any |
Any |
|
|
Any |
Any |
|
Credit Card numbers |
Instead, define one of these recommended rules:
Source |
Destination |
Services & |
Content |
---|---|---|---|
Any |
Internet |
|
|
Any |
Server |
|
Credit Card numbers |
Reason for 2 and 3: Application Control and Content Awareness rules require content inspection. Therefore, they:
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.
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:
Important – After upgrade, do not change the Action 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:
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 Drop all the traffic that does not match any rule in that Policy Layer. We recommend that the Action is set to Drop for the Network Policy Layer and Accept for the Application Control Policy Layer.
If you remove the default rule, the Implicit Cleanup Rule will be enforced. The Implicit Cleanup Rule is configured in the Policy configuration window and is not visible in the Rule Base table. Make sure the Implicit Cleanup Rule is configured to Drop the unmatched traffic for the Network Policy Layer and to Accept the unmatched traffic for the Application Control Policy Layer.
Use the Hit Count feature to show the number of connections that each rule matches. Use the Hit Count data to:
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.
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.
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:
To enable or disable Hit Count on each Security Gateway:
These are the options you can configure for how matched connection data is shown in the Hits column:
The values are shown with these letter abbreviations:
For example, 259K represents 259 thousand connections and 2M represents 2 million connections.
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 Hits.
To configure the Hit Count in a rule:
To update the Hit Count in a rule: