Support Center > Search Results > SecureKnowledge Details
Best Practices - Application Control Technical Level

Table of Contents:

  • Application Control Overview
  • Blacklist vs. Whitelist
  • Recommended Categories to Block
  • Setting Your Policy for Unknown Traffic
  • HTTPS Inspection
  • Writing Your Own Application
  • Common Use Cases
  • Application Control & UserCheck
  • Application Control & Identify Awareness
  • Request New Application
  • Report Spam Miss-classification and Request URL Categorization
  • Network Protocols Restrictions
  • QUIC Protocol
  • SSL/TLS Older Versions
  • Ensuring the Gateway Receives Online Updates
  • Office 365
  • Optimization
  • Related solutions


Application Control Overview

The Application Control Software Blade provides application security and identity control to organizations of all sizes. It enables IT teams to easily create granular policies, based on users or groups, to identify, block or limit usage of web applications, network protocols and and other non-standard applications.

This article provides guidance for fine tuning the product, as well as information that allows you to leverage advanced capabilities in the product.


Blacklist vs. Whitelist

There are two ways to enforce application control policy:

  • Blacklist: Block any undesired traffic and allow everything else. By far the most common configuration, this approach is easier to manage as it requires little administrative overhead. You use the network policy to quickly block any unneeded service on the network. At the same time, the traffic that does match the network policy allowed rules is inspected by Application Control. Any unwanted application or category is blocked.
  • Whitelist: Allow any application or network protocol that you want accessible. The default action is to block traffic not matching any of the rules (also known as the cleanup rule). In this approach, every little change in application traffic could result in new unidentified streams that will be blocked, if they are not correlated with the main app. This may cause disruptions in network resource availability.


  • Critical Risk and Anonymizers: These categories includes applications such as UltraSurf, Tor, Psiphon and many others that allow any user to bypass the access policy, and may incur data leakage. Anonymizers establish an encrypted tunnel that is used to hide identifying information.
  • P2P File Sharing: File sharing protocols and applications, such as BitTorrent, eMule & Soulseek, are often used for piracy and utilize excessive amounts of network resources.
  • Spyware: Applications in this category are often used to share sensitive information without the user's knowledge.
  • Remote Admin: Protocols and applications used for remote control should be avoided due to the added risk of use without user consent. Proper exceptions should be configured in the rule base to allow remote help from support and help desk teams for users within an organization or for customers support.


Setting Your Policy for Unknown Traffic

"Unknown traffic" is non-HTTP traffic that does not match anything in your current application database. Logs for unknown traffic should be examined carefully to understand what is behind them. Traffic that results in such a log could be a product of a protocol that is not yet supported, anonymized traffic which uses a proprietary protocol, or even a mis-detected supported protocol or application.

As the options listed have either security or connectivity concerns (often both), report any missing protocol or misdetection directly to the Application Control team. In general, once the unknown traffic has been inspected and categorized correctly, it is recommended you block such traffic facing the Internet and continue to monitor internal traffic.

Note: Unknown traffic will be matched on rules containing "Any Recognized" in addition to specific rules.


HTTPS Inspection

HTTPS inspection allows us to inspect outgoing traffic wrapped by SSL/TLS, and to enforce the customer policy based on the traffic. Using the Dropbox web site as an example, if you want to block Dropbox completely, HTTPS inspection is not really required, as we can easily tell Dropbox is being accessed by looking at the TLS handshake. However, if you only want to allow downloads from Dropbox while blocking uploads from within the organization, that task cannot be accomplished without HTTPS inspection.

