Creating Application Control and URL Filtering Rules

Create and manage the Policy for Application ControlClosed Check Point Software Blade on a Security Gateway that allows granular control over specific web-enabled applications by using deep packet inspection. Acronym: APPI. and URL FilteringClosed Check Point Software Blade on a Security Gateway that allows granular control over which web sites can be accessed by a given group of users, computers or networks. Acronym: URLF. in the Access Control Policy, in the Access Control view of SmartConsoleClosed Check Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on.. 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.

Best Practice - Do not use Application Control and URL Filtering in the same ruleClosed Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session., this may lead to wrong rule matching. Use Application Control and URL Filtering in separate rules. This makes sure that the URL Filtering rule is used as soon as the category is identified. For more information, see sk174045.

Blocking URL Categories

Scenario: I want to block pornographic sites. How can I do this?

You can do this by creating a rule that blocks all sites with pornographic material with the Pornography category. If you enable Identity Awareness on a Security Gateway, you can use it together with URL Filtering to make rules that apply to an access role. Use access role objects to define users, machines, and network locations as one object.

In this example:

  • You have already created an Access Role (Identified_Users) that represents all identified users in the organization.

  • You want to block sites related to pornography.

The procedure is similar to Blocking Applications and Informing Users.

Using Dynamic URL Lists for Application Control and URL Filtering

Starting from R81.20 Jumbo Hotfix Accumulator Take 115, you can create a Dynamic URL List for Application Control and URL Filtering. The Dynamic URL List allows automatic update of the URL list based on a feed file, without requiring a policy installation for each URL change. Policy installation is only needed when modifying the configuration of the URL list itself (such as adding a new Dynamic URL List object or changing feed location). This feature provides greater flexibility and efficiency when managing allow lists and block lists.

To configure a Dynamic URL List

  1. Create a file with the list of URLs

    Prepare a plain-text file containing the required URLs (for example, with the name urls.txt).

    Notes:

    • Enter each URL entry on a new line.

    • You can configure URLs using Regular Expressions:

      Example: To match example.com and its sub-domains (such as support.example.com, you can configure the URL in one of these ways:

      \/example\.com
      \.example\.com
      \/example\.com|\.example\.com

      For more examples on defining URLs as Regular Expressions, see sk165094.

    • Lines beginning with the # character are considered comments and are ignored.

  2. Optional: Create a version file

    Create a plain-text file named version in the same directory as the urls.txt file.

    The file must contain a timestamp of the last update of the urls.txt file. The timestamp must be in Unix Epoch format

  3. Create the dynamic configuration file for the URLs

    Create a plain-text file named dynamic_urls_lists.C (this name is mandatory and case-sensitive) in the format of the example below.

    This example contains two URLs and uses HTTP authentication in the Urls2 list:

    (
    :dynamic_urls_lists (
    : (
    :name (Urls1) # Must be the same as the name of the Custom Application/Site object in SmartConsole
    :path (https://172.16.4.191/urls) # Must be the same as configured in the file "urls.txt" and in the Custom Application/Site object
    :regex (false)
    )
    : (
    :name (Urls2) # Must match the name of the Custom Application/Site object in SmartConsole
    :path (http://example.com/content) # Must be the same as configured in the file "urls.txt" and in the Custom Application/Site object
    :username (user123)
    :password (7f737d777d1c) # Obfuscated password
    :regex (true)
    )
    )
    :update_interval (300) # Update interval in seconds
    )

    Notes:

    • Strings that appear after the # character are considered comments and are ignored.

    • In the name field, enter the application name. This name must match the name of the Custom Application/Site object you created in SmartConsole.

    • In the field :path, enter the applicable URL exactly as you configured it in the urls.txt file .

      To specify the URL using a Regular Expression:

      • In the file urls.txt, enter the URL using a Regular Expression

      • In the path field, enter the URL using a Regular Expression

      • In the regex field, configure the value true.

      Example:

      To match example.com and its sub-domains (such as support.example.com), configure the URL in one of these ways:

      \/example\.com
      \.example\.com
      \/example\.com|\.example\.com

      For more examples on defining URLs as Regular Expressions, see sk165094.

    • If HTTP authentication is required (RFC 7617):

      • In the :username field, enter the username.

      • In the :password field, enter the password.

        Important - Obfuscate the password using this Expert mode command:

        obfuscate_password <Password String>

      • If authentication is used, it is relevant for both the urls.txt and version files.

  4. In SmartConsole, create a Custom Application/Site object for each URL list

    1. In SmartConsole, go to the Object Explorer, click New > More > Custom Application/Site > Application/Site.

      The New Application/Site window opens:

    2. Enter the list name.

    3. In GeneralGeneralPrimary Category, select Custom_Application Site.

    4. In General > Match ByURL List, click the + sign.

    5. Enter the path to the list. In this example: https://172.16.4.191/urls

    6. If relevant, select URLs are defined as Regular Expressions.

    7. Click OK.

    8. Repeat these steps for each URL list.

  5. Deploy the configuration to the Security Gateway:

    1. Copy the dynamic_urls_lists.C file to the Security Gateway / each Cluster MemberClosed Security Gateway that is part of a cluster. / Scalable Platform Security Group to this directory:

      $FWDIR/appi/update/

      Important - In the VSNext / VSXClosed Virtual System Extension. Check Point virtual networking solution, hosted on a computer or cluster with virtual abstractions of Check Point Security Gateways and other network devices. These Virtual Devices provide the same functionality as their physical counterparts. mode, you must copy the dynamic_urls_lists.C file to the $FWDIR/appi/update/ directory in the context of the specific Virtual Gateway / Virtual System:

      1. Connect to the command line on the VSNext Security Group/ VSX GatewayClosed Physical server that hosts VSX virtual networks, including all Virtual Devices that provide the functionality of physical network devices. It holds at least one Virtual System, which is called VS0. / VSX Cluster.

      2. Log in to the Expert mode.

      3. Go to the context of the specific Virtual Gateway / Virtual System. Run:

        vsenv <VSID>

      4. Go to the directory. Run:

        cd $FWDIR/appi/update/

      5. Get the absolute path. Run:

        pwd

    2. On a Scalable Platform Security Group, copy the file to each Security Group Member. Run:

      asg_cp2blades $FWDIR/appi/update/dynamic_urls_lists.C

      Important - In the VSNext / VSX mode, you must copy the file $FWDIR/appi/update/dynamic_urls_lists.C to the context of the specific Virtual Gateway / Virtual System. Instead of the $FWDIR path, use the absolute path from step a.

    3. In SmartConsole, install the Access Control policy on the Security Gateway / Security Cluster / Virtual Gateway / Virtual System object.

  6. Make sure that the URL list is accessible from the Security Gateway.

Notes:

  • After each change in the dynamic_urls_lists.C file, you must install the Access Control policy.

    Changes in the file with URLs (urls.txt) do not require policy installation.

  • If an invalid URL format is detected or if the URL list cannot be downloaded, the Security Gateway generates a log, and the URLs are not updated

  • There is no validation in SmartConsole.

  • To manually force an update, delete these files on the Security Gateway / Cluster Member / Security Group:

    $FWDIR/appi/update/URL_List_Version
    $FWDIR/appi/update/URL_List_next_update

    Important - In the VSNext / VSX mode, you must delete these files to the context of the specific Virtual Gateway / Virtual System.

  • To check the update status, examine this file:

    $FWDIR/appi/update/URL_List_status.C

    Important - In the VSNext/ VSX mode, examine this file in the context of the specific Virtual Gateway/ Virtual System.