In This Section: |
You configure Application Control and URL Filtering in SmartDashboard. SmartView Tracker shows the logs and SmartEvent shows real-time traffic statistics and analysis. This chapter explains the Application Control and URL Filtering configuration and management that you do in SmartDashboard.
The Application Control and URL Filtering Policy determines who can access which applications and sites from an organization. The primary component of the Policy is the Rule Base. The rules use the Application and URL Filtering Database, network objects and custom objects (if defined).
If you enable Identity Awareness on your Security Gateways, you can also use Access Role objects as the source in a rule. This lets you easily make rules for individuals or different groups of users. You cannot use a regular network object and an access role together in one field. For example, you can have the source of Rule 4 as an Access Role and the Destination as an Address Range. You cannot have an Access Role and an Address Range together in the Source field.
There are no implied rules in the Rule Base. Application and site traffic is allowed unless it is explicitly blocked.
Important - Dynamic Objects are not supported in the Application and URL Filtering Rule Base. |
For examples of how to create different types of rules, see Creating Application Control Rules.
When you enable Application Control, a default rule is added to the Rule Base that allows all traffic from known applications and sites, with the tracking set to Log.
Source |
Destination |
Applications/Sites |
Action |
Track |
Install On |
---|---|---|---|---|---|
Any |
Internet |
Any Recognized |
Allow |
Log |
All |
The result of this rule is that all application traffic is monitored. Therefore, you can see logs related to application traffic in SmartView Tracker and SmartEvent. Use the data there to better understand the use of applications in your environment and create an effective Rule Base.
If you enabled Identity Awareness on the Security Gateway, you will also see names of identified users in the logs.
If you do not add other rules to the Rule Base, your Application Control Policy stays in monitor mode. This means that you see application traffic in the logs, but do not block access to applications.
If you change the default rule, for example:
Then no traffic will be monitored.
You can add more rules that block specified applications or sites or have different tracking settings. If you do not change the default rule, traffic that is not included in other rules is allowed and monitored.
The columns of a rule define the traffic that it matches and what is done to that traffic:
The sequence of rules is important because the first rule that matches an application is applied.
For example, Gmail additional categories include Sends Mail, Transmits Personal or Enterprise Information, and Instant Chat. If rule 3 allows Gmail and rule 4 blocks applications with the Instant Chat additional category, Gmail will be allowed based on rule 3.
Hit Count tracks the number of connections that each rule matches. For each rule in the Rule Base, the Hits column shows by default a visual indicator of matching connections together with the number of hits in K (thousands), M (millions), G (billions), or T (trillions). You can configure to show the percentage of the rule's hits from total hits, the indicator level (very high, high, medium, low, or zero) and set a timeframe for the data that is shown. These options are configured from the Firewall Rule Base by right-clicking the Hits column header or the rule number.
See Hit Count.
Give the rule a descriptive name. The name can include spaces.
Double-click in the Name column of the rule to add or change a name.
The source is where the traffic originates. The default is Any.
Important - A rule that blocks traffic, with the Source and Destination parameters defined as Any, also blocks traffic to and from the Captive Portal. |
Put your mouse in the column and a plus sign shows. Click the plus sign to open the list of network objects and select one or multiple sources. The source can be an Access Role object, which you can define when Identity Awareness is enabled.
Choose the destination for the traffic. The default is the Internet, which includes all traffic with the destination of DMZ or external. If you delete the destination value, the rule changes to Any, which applies to traffic going to all destinations
Important - A rule that blocks traffic, with the Source and Destination parameters defined as Any, also blocks traffic to and from the Captive Portal. |
To choose other destinations, put your mouse in the column and a plus sign shows. Click the plus sign to open the list of network objects and select one or multiple destinations.
The Applications/Sites column contains the applications and categories for sites and applications that you choose to include. One rule can include multiple items and items of different types. For example, one rule can include 2 applications and 3 categories. The default is that the rule applies to all known applications and sites. The category on which the rule is matched is shown in the SmartView Tracker logs in the Matched Category field.
You can also include widgets and custom defined applications, sites, categories and groups. Custom defined items are set in SmartDashboard by the administrator and are not a part of the Application and URL Filtering Database.
If you do not enable URL Filtering on the Security Gateway, you can use a generic web browser application called Web Browsing.
This application includes all HTTP traffic that is not a defined application. Because Web Browsing traffic can generate many logs, the Web browsing application has its own activation setting. You can activate Web Browsing in Advanced > Engine Settings.
To add applications or categories to a rule:
Move the cursor to the Application/Sites column. Click the plus sign to open the Application viewer. For each application or widget, the viewer shows a short description and its related categories. For each category, the viewer shows a description and if there are applications or sites related with it.
Action refers to what is done to the traffic. Click in the column to see the options and select an action to add to the rule.
Action |
Meaning |
|||
---|---|---|---|---|
Allow |
Allows the traffic |
|||
Inform |
Sends a message to the user attempting to access the application |
|||
Ask |
Asks the user a question and adds a confirmatory check box, or a reason box. |
|||
Block |
Blocks the traffic. If no UserCheck object is defined for this action, no page is displayed. |
|||
Limit |
Limits the bandwidth that is permitted for a rule. Add a Limit object to configure a maximum throughput for uploads and downloads. |
|||
User Check 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:
|
|||
Edit User Check Message |
Opens the User Check message for editing |
|||
Captive Portal |
Redirects HTTP traffic to an authentication (captive) portal. Once the authentication credentials are obtained, further connections from this source are inspected without requiring authentication. |
|||
Rule Actions |
From the toolbar at the top of the Application Control Policy page, click the icons to create new rules or to delete the selected rules. If you right-click in a column of the Rule Base and select Rule Actions, a menu opens with these options:
|
|||
Important - A rule that blocks traffic, with the Source and Destination parameters defined as Any, also blocks traffic to and from the Captive Portal. |
||||
Note - The actions Block, Ask, and Inform involve the creation of UserCheck Interaction Objects] edi. |
Choose if the traffic is logged in SmartView Tracker or if it triggers other notifications. Click in the column and the options open. The options include:
For more about logs, see log sessions.
Choose which Security Gateways on which the rule will be installed. The default is All, which means all Security Gateways that have Application Control enabled. Put your mouse in the column and a plus sign shows. Click the plus sign to open the list of available Security Gateways and select.
You can add a Time object to a rule to make the rule active only during specified times. If you do not include a Time object in a rule, the rule is always active.
You can include one or more Time objects and Time Groups in a rule. A Time Group contains Time objects.
When you have multiple Time objects or a Time Group, each Time object works independently. For example, if a rule has two Time objects:
The rule is active each day from 9:00 - 17:00 and all day on Mondays. For the rule to be active from 9:00 - 17:00 on Mondays only, make one Time object that contains all of the criteria.
If Time objects were created from a different tab in SmartDashboard, you can also use them in the Application Control and URL Filtering Rule Base. For example, you can create Time objects from the Firewall Rule Base or from Manage menu > Time.
To add Time objects to a rule:
To create a new Time object from the Application Control and URL Filtering Rule Base:
Note - The relevant time zone is that of the Security Gateway enforcing the rule. If Security Gateways are in different time zones, they enforce the same time object rules at different times. |
Use the Limit action in rules to limit the bandwidth that is permitted for a rule in the Application Control and URL Filtering Rule Base. Configure a maximum throughput for uploads and downloads. The Limit action makes sure that employee use of the internet does not impede important business tasks.
You can add one Limit object to a rule. It can include upload and download rates.
When the limit is reached, the gateway begins to drop packets. The Application Control logs show dropped packets.
To add a Limit object to a rule:
The Limit is added to the rule.
Note - The Security Gateway implements the Limit action by dropping successive packets which exceed the allowed bandwidth. |
Use the Hit Count feature to track the number of connections that each rule matches. You can show Hit Count for the rules in these options:
These options are configured in the Firewall 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.
You can 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. |
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 configure the Hit Count display:
The values shown in the Hits column are based on the Timeframe setting. By default, the timeframe is cumulative according to the Keep Hit Count data up to parameter in the Global Settings. For example, if the parameter is configured to 6 months, the available timeframe options are 1 month, 3 months, and 6 months.
You can change the timeframe according to intervals based on the Global Settings parameter.
To configure the hit count timeframe:
Hit count data is transferred from the Security Gateways to the Security Management Server at three hour intervals for each rule. When you refresh the hit count data, you get updated data from the Security Management Server database and not directly from the Security Gateways.
After you install a Policy, the hit count is updated from each Security Gateway in the Policy to the Security Management Server database. This is done at one minute intervals for the first 3 minutes after the Policy is installed.
To refresh hit count data in the Firewall Rule Base:
To refresh hit count data in the Application and URL Filtering Rule Base:
Click the refresh hits button in the Policy toolbar.
UserCheck Interaction Objects add flexibility and give the Security Gateway a mechanism to communicate with users. UserCheck objects are used in a Rule Base to:
If a UserCheck object is set as the action on a policy rule, the user browser redirects to the Administration web portal on port 443 or 80. The portal hosts UserCheck notifications.
UserCheck client adds the option to send notifications for applications that are not in a web browser, such as Skype, iTunes, or browser add-ons (such as radio toolbars). The UserCheck client can also work together with the UserCheck portal to show notifications on the computer itself when:
For more about configuring UserCheck on the gateway and the UserCheck client, see Configuring UserCheck.
Create a UserCheck Interaction object from the Rule Base or from the UserCheck page of the Application and URL Filtering tab. The procedure below shows how to create the object from the Rule Base.
To create a UserCheck object that includes a message:
If you selected New UserCheck, the UserCheck Interaction window opens on the Message page.
Note - The graphic must have a height and width of 176 x 52 pixels.
Note - Right-click inside one of the text boxes to change modes and enter HTML code directly. The HTML mode closes the formatting toolbar.
Variables are replaced with applicable values when the (Block, Ask, Inform) action occurs and the message shows. The Username can only be displayed if the Identity Awareness blade is enabled.
This creates the UserCheck object and web page notification for the portal.
After you set the UserCheck interaction object language, you can translate the Portal OK and Cancel buttons to the applicable language. For more information, see: sk83700.
The UserCheck predefined notifications are translated to English, French, Spanish, and Japanese.
To support more languages:
You can set the number of times that users get UserCheck messages for accessing applications that are not permitted by the policy. You can also set if the notifications are based on accessing the rule, application category, or application itself.
To set how often UserCheck notifications show:
Example:
In a rule that contains:
Applications/Sites |
Action |
---|---|
Social Networking category |
Inform |
If you select Once a day, as the UserCheck Frequency and For this rule for UserCheck Scope:
A user who accesses Facebook and then LinkedIn on the same day gets one Inform message.
If you select Once a day, as the UserCheck Frequency and For each application for UserCheck Scope:
A user who accesses Facebook and then LinkedIn on the same day gets one Inform message for Facebook and one for LinkedIn.
In new installations, the UserCheck Scope default is For each category.
In upgrades from a version before R75.40, the UserCheck Scope default is For this Rule.
For each UserCheck Interaction object you can configure these options from the UserCheck Interaction window:
Then the notification displays in Japanese.
The URL template field points to an XML file. This file should be placed on the external portal so that it can be sent back to the Security Gateway when called. The pre-shared secret authenticates the external portal to the Security Gateway.
On the UserCheck page, you can create, edit, and preview UserCheck interaction objects and their messages.
Item |
Meaning |
---|---|
New |
Creates a new UserCheck object |
Edit |
Modifies an existing UserCheck object |
Delete |
Deletes an UserCheck object |
Clone |
Clones the selected UserCheck object. |
These are the default UserCheck messages:
Name |
Action Type |
Description |
---|---|---|
Cancel Page |
Cancel |
Shows after a user gets an Inform or Ask message and clicks Cancel. |
Blocked Message |
Block |
Shows when a request is blocked. |
Access Notification |
Inform |
Shows when the action for the rule is inform. It informs users what the company policy is for that site. |
Company Policy |
Ask |
Shows when the action for the rule is ask. It informs users what the company policy is for that site and they must click OK to continue to the site. |
Ask and Inform pages include a Cancel button that users can click to cancel the request.
For Threat Prevention and Application and URL Filtering, you can show these UserCheck message previews:
For DLP, you can also show these UserCheck message previews:
The Check Point Application and URL Filtering Database contains more than 4,500 applications and about 96 million categorized URLs.
For URL Filtering, each Security Gateway also has:
Upon rule match in the Rule Base, it is necessary to determine if the URL is an application and its related category. To do this the Security Gateway does these steps:
Each item has a description, a category, additional categories, and a risk level. You can include applications and categories in your Application Control and URL Filtering rules. When you have a valid Application Control and/or URL Filtering contract, the database is updated regularly with new applications, categories and social networking widgets. This lets you easily create and maintain an up to date Policy.
Access the Application and URL Filtering Database from:
The local cache on each Security Gateway keeps URL categorization data for up to 3 days. During that time, it is possible that the initial categorization of a security category is updated on the Check Point Online Web Service. For example, a URL categorized as portal, is updated to phishing after 24 hours.
Changes made to URLs with security categories (such as phishing, malware, botnet, and spam) are updated in a security service list by the Check Point Online Web Service.
The local cache is updated on a regular basis depending on the category involved. For security related categories, such as phishing, there is a special update Policy that allows fast updates to occur.
In the Application and URL Filtering Database, each application is assigned to one primary category based on its most defining aspect. See the category in the description of each application and in the logs.
In the Application and URL Filtering Database, each application can have additional categories, which are characteristics of the application. For example, some of the additional categories of Gmail include: Supports File Transfer, Sends mail, and Instant Chat. If an additional category is in a rule, the rule matches all applications that are marked with it.
Note - In the AppWiki, additional categories are called tags. |
When you use the AppWiki or add applications to the Rule Base, you can filter by additional category or risk level to see all applications with that characteristic. This is a good way to get ideas of types of applications that you might want to block or allow.
If new applications are added to an additional category that is in an Application Control, URL Filtering, or Threat Prevention rule, the rule is updated automatically when the database is updated.
The Application and URL Filtering Database and AppWiki show a Risk Level for each application.
This table explains what each level means and gives examples of applications or types of applications with that level.
Risk Level |
Definition |
Examples |
---|---|---|
5 - Critical |
Can bypass security or hide identities |
Tor, VTunnel |
4 - High |
Can cause data leakage or malware infection without user knowledge |
Remote Desktop, File Sharing, P2P (uTorrent, Kazaa) |
3 - Medium |
Can be misused and cause data leakage or malware infection |
Instant messaging, File Storage (Drop box), WebEx, Gmail |
2- Low |
Potentially not business related, but low risk |
Gaming, Facebook, YouTube, Media |
1- Very Low |
Usually business related with no or very low risk |
SalesForce, Google Finance |
You can filter a search based on the risk level. For example, select risk level 5 to see all applications with that risk level. The risk level is also a tag that shows in the details of each application. This helps you to understand which types of applications to be wary of and which are low risk.
The AppWiki is an easy to use tool that lets you search and filter the Application and URL Filtering Database to find out information.
Access the AppWiki from the Application and URL Filtering tab or from the Check Point website.
The Application and URL Filtering Database automatically updates regularly to make sure that you have the most current data and newly added applications and websites in your Application Control and URL Filtering Policy. The Application and URL Filtering Database only updates if you have a valid Application Control and/or URL Filtering contract. By default, all new Application Control installations have a valid contract for 30 days.
By default, updates run on the Security Management Server and Security Gateways every two hours. You can change the update schedule or choose to manually update the management server. The updates are stored in a few files on each Security Gateway.
To manually update the management server only:
On the Advanced > Updates pane of the Application and URL Filtering tab, click Update Management to update the management only.
To change the schedule for updates on the management server and Security Gateways:
When you update the database on the Security Management Server, you can see relevant database changes in SmartDashboard. If you only update the Security Gateways, you will see in SmartDashboard that the Security Gateway has a new version of the Application and URL Filtering Database.
In Multi-Domain Security Management, update the database for all Domain Management Servers in the Global SmartDashboard and not from Domain Management Servers.
The gateway and Security Management Server connect to the Internet to get the Application and URL Filtering Database updates. To make sure that they can get the updates successfully:
To configure a proxy:
To Configure IPv6 proxy support:
If the proxy uses an IPv6 address:
updates_over_IPv6=1
.To change the update schedule from the default scheduled Application and URL Filtering Database updates:
The Scheduled Event Properties window opens.
If you have Security Gateways in different time zones, they will not be synchronized when one updates and the other did not update yet.
In the Application and URL Filtering Overview pane, you can quickly see the status of computers and incidents. Use the windows for the most urgent or commonly-used management actions.
Shows a graphical summary of the most popular applications in Top Applications, the most popular categories in Top Categories and the most popular sites in Top Sites.
Shows a graphical summary of the most popular users who use applications the most.
The Security Gateway connects to the internet to get the most current AppWiki.
The Gateways pane lists the gateways with Application Control and/or URL Filtering enabled. Select a gateway and click Edit to edit the gateway properties.
For each gateway, you see the gateway name and IP address. You also see these columns:
In the Application and URL Filtering Database Updates section, you can also see the status of the Application and URL Filtering Database on the Security Management Server. A message shows if the Management server is up to date or if a new update is available. Click Updates to go to the Updates pane.
The Applications/Sites pane shows custom applications, sites, categories and groups that you defined. Select an object in the list and click Edit to change its properties. You can use the toolbar buttons to create, look for, delete and import objects.
You can import a customized application binary file that Check Point creates for applications not in the Application and URL Filtering Database. This file contains a database of internal applications that are not necessarily web-based.
For each object in the list, you see the name and type and also:
You can create a custom application or site to use in the Rule Base. You can enter the URLs manually or use a .csv (comma separated values) file to add many URLs at one time from an external source.
The .csv file syntax is one URL for each line in the text file. When you use the .csv file option, the URLs are imported when you click Finish. If it is necessary to edit the URLs, click the Applications/Site object in the list and click Edit.
To create an application or site:
The Application/Site wizard opens.
Note - Select the URLs are defined as Regular Expression checkbox only if the application or site URL is entered as a regular expression using the correct syntax.
Note - You can click New in the list to create a new category.
You can use this custom application or site in the Policy.
This feature is supported in R77.30, with the R77.30 Add-on, and higher.
R77.30 extends support for SCADA protocol based applications, for deep inspection of Modbus traffic. You can define the application rule for Any Modbus traffic, for applications that match granular function sets or units, and for custom Modbus applications.
To enable Modbus configuration:
modbus_applications_enabled
to true
.To create a Modbus application rule:
The Modbus Application window opens.
We recommend that you do not change the Primary Category from SCADA Protocols, unless you are sure you want a custom category for this application.
You can monitor matched traffic in SmartLog. In the Log Details window, see the Modbus section.
You can create a custom category to use in the Rule Base if there is no corresponding category.
Note - If category data in the Application and URL Filtering Database for a URL is not applicable for your organization, you can override the categorization. |
To create a new category:
The Category Properties window opens.
You can use this custom category object in the Policy.
You can create a group of applications or sites to use in the Rule Base. The group members can include categories, applications and widgets from the Application and URL Filtering Database and also custom applications, sites and categories.
To create an application or site group:
The Applications/Sites group window opens.
The Application viewer opens.
The selected items are shown in the Group members list.
You can use this group in the Policy.
You can import Check Point custom applications for Application Control from the Applications/Sites pane. These are signatures that Check Point creates for organizations that have network applications not in the Application and URL Filtering Database (for example, proprietary applications). After importing the file, you can include them in your Rule Base. The custom applications have an .apps suffix.
To import an application or site file:
The Import Applications/Sites window opens.
The Custom Application object is added to the Applications/Sites list.
This section describes settings that you can configure in the Application and URL Filtering tab, in the Advanced section of the navigation tree. These settings apply globally for all Security Gateways with Application Control and URL Filtering.
Applications that use HTTP normally send the HTTP traffic on TCP port 80. Some applications send HTTP traffic on other ports also. You can configure some Software Blades to only inspect HTTP traffic on port 80, or to also inspect HTTP traffic on non-standard ports.
When selected, the Application and URL Filtering policy inspects all HTTP traffic, even if it is sent using non-standard ports. This option is selected by default. You can configure this option in the Advanced section of the Application and URL Filtering tab.
You can also configure IPS to inspect HTTP traffic on non-standard ports.
In some cases, the category data in the Application and URL Filtering Database for a URL is not applicable for your organization. You can use the override categorization option to update the category and risk definitions of a URL.
This definition overrides the information in the Application and URL Filtering Database and the responses received from the Check Point Online Web Service. The Rule Base will use the newly specified categorization when matching rules with URLs.
You can use the toolbar buttons to create, edit, search, and delete a categorization entry.
To override categorization for a URL:
The Override Categorization for URL window opens.
http:\\.
The selected categories are shown in the Additional Categories list.
The URL with its newly defined categories is shown in the list in the Override Categorization pane.
You can enable HTTPS traffic inspection on Security Gateways to inspect traffic that is encrypted by the Secure Sockets Layer (SSL) protocol. SSL secures communication between internet browser clients and web servers. It supplies data privacy and integrity by encrypting the traffic, based on standard encryption ciphers.
However, SSL has a potential security gap. It can hide illegal user activity and malicious traffic from the content inspection of Security Gateways. One example of a threat is when an employee uses HTTPS (SSL based) to connect from the corporate network to internet web servers. Security Gateways without HTTPS Inspection are unaware of the content passed through the SSL encrypted tunnel. This makes the company vulnerable to security attacks and sensitive data leakage.
The SSL protocol is widely implemented in public resources that include: banking, web mail, user forums, and corporate web resources.
There are two types of HTTPS inspection:
The Security Gateway acts as an intermediary between the client computer and the secure web site. The Security Gateway behaves as the client with the server and as the server with the client using certificates.
To optimize performance, inbound HTTPS traffic is inspected only if the policy has rules for HTTPS. For example, if the IPS profile does not have HTTP/HTTPS-related protections activated, HTTPS Inspection is not started.
All data is kept private in HTTPS Inspection logs. This is controlled by administrator permissions. Only administrators with HTTPS Inspection permissions can see all the fields in a log. Without these permissions, some data is hidden.
In outbound HTTPS inspection, when a client in the organization initiates an HTTPS connection to a secure site, the Security Gateway:
In inbound HTTPS inspection, when a client outside of the organization initiates an HTTPS connection to a server behind the organization's gateway, the Security Gateway:
To enable outbound HTTPS traffic inspection, you must do these steps:
When required, you can update the trusted CA list in the Security Gateway.
You must enable HTTPS inspection on each Security Gateway. From Security Gateway > HTTPS Inspection > Step 3, select Enable HTTPS Inspection.
The first time you enable HTTPS inspection on one of the Security Gateways, you must create an outbound CA certificate for HTTPS inspection or import a CA certificate already deployed in your organization. This outbound certificate is used by all Security Gateways managed on the Security Management Server.
The outbound CA certificate is saved with a P12 file extension and uses a password to encrypt the private key of the file. The Security Gateways use this password to sign certificates for the sites accessed. You must keep the password as it also used by other Security Management Servers that import the CA certificate to decrypt the file.
After you create an outbound CA certificate, you must export it so it can be distributed to clients. If you do not deploy the generated outbound CA certificate on clients, users will receive SSL error messages in their browsers when connecting to HTTPS sites. You can configure a troubleshooting option that logs such connections.
After you create the outbound CA certificate, a certificate object named Outbound Certificate is created. Use this in rules that inspect outbound HTTPS traffic in the HTTPS inspection Rule Base.
To create an outbound CA certificate:
The Gateway Properties window opens.
If you use more than one Security Management Server in your organization, you must first export the CA certificate with the export_https_cert
CLI command from the Security Management Server on which it was created before you can import it to other Security Management Servers.
Command syntax:
export_https_cert [-local] | [-s server] [-f certificate file name under FWDIR/tmp][-help]
To export the CA certificate:
On the Security Management Server, run this command:
$FWDIR/bin/export_https_cert -local -f [certificate file name under FWDIR/tmp]
Example
$FWDIR/bin/export_https_cert -local -f mycompany.p12
To prevent users from getting warnings about the generated CA certificates that HTTPS inspection uses, install the generated CA certificate used by HTTPS inspection as a trusted CA. You can distribute the CA with different distribution mechanisms such as Windows GPO. This adds the generated CA to the trusted root certificates repository on client computers.
When users do standard updates, the generated CA will be in the CA list and they will not receive browser certificate warnings.
To distribute a certificate with a GPO:
Or
From the HTTPS Inspection > Gateways pane in a supported blade, click Export.
Note - Make sure that the CA certificate is pushed to the client computer organizational unit.
You can use this procedure to deploy a certificate to multiple client machines with Active Directory Domain Services and a Group Policy Object (GPO). A GPO can contain multiple configuration options, and is applied to all computers in the scope of the GPO.
Membership in the local Administrators group, or equivalent, is necessary to complete this procedure.
To deploy a certificate using Group Policy:
The Group Policy Management Editor opens and shows the contents of the policy object.
You can import a CA certificate that is already deployed in your organization or import a CA certificate created on one Security Management Server to use on another Security Management Server.
Note - It is recommended that you use private CA Certificates. |
For each Security Management Server that has Security Gateways enabled with HTTPS inspection, you must:
To import a CA certificate:
Or
From the HTTPS Inspection > Gateways pane of a supported blade, click the arrow next to Create Certificate and select Import certificate from file.
The Import Outbound Certificate window opens.
To enable inbound HTTPS traffic inspection:
When a client from outside the organization initiates an HTTPS connection to an internal server, the Security Gateway intercepts the traffic. The Security Gateway inspects the inbound traffic and creates a new HTTPS connection from the gateway to the internal server. To allow seamless HTTPS inspection, the Security Gateway must use the original server certificate and private key.
To assign the certificate for inbound HTTPS inspection:
This creates a server certificate object.
The Server Certificates window in SmartDashboard has these options:
When you import a server certificate, enter the same password that was entered to protect the private key of the certificate on the server. The Security Gateway uses this certificate and the private key for SSL connections to the internal servers.
After you import a server certificate (with a P12 file extension) to the Security Gateway, make sure you add the object to the HTTPS Inspection Policy.
Do this procedure for all servers that receive connection requests from clients outside of the organization.
To add a server certificate:
The Import Certificate window opens.
The Successful Import window opens the first time you import a server certificate. It shows you where to add the object in the HTTPS Inspection Rule Base. Click Don't show this again if you do not want to see the window each time you import a server certificate and Close.
The HTTPS inspection policy determines which traffic is inspected. The primary component of the policy is the Rule Base. The rules use the categories defined in the Application and URL Filtering Database, network objects and custom objects (if defined).
The HTTPS Rule Base lets you inspect the traffic on other network blades. The blades that HTTPS can operate on are based on the blade contracts and licenses in your organization and can include:
If you enable Identity Awareness on your Security Gateways, you can also use Access Role objects as the source in a rule. This lets you easily make rules for individuals or different groups of users.
To access the HTTPS inspection Rule Base:
In SmartDashboard, open the Policy page from the specified blade tab:
When you enable HTTPS inspection, a predefined rule is added to the HTTPS Rule Base. This rule defines that all HTTPS and HTTPS proxy traffic from any source to the internet is inspected on all blades enabled in the Blade column. By default, there are no logs.
The columns of a rule define the traffic that it matches and if that traffic is inspected or bypassed. When traffic is bypassed or if there is no rule match, the traffic continues to be examined by other blades in the Security Gateway.
The sequence of rules is important because the first rule that matches is applied.
For example, if the predefined rule inspects all HTTPS traffic from any category and the next rule bypasses traffic from a specified category, the first rule that inspects the traffic is applied.
Give the rule a descriptive name. The name can include spaces.
Double-click in the Name column of the rule to add or change a name.
The source is where the traffic originates. The default is Any.
Important - A rule that blocks traffic, with the Source and Destination parameters defined as Any, also blocks traffic to and from the Captive Portal. |
Put your mouse in the column and a plus sign shows. Click the plus sign to open the list of network objects and select one or multiple sources. The source can be an Access Role object, which you can define when Identity Awareness is enabled.
Choose the destination for the traffic. The default is the Internet, which includes all traffic with the destination of DMZ or external. If you delete the destination value, the rule changes to Any, which applies to traffic going to all destinations
Important - A rule that blocks traffic, with the Source and Destination parameters defined as Any, also blocks traffic to and from the Captive Portal. |
To choose other destinations, put your mouse in the column and a plus sign shows. Click the plus sign to open the list of network objects and select one or multiple destinations.
By default, HTTPS traffic on port 443 and HTTP and HTTPS proxy on port 8080 is inspected. You can include more services and ports in the inspection by adding them to the services list.
To select other HTTPS/HTTP services, put your mouse in the column and a plus sign shows. Click the plus sign to open the list of services and select a service. Other services, such as SSH are not supported.
The Site Category column contains the categories for sites and applications that users browse to and you choose to include. One rule can include multiple categories of different types.
Important -
|
You can also include custom applications, sites, and hosts. You can select a custom defined application or site object with the Custom button or create a new host or site with the New button at the bottom of the page.
To add site categories to a rule:
Put your mouse in the column and a plus sign shows. Click the plus sign to open the Category viewer. For each category, the viewer shows a description and if there are applications or sites related with it.
You can create a new host site object to use in the HTTPS Rule Base if there is no corresponding existing category. Only the domain name part or hosts part of the URL is supported.
To create a new host site:
The Hosts/Sites window opens.
The new host site is added to the Selected list and can be added to the Rule Base.
The action is what is done to the traffic. Click in the column to see the options and select one to add to the rule.
Choose if the traffic is logged in SmartView Tracker or if it triggers other notifications. Click in the column and the options open. The options include:
Choose the blades that will inspect the traffic. Click in the column and the options open. The options include:
Important - The blade options you see are based on the blade contracts and licenses in your organization. |
Choose which Security Gateways the rule will be installed on. The default is All, which means all Security Gateways that have HTTPS inspection enabled. Put your mouse in the column and a plus sign shows. Click the plus sign to open the list of available Security Gateways and select.
Choose the certificate that is applicable to the rule. The Security Gateway uses the selected certificate for communication between the Security Gateway and the client.
Check Point dynamically updates a list of approved domain names of services from which content is always allowed. This option makes sure that Check Point updates or other 3rd party software updates are not blocked. For example, updates from Microsoft, Java, and Adobe.
To bypass HTTPS inspection for software updates:
Enhanced HTTPS Inspection Bypass lets the gateway bypass traffic (according to the HTTPS inspection policy) to servers that require client certificate authentication and non-browser applications.
This feature is supported on R77.30 and higher gateways.
To enable enhanced HTTPS inspection:
$FWDIR/boot/modules/fwkern.conf
file on the gateway, add:enhanced_ssl_inspection=1
You can configure this feature without changing the configuration file, but it does not survive reboot:
In expert mode, run: fw ctl set int enhanced_ssl_inspection 1
The Gateways pane lists the gateways with HTTPS Inspection enabled. Select a gateway and click Edit to edit the gateway properties. You can also search, add and remove Security Gateways from here.
For each gateway, you see the gateway name, IP address and comments.
In the CA Certificate section, you can renew the certificate validity date range if necessary and export it for distribution to the organization client machines.
If the Security Management Server which manages the selected Security Gateway does not have a generated CA certificate installed on it, you can add it with Import certificate from file.
When a client initiates an HTTPS connection to a web site server, the Security Gateway intercepts the connection. The Security Gateway inspects the traffic and creates a new HTTPS connection from the Security Gateway to the designated server.
When the Security Gateway establishes a secure connection (an SSL tunnel) to the designated web site, it must validate the site server certificate.
HTTPS Inspection comes with a preconfigured list of trusted CAs. This list is updated by Check Point when necessary and is automatically downloaded to the Security Gateway. The system is configured by default to notify you when a Trusted CA update file is ready for installation. The notification in SmartDashboard shows as a pop-up notification or in the Trusted CAs window in the Automatic Updates section. After you install the update, make sure to install the policy. You can select to disable the automatic update option and manually update the Trusted CA list.
If the Security Gateway receives a non-trusted server certificate from a site, by default the user gets a self-signed certificate and not the generated certificate. A page notifies the user that there is a problem with the website security certificate, but lets the user continue to the website.
You can change the default setting to block untrusted server certificates.
The trusted CA list is based on the Microsoft Root Certificate Program.
Updates for the trusted CA list and Certificate Blacklist will be published from time to time on the Check Point web site. They are automatically downloaded to the Security Management Server by default. When you are sent a notification that there is an update available, install it and do the procedure. The first notification is shown in a popup balloon once and then in the notification line under HTTPS Inspection > Trusted CAs. You can disable automatic updates if necessary.
To update the Trusted CA list and Certificate Blacklist:
You see the certificates that will be added or removed to the lists and the validity date range of the certificates added to the Trusted CA list.
The certificates will be added or removed respectively from the lists.
To disable automatic updates:
To add a trusted CA manually to the Security Gateway, you must export the necessary certificate from a non-trusted web site and then import it into SmartDashboard.
To export a CA certificate to add to the Trusted CAs list:
To import a CA certificate to the Trusted CAs list:
The certificate is added to the trusted CAs list.
You can save a selected certificate in the trusted CAs list to the local file system.
To export a CA certificate:
A CER file is created.
When a Security Gateway receives an untrusted certificate from a web site server, the settings in this section define when to drop the connection.
Untrusted server certificate
When selected, traffic from a site with an untrusted server certificate is immediately dropped. The user gets an error page that states that the browser cannot display the webpage.
When cleared, a self-signed certificate shows on the client machine when there is traffic from an untrusted server. The user is notified that there is a problem with the website's security certificate, but lets the user continue to the website (default).
Revoked server certificate (validate CRL)
When selected, the Security Gateway validates that each server site certificate is not in the Certificate Revocation List (CRL) (default).
If the CRL cannot be reached, the certificate is considered trusted (this is the default configuration). An HTTPS Inspection log is issued that indicates that the CRL could not be reached. This setting can be changed with GuiDBedit. Select Other > SSL Inspection > general_confs_obj and change the attribute drop_if_crl_cannot_be_reached
from false to true.
To validate the CRL, the Security Gateway must have access to the internet. For example, if a proxy server is used in the organizational environment, you must configure the proxy for the Security Gateway.
To configure the proxy:
When cleared, the Security Gateway does not check for revocations of server site certificates.
Important - Make sure that there is a rule in the Rule Base that allows outgoing HTTP from the Security Gateway. |
Expired server certificate
Track validation errors
Choose if the server validation traffic is logged in SmartView Tracker or if it triggers other notifications. The options include:
Automatically retrieve intermediate CA certificates
You can create a list of certificates that are blocked. Traffic from servers using the certificates in the blacklist will be dropped. If a certificate in the blacklist is also in the Trusted CAs list, the blacklist setting overrides the Trusted CAs list.
Choose if the dropped traffic is logged in SmartView Tracker or if it triggers other notifications. The options include:
Secure connections between a client and server with no traffic create logs in SmartView Tracker labeled as "Client has not installed CA certificate". This can happen when an application or client browser fails to validate the server certificate. Possible reasons include:
The option in the HTTPS Validation pane:
Log connections of clients that have not installed the CA certificate
You can configure a gateway to be an HTTP/HTTPS proxy. When it is a proxy, the gateway becomes an intermediary between two hosts that communicate with each other. It does not allow a direct connection between the two hosts.
Each successful connection creates two different connections:
Proxy Modes
Two proxy modes are supported:
Access Control
You can configure one of these options for forwarding HTTP requests:
Ports
By default, traffic is forwarded only on port 8080. You can add or edit ports as required.
Advanced
By default, the HTTP header contains the Via proxy related header. You can remove this header with the Advanced option.
You can also use the Advanced option to configure the X-Forward-For header that contains the IP address of the client machine. It is not added by default because it reveals the internal client IP.
Logging
The Security Gateway opens two connections, but only the Firewall blade can log both connections. Other blades show only the connection between the client and the gateway. The Destination field of the log only shows the gateway and not the actual destination server. The Resource field shows the actual destination.
To configure a Security Gateway to be an HTTP/HTTPS proxy:
Note - If you select Non Transparent mode, make sure to configure the clients to work with the proxy.
The X-Forward-For header must be configured if traffic will be forwarded to Identity Awareness Security Gateways that require this information for user identification.
The Security Gateway runs different web-based portals over HTTPS:
All of these portals can resolve HTTPS hosts to IPv4 and IPv6 addresses over port 443.
These portals (and HTTPS inspection) support the latest versions of the TLS protocol. In addition to SSLv3 and TLS 1.0 (RFC 2246), the Security Gateway supports:
Support for TLS 1.1 and TLS 1.2 is enabled by default but can be disabled in SmartDashboard (for web-based portals) or GuiDBedit (for HTTPS Inspection).
To configure TLS protocol support for portals:
The Advanced Configuration window opens.
To Configure TLS Protocol Support for HTTPS inspection:
Logs from HTTPS Inspection are shown in SmartView Tracker. There are two types of predefined queries for HTTPS Inspection logs in SmartView Tracker:
To open SmartView Tracker:
These are the predefined queries in Predefined > Network Security Blades > HTTPS Inspection.
HTTPS Validation values are:
When applying HTTPS Inspection to a specified blade:
An administrator must have HTTPS inspection permissions to see classified data in HTTPS inspected traffic.
To set permissions for an administrator in a new profile:
The Permissions Profile Custom Properties window opens.
To edit an existing permissions profile:
Events from HTTPS Inspection are shown in SmartEvent. There are two types of predefined queries for HTTPS Inspection events in SmartEvent:
To open SmartEvent:
SmartEvent supplies advanced analysis tools with filtering, charts, reporting, statistics, and more, of all events that pass through enabled Security Gateways. SmartEvent shows all HTTPS Inspection events.
You can filter the HTTPS Inspection information for fast monitoring on HTTPS Inspection traffic.
SmartEvent shows information for all Software Blades in the environment.
There are two types of predefined queries for HTTPS Inspection events in SmartEvent:
HTTPS Inspection Queries
Blade Queries
On the Advanced > Engine Settings pane, configure settings related to engine inspection, the Check Point Online Web Service, Application Control and URL Filtering sessions, and compatibility with gateways from lower versions (Web Browsing application and session unification).
Select the behavior of the Application Control and URL Filtering engine, if it is overloaded or fails during inspection. For example, if the application inspection is terminated in the middle for any reason. By default, in such a situation all application and site traffic is blocked.
The Check Point Online Web Service is used by the URL Filtering engine for updated website categorization and by the Application Control engine for updated Widget definitions. The responses the Security Gateway gets are cached locally to optimize performance.
You can enable these URL Filtering features:
Categorize HTTP sites
Selecting this option lets you categorize HTTPS sites without activating HTTPS inspection. Each site is filtered and categorized according to its Domain Name. When this option is enabled, the server certificate is detected and validated. If the certificate is:
The Domain Name is extracted from the certificate and used to categorize the site
The site is categorized according to IP address
Before extracting the Domain Name from the server certificate, the certificate is validated by checking it against the:
If your company issues certificates, you must add the company Certificate Authority to the list of Trusted CAs.
Important -
|
Fine tuning
Categorizing HTTPS sites according to DN can be fine-tuned by editing these properties in GuiDBedit:
urlf_ssl_cn_enc_http_services_only
Value |
Meaning |
---|---|
False |
The Security Gateway listens for SSL signatures on all ports |
True |
|
urlf_ssl_cn_max_server_hello_size
The maximum size of the certificate in bytes.
urlf_ssl_cn_wstlsd_ttl
The maximum amount of time to wait while the DN is being extracted from a certificate. After the default value expires, the IP address is used to categorize the site. The default value (10 seconds) is a Check Point internal attribute. We do not recommend that you change it.
Enforce safe search in search engines
Selecting this option enforces a safe search. The URL Filtering Policy applies the strictest safe search options offered by the search engine. Regardless of what the user has selected, the strictest Safe Search settings are applied. Explicit sexual content is filtered out of the search results.
Categorize cached pages and translated pages in search engines
Selecting this option enables the categorization of a search engine cached and translated pages. Pages from the search engine cache are not categorized as "search engine pages". Cached and translated pages are categorized according to the original web site they were cached and translated from.
Application and URL traffic generate a large quantity of logs. To make the quantity of logs manageable, you can consolidate logs by session. A session is a period that starts when the user first accesses an application or site. The Security Gateway records one log for each application or site accessed during a session. All actions that the user does in the session are included in the log.
There are 3 tracking options you can use:
To adjust the length of a session:
Enable Web Browsing logging and policy enforcement - The Web Browsing application includes all HTTP traffic that is not a defined application. Web Browsing is enabled by default. If you disable it:
For compatibility with Security Gateway versions earlier than R75.20, click Settings to configure backwards compatibility for use with Application Control.
Identity Awareness and Application and URL Filtering can be used together to add user awareness, computer awareness, and application awareness to the Check Point Security Gateway. They work together in these procedures:
In SmartView Tracker logs and SmartEvent events, you can see which user and IP address accesses which applications. For more details, see the R77 Identity Awareness Administration Guide.
The Security Gateway inspects Application and URL Filtering requests and applies rules in a sequential manner. When a Security Gateway receives a packet from a connection, it examines the packet against the first rule in the Rule Base. If there is no match, it goes on to the second rule and continues until it completes the Rule Base. If no rule matches, the packet is allowed.
In rules with access roles, you can add a property in the Action field to redirect traffic to the Captive Portal. If this property is added, when the source identity is unknown and traffic is HTTP, the user is redirected to the Captive Portal. If the source identity is known, the Action in the rule (Allow or Block) is enforced immediately and the user is not sent to the Captive Portal. When the system gets the credentials from the Captive Portal, it can examine the rule for the next connection.
In rules with access role objects, criteria matching works like this:
If all the conditions apply, the traffic is redirected to the Captive Portal to get credentials and see if there is a match.
If not all conditions apply, there is no match and the next rule is examined.
To redirect HTTP traffic to the Captive Portal:
The Action Properties window opens.
The Action column shows that a redirect to the Captive Portal occurs.
This is an example of an Application and URL Filtering Rule Base that shows how criteria matching operates:
No. |
Source |
Destination |
Service |
Applications/Sites |
Action |
---|---|---|---|---|---|
1 |
Finance_Dept (Access Role) |
Internet |
Any |
Salesforce |
Allow |
2 |
Any_identified_user |
Internet |
Any |
Remote Administration Tool (non-HTTP category) |
Allow |
3 |
Any_identified_user |
Internet |
Any |
Any recognized |
Block |
When browsing the Internet, different users experience different outcomes:
Example 1 - An unidentified Finance user that attempts to access Salesforce is sent to the Captive Portal. This happens because the action is set to redirect to the Captive Portal. After entering credentials and being identified, the user is granted access according to rule number 1.
Example 2 - An unidentified user that attempts to access the Remote Administration Tool matches rule 2, but not the Source column. Because the application is not HTTP, traffic cannot be redirected to the Captive Portal. Since none of the rules match, the user is granted access to the Remote Administration Tool.
Example 3 - An unidentified user that browses to Gmail does not match rules 1 and 2 because of the application. In rule 3 there is also no match because the action is not set to redirect to the Captive Portal. Since none of the rules match, the user is granted access to Gmail.
If your organization uses an HTTP proxy server behind the Security Gateway, the Rule Base cannot match taking into account identities. Therefore, you cannot see identities of users behind the proxy. Application Control and URL Filtering logs show the proxy as their source IP address and not the user identity. Application Control, URL Filtering and Identity Awareness Security Gateways can use X-Forward-For HTTP header, which is added by the proxy server, to resolve this issue. When you configure the proxy server to add X-Forward-For HTTP header and the Check Point gateways to use it, you will see the correct source identities for traffic that goes through the proxy.
You can also configure the gateways to hide and strip the X-Forward-For header in outgoing traffic so that internal IP addresses will not be seen in requests to the internet.
To use X-Forwarded-For HTTP header:
When you configure Virtual Systems to use the Application Control and URL Filtering Software Blades, make sure that the VSX Gateway (VS0) can connect to the Internet. Updates are done only through this Virtual System.
To enable Application and URL Filtering Categories on Virtual Systems:
Note - You do not have to enable these blades on the VSX Gateway (VS0)