Another example: Google, one of the world’s most popular content providers (Search, YouTube, Gmail, Drive…) uses a so called wildcard certificate (* These kinds of certificates make it very hard to distinguish between different services without using HTTPS inspection.


Writing Your Own Application

There are times when you want to create your own applications, which must then be configured within your rule base. Examples include internally developed software that needs to be recognized, identifying web traffic coming from a specific referrer (or any other header), blocking or identifying specific file types, and more.

Refer to the Check Point Application Control Self Help Guide.


Common Use Cases

We often get requests to allow certain features of a web application while blocking others.

Let's take for example the Evernote application and consider the following scenario:

The security administrator decides to allow usage of Evernote within the organization, but to block any attempt to upload content or create new notes.

A search in AppWiki for Evernote, shows 2 apps listed,: "Evernote" and "Evernote-upload". The security administrator now needs to add a rule that blocks "Evernote-upload" and make sure it is located above a rule that allows "Evernote." This ensures that any attempt to upload files is blocked, while regular usage of the web application is allowed.

Note: Security administrators should be aware of the implications of allowing a network protocol (explicit or implicit (via risk or additional category), as it may pose a security concern. Let us look at the "SSL Protocol" application: Allowing it in one of the top rules either directly, or by allowing the "Very Low Risk" category will match a huge amount of traffic, and may result in traffic passing without additional inspection.

In R80.10:


Application Control & UserCheck

UserCheck allows the security administrator to show a block message when end users try to access forbidden resources. UserCheck can also be used when the user attempts to access web resources with questionable content that are usually blocked. This is where the "Ask" directive comes into play; if the user provides a valid reason for the attempt, access may be granted.

To download UserCheck client:

  1. In Smart Console, open the General Properties window of the gateway object.
  2. If Data Loss Prevention is enabled on the gateway, select Data Loss Prevention. In the UserCheck area, click Download Client.
  3. If Application Control and URL Filtering is enabled on the gateway, select UserCheck. In the UserCheck Client area, click Download Client.
  4. If DLP and Application Control and URL Filtering are enabled on the Security Gateway, you can get the MSI file from the Data Loss Prevention page or the UserCheck page.


Application Control & Identify Awareness

For Identity Awareness to correctly identify application usage by users behind a web proxy, you must enable the detection of X-Forwarded-For under the gateway properties, as seen below:

In R80.10: Under 'Menu > Manage Policies and Layers > Layers > New or Edit > Advanced'


Request New Application

We urge you to request our support for any new applications that are not already covered in our application database.

Whether you would like to add a new mobile application that is popular in your organization, or an enterprise grade application deployment, collect as much information as you can, and refer to the Check Point Application Control Self Help Guide for the procedure to request a new application.

You are also encouraged to take as many captures as you can and attach them to your request.


Report Spam Miss-classification and Request URL Categorization

Contact us via this form.

Network Protocols Restrictions

Note: This section applies to Security Gateways versions up to R77.xx

Network protocols used in the application control policy, by default will be matched on any port by default. It is possible to restrict each protocol to its standard port by using the Service column, as seen below.

To use this technique, you will first need to "unhide" the Service column. Right-click on one of the column names in the Application Control rule base and select the Service column (see image below):


Network Protocols Restrictions (in R80.10)

Network protocols used in the application control policy, by default will be matched on any port by default. It is possible to restrict each protocol to its standard port by using the Services (Services & Applications column in R80.10), as seen below:

In order to use this technique, double-click on the service (in this example ssh_version_2):

Further information on protocol signature can be found in sk114917 - Application Control Network Protocols in R80.10


QUIC Protocol

QUIC Protocol (UDP, port 443) is a (still evolving) protocol invented by Google to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency. According to the latest information published by Google, half of Chrome’s requests to Google servers are served over QUIC Protocol. Application Control and URLF features like Safe Search, Translate, and Cache rely on traffic inspection to classify web traffic. When QUIC is used, we cannot inspect parts of the traffic, which may impact our ability to reliably classify content. If you see this in your organization, we currently recommend you block QUIC Protocol using Application Control.


SSL/TLS Older Versions

Older versions of the SSL Protocol are considered highly vulnerable to various methods of exploitation. Blocking their usage in your organization is fairly simple; all you need to do is add a rule similar to the one below:

In R80.10:


Ensuring the Gateway Receives Online Updates

If you want to check your gateway’s update status (or if any online updates were received), enter the following command in the shell prompt:

cat $FWDIR/appi/update/Version

The output should look similar to:


:pkg_file_name ("appi_urlf_db_pkg.tar")

:md5sum ("8b137fdf39c656419d7f10ba3135486e")

:pkg_version (290915_3)

:appi_version ("210915_1")

:urlf_version ("290915_3")

:pkg_timestamp (1443506853)

:appi_filename ("appi_db.C.tmp")

:urlf_filename ("urlf_db.bin.tmp")


The appi_version field (bolded) is formatted as DDMMYY_X (X - Internal).

Note: Application Control updates are usually released online once a week.


Office 365

Microsoft Office 365 supported applications are assigned an additional category called "Microsoft Services" for ease of use in the Application Control rule base. This category includes all of the Microsoft related content, including Office 365 applications, Microsoft account, etc.

Additional information can be found in:



For Application Control optimization, please refer to Section (3-10) in sk98348 - Best Practices - Security Gateway Performance.


Important: For FAQ, refer to the Check Point Application Control Self Help Guide

Give us Feedback
Please rate this document