> Source: [sk112249](https://support.checkpoint.com/results/sk/sk112249)

# sk112249 - Best Practices - Application Control

| Property | Value |
|----------|-------|
| Solution ID | sk112249 |
| Date Created | 2016-07-05 |
| Last Modified | 2025-05-22 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R82.10, R82, R81.20, R81.10 (EOS), R81 (EOS) |

## Solution

**Table of Contents:**

* Application Control Overview
* Block-list vs. Allow-list
* 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
* Ensuring the Gateway Receives Online Updates
* Office 365
* Optimization
* FAQ
* Related solutions

### Application Control Overview {#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.

### Block-list vs. Allow-list {#Blacklist vs. Whitelist}

There are two ways to enforce application control policy:

* **Block-list:**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.
* **Allow-list:**   
  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.

### Recommended Categories to Block {#Recommended Categories to Block}

* **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 {#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.

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}

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, and so on) uses a so-called wildcard certificate (\*.google.com). These kinds of certificates make it very hard to distinguish between different services without using HTTPS inspection.

### Writing Your Own Application {#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](https://sc1.checkpoint.com/documents/PDF/CP_Application_Control_Self_Help_Guide.pdf).

### Common Use Cases {#Common Use Cases}

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

Let us take for example the [Evernote](https://evernote.com/) 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](http://appwiki.checkpoint.com/appwikisdb/public.htm) for Evernote shows 2 apps - "**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.

Example from R77.30 SmartDashboard:

![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/Common_Use_Cases1607060003.png)

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

Example from R80.10 SmartConsole:

![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/11708230434.1.png)

### Application Control \& UserCheck {#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.

For more information about the UserCheck Client, see the [Quantum Security Management Administration Guide](https://support.checkpoint.com/product/184#f-commonsource=C.%20Documentation) for your version \> Chapter "UserCheck in the Access Control Policy" \> Section "UserCheck Client".

To download a UserCheck Client:

1. In SmartConsole, go to the **Gateways \& Servers** view.
2. Double-click the Security Gateway object.
3. In the left tree, click the **General Properties** page.
4. On the **Network Security** tab, enable the **Application Control** Software Blade.
5. In the left tree, click the **UserCheck** page.
6. At the top, select **Enable UserCheck for active blades**.
7. In the **UserCheck Client** section, select **Activate UserCheck Client support**.
8. Click OK.
9. Install the Access Control policy.
10. Double-click the Security Gateway object again.
11. In the left tree, click the **UserCheck** page.
12. In the **UserCheck Client** section, click **Download Client** .  
    The UserCheck portal opens in your default web browser, and the download starts.

### Application Control \& Identify Awareness {#Application Control & Identify Awareness}

For Identity Awareness Software Blade to correctly identify application usage by users behind a web proxy, you must enable the detection of X-Forwarded-For in the Security Gateway object:

1. Configure the Security Gateway object:
   1. In SmartConsole, go to the **Gateways \& Servers** view.
   2. Double-click the Security Gateway object.
   3. In the left tree, click the **General Properties** page.
   4. On the **Network Security** tab, enable the **Identity Awareness** Software Blade and follow the wizard.
   5. In the left tree, click the **Identity Awareness** page.
   6. At the top, select **Enable UserCheck for active blades**.
   7. In the **Proxy configuration for supported blades** section, select **Detect users located behind http proxy using X Forward-For header** .  
      Example:  
      ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/Applic_Control_and_Identity_Awareness1607060012.png)
   8. Click **OK**.
2. Configure the relevant Layer in the Access Control policy:
   1. In the top left corner, click **Menu** \> **Manage policies and layers**.
   2. In the left panel, click **Layers**.
   3. Click the relevant layer.
   4. From the top toolbar, click **Edit**.
   5. In the left panel, click the **Advanced** page.
   6. In the **Proxy Configuration** section, select **Detect users located behind http proxy configured with X-Forward-For** .  
      Example:  
      ![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/detect users located behind an HTTP proxy with an X Forward-For header1708230438.png)
   7. Click **OK** to close the **Layer Editor** window.
   8. Click **Close** to close the **Manage policies and layers** window.
3. Install the Access Control policy.

### Request New Application {#Request New Application}

We urge you to request our support for any new applications that are not already covered in our [application database](http://appwiki.checkpoint.com/appwikisdb/public.htm).

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 th [Check Point Application Control Self Help Guide](https://sc1.checkpoint.com/documents/PDF/CP_Application_Control_Self_Help_Guide.pdf) 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 {#Report Spam Miss-classification}

Follow [sk113512](https://support.checkpoint.com/results/sk/sk113512).

### Network Protocols Restrictions {#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.

Example from R77.30 SmartDashboard:

![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/Network_Protocols_Restrictions1607060026.png)

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):

Example from R77.30 SmartDashboard:

![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/Network_Protocols_Restrictions_21607060031.png)

**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 \& Applications** column (**Services** column in SmartDashboard R77.30 and lower):

Example from R80.10 SmartConsole:

![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/61708230449.png)

To use this technique, double-click on the service (in this example, `ssh_version_2`):

Example from R80.10 SmartConsole:

![](https://sc1.checkpoint.com/sc/SolutionsStatics/sk112249/71708230453.png)

Further information on protocol signature can be found in [sk114917 - Application Control Network Protocols in R80.10](https://support.checkpoint.com/results/sk/sk114917).

### QUIC Protocol {#QUIC Protocol}

[QUIC](https://en.wikipedia.org/wiki/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](https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html) 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.  

**Note** - Starting from the R82 version, Check Point Security Gateways can inspect HTTP/3 traffic according to the configuration of the enabled Software Blades. For more information, see the [Quantum Security Management Administration Guide](https://support.checkpoint.com/product/184#f-commonsource=C.%20Documentation) for your version \> Chapter "HTTPS Inspection".

### Ensuring the Security Gateway Receives Online Updates {#Ensuring the Gateway Receives Online Updates}

To check the Application Control database update status on your Security Gateway:

1. Connect to the command line on the Security Gateway / each Cluster Member.
2. Log in to the Expert mode.
3. Run:  
   `cat $FWDIR/appi/update/Version`

The output should look similar to this:

```
(
        :pkg_file_name ("appi_urlf_db_pkg.tar")
        :md5sum ("91053baf319f2f55e750fba6db79a956")
        :pkg_version ("220525_3")
        :appi_version ("180525_1")
        :urlf_version ("220525_3")
        :pkg_timestamp ("1747904443388")
        :appi_filename ("appi_db.C.tmp")
        :urlf_filename ("urlf_db.bin.tmp")
)
```

```

```

The "`appi_version`" parameter contains the date of the last received package in the format "DDMMYY_\<X\>".

### Office 365 {#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, Outlook.com etc.

Additional information can be found in:

* [sk110679 - Application Control support for Office 365](https://support.checkpoint.com/results/sk/sk110679)
* [sk112354 - How to allow Office 365 services in Application Control R77.30 and above](https://support.checkpoint.com/results/sk/sk112354)

### Optimization {#Optimization}

For Application Control optimization, refer to [sk98348 - Best Practices - Security Gateway Performance](https://support.checkpoint.com/results/sk/sk98348) \> Section "(3-10) Best practices - Application Control \& URL Filtering optimization".

### FAQ {#FAQ}

Refer to the [Check Point Application Control Self Help Guide](https://sc1.checkpoint.com/documents/PDF/CP_Application_Control_Self_Help_Guide.pdf).

### Related solutions {#Related solutions}

* [sk73220 - ATRG: Application Control](https://support.checkpoint.com/results/sk/sk73220)
* [sk120556 - Application Control rulebase does not enforce Non TCP/UDP services that are included in a Service group](https://support.checkpoint.com/results/sk/sk120556)
* [sk174045 - Wrong rule match on the first access to a URL/Website](https://support.checkpoint.com/results/sk/sk174045)

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content