Support Center > Search Results > SecureKnowledge Details
R77.30 Virtual Machine Scale Sets (VMSS) for Azure
Solution

Table of Contents:

  1. Overview
  2. Prerequisites
  3. Background
  4. Configuration
    1. Install a Check Point Management Server
    2. Create an Azure Active Directory Application and Service principal
    3. Configure the Check Point Management Server
    4. Deploy the Check Point Virtual Machine Scale Set
    5. Set up the external Load Balancer
    6. Set up Firewall and NAT rules
  5. Configuring Outbound Protection
  6. Additional information
    1. Downloading and installing the latest Auto Provisioning version
    2. Enabling and disabling Software Blades
    3. IPS Geo protection based on "X-Forwarded-For" HTTP header
    4. Licensing
    5. Testing scale in and scale out events
    6. Autoscale setting
    7. Automatic rule placement
    8. Troubleshooting
  7. Known limitations

 

(1) Overview

 

NOTE: This solution is deprecated. For up-to-date documentation on deploying CloudGuard for Azure Scale Sets see the Virtual Machine Scale Sets (VMSS) R80.10 and above for Microsoft Azure Administration Guide.

 

This article will guide you in:

  • Deploying a new R77.30 Virtual Machine Scale Set for Microsoft Azure.
  • Configuring existing R77.30 and  R80.10 Virtual Machine Scale Sets for Microsoft Azure for template versions lower than 20180610.
    • Template version can be identified on each CloudGuard instance at: /etc/cloud-version.

Note: For new R80.10 Virtual Machine Scale Set deployments, refer to Virtual Machine Scale Sets (VMSS) R80.10 and above for Microsoft Azure Administration Guide. Also, for existing R80.10 Virtual Machine Scale Set deployments of template versions 20180610 and above, refer to Virtual Machine Scale Sets (VMSS) R80.10 and above for Microsoft Azure Administration Guide .

Virtual Machine Scale Sets (VMSS) are an Azure Compute resource one can use to deploy and manage a set of identical VMs. The size of a set can increase and decrease based on the current needs.

A typical use case consists of a web application served by multiple web servers that are deployed across multiple fault and update domains. A Load Balancer would distribute network traffic across this group of web servers.
VMSS will increase or decrease the number of web servers according to the current load.

In the current cyber landscape, it is crucial to be able to protect these environments from attackers.
Any security solution used should be as scalable as the environment it is protecting.
It is also important that as the number of protected resources scales up or down, so does the number of protecting gateways.

This article will guide you toward achieving these goals using Check Point vSEC Security Gateways.

 

(2) Prerequisites

It is assumed that the reader is familiar with the following topics:

Vendor Topic
Azure
Check Point

 

(3) Background

  • Network Diagram

    This diagram depicts an Azure Virtual Network containing 2 subnets.

    An External Load Balancer sends incoming traffic to a Check Point Virtual Machine Scale Set (VMSS) residing on the external subnet.
    The gateways in the set inspect the traffic and, if allowed by policy, forward the traffic to an Internal Load Balancer.
    The Internal Load Balancer sends incoming traffic to a group of servers residing on a more internal subnet.
    Azure Autoscale is set up to increase or decrease the number of Check Point vSEC Security Gateways in the Virtual Machine Scale Set.

    The Check Point vSEC Security Gateways are managed by a Check Point Management Server.
    The Management Server can be located either in Azure, or on-premises.

  • Scale Out

    A scale out event can occur if the current load increases.
    When a scale out event is triggered:

    1. Azure Autoscale launches one or more new instances of the Check Point vSEC Security Gateway.
    2. The new instances automatically execute the Check Point First Time Configuration Wizard and then reboot.

    In the meantime, the Check Point Management Server detects that new Check Point instances have been launched.
    It waits until the vSEC Security Gateways have finalized the First Time Configuration Wizard, and then automatically:

    1. Initializes a Secure Internal Communication (SIC) channel with them.
    2. Installs a Security Policy on them.

    After a security policy is installed on these vSEC Security Gateways, these gateways start to respond to health probes. The load balancer then starts to forward new connections to them. The newly created vSEC Security Gateways report status and send logs to the Check Point Management Server.

  • Scale In

    A scale in event can occur as a result of a decrease of the current load.
    When a scale in event is triggered, Azure Autoscale designates one or more of the gateways as candidates for termination.
    The external load balancer stops forwarding new connections to these gateways, and later Autoscale terminates them.
    The Check Point Management Server detects that these vSEC Security Gateways have been terminated
    and automatically deletes these vSEC Security Gateways from its database.

Note: It is recommended to have at least 2 Security Gateways for redundancy and availability purposes (quote from What are virtual machine scale sets in Azure? (as of 01 Sep 2017): "Currently Virtual Machine Scale Sets only supports deploying to a single availability zone. Multi-zone deployment will be supported in the future.").

 

(4) Configuration

It is assumed that the following is already set up:

  • A Virtual Network consisting of at least:

    • A public subnet
    • A private subnet
  • A group of Servers deployed in the private subnets (possibly, part of its own VMSS).

  • An internal load balancer sending traffic to this group of Servers.

Auto Scale configuration consists of the following main steps:

  1. Install a Check Point Management Server
  2. Create an Azure Active Directory Application and Service principal
  3. Configure the Check Point Management Server
  4. Deploy the Check Point Virtual Machine Scale Set
  5. Set up the external Load Balancer
  6. Set up Firewall and NAT rules

 

Procedure:

  • (4-A) Install a Check Point Management Server

    The latest recommended version of Security Management Server is Check Point R80.10.
    For version R80, make sure you are using R80 image Take 132 or higher.
    The Security Management Server can be deployed either in Azure, or on-premises.

    In order to be able to control the vSEC Security Gateways:

    • The Management Server must be able to initiate connections to the vSEC Security Gateways.
    • The vSEC Security Gateways should be able to initiate connections to the Management Server (e.g., for sending logs).

    At the time of writing this article, a VM in a VMSS cannot be assigned a public IP address. As a result, the Management Server needs to be able to communicate with the VMSS over private IP addresses.
    This can be achieved in one of the following ways:

    • Installing the Security Management Server in the same Azure Virtual Network
    • Installing the Security Management Server in a peered Azure Virtual Network
    • Installing the Security Management Server in an on-premises network and connecting it to the Azure Virtual Network over ExpressRoute
    • Installing the Security Management Server in an on-premises network and connecting it to the Azure Virtual Network over a VPN

    Procedures:

    • Deploying a Management Server in Azure

      Follow the instructions in this section if you plan to deploy your Check Point Security Management Server in Azure.

      Deploy the following Azure marketplace solution:
      https://azuremarketplace.microsoft.com/en-us/marketplace/apps/checkpoint.vsec
      (select the "Check Point vSEC Security Management" software plan).

      The template takes the following parameters:

      Parameter Description
      Server Name The name of the Security Management Server.
      Credentials The SSH public key or the SSH password for managing the server.
      Subscription The subscription, into which the servers should be deployed.
      Resource Group The name of the resource group into which the server should be deployed.
      Location The Azure location, into which the server should be deployed.
      Network setting A pre-existing virtual network and its subnet, or a name of a new
      virtual network and subnet, into which the server should be deployed.
      Virtual Machine size The size of the Security Management Server virtual machine.
      Storage setting The name of an existing, or a new storage account to be used by the Security Management Server.
      Allowed GUI clients Addresses of allowed SmartConsole, Gaia Portal and SSH clients in CIDR notation.

      This template will deploy the Management Server in the selected subnet.
      When the management instance is started, it will automatically execute its own First Time Configuration Wizard.
      Note that it can take up to 30 minutes for this step to complete.

      When completed, proceed to section "(4-B) Create an Azure Active Directory Application and Service principal".

      Note: if the Management Server is deployed in Azure and manages the Gateways Auto Scaling group via their public IP addresses, make sure that the Management Server is identified by the Gateways via its public IP address. To achieve this, follow these steps:

      • Open Gateways & Servers in SmartConsole.
      • Double click on the line representing the Management Server.
      • Insert the Management Server public IP address in the IP Address field.

       

    • Deploying a Management Server on-premises

      1. Follow the standard procedure to install an R80.10 Check Point Security Management Server on-premises.

        (refer to R80.10 Documentation - "R80.10 Release Notes" and "R80.10 Installation and Upgrade Guide").
      2. Download and install the latest Auto Provisioning version. See section 6A Downloading and installing the latest Auto Provisioning version.

      3. When completed, proceed to section "(4-B) Create an Azure Active Directory Application and Service principal".

       

  • (4-B) Create an Azure Active Directory Application and Service principal

    In this step, we will be creating an Azure Active Directory Application and Service principal.
    This will be used by the Check Point Security Management Server to monitor the creation and state of the VMSS, so that the Management Server can complete the provisioning of these gateways.

    Follow https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal to create an Azure Active Directory Application and Service Principal.

    Use the following parameters:

    Name check-point-autoprovision
    Application Type Web-App / API
    Sign-on URL https://localhost/check-point-autoprovision

    After the application is created, write down the application ID.
    This value will be used later as client_id in section "(4-C) Configure the Check Point Management Server".

    Create an application key. We recommend that you set the key to never expire.
    Write down the key value.
    This value will be used later as client_secret in section "(4-C) Configure the Check Point Management Server".

    Write down the tenant ID (also referred to as directory ID).
    This value will be used later as tenant in section "(4-C) Configure the Check Point Management Server".

    The newly created application needs to be assigned at minimum a Reader role to the following resources:

    • The virtual network in which the VMSS is to be deployed
    • The resource group of the VMSS

    We will perform this at a later stage - after the VMSS is deployed.

  • (4-C) Configure the Check Point Management Server

    1. Connect to command line on the Management Server.

    2. Log in to Expert mode.

    3. Run the following command to make sure you have the latest Auto Provisioning version and to view the available Auto Provisioning configuration options:

      autoprov-cfg -h

      Note: Specific help documentation is available for each option you choose. For example, the following command will display the available initialization parameters for Azure and their meaning:

      autoprov-cfg init Azure -h

      If you receive the "autoprov-cfg: command not found" error, install the latest Auto Provisioning version. See section (6-A) Downloading and installing the latest Auto Provisioning version.

    4. Run the following command:

      autoprov-cfg init Azure -mn <MANAGEMENT-NAME> -tn <CONFIGURATION-TEMPLATE-NAME> -otp <SIC-KEY> -ver <VERSION> -po <POLICY-NAME> -cn <CONTROLLER-NAME> -sb <AZURE-SUBSCRIPTION> -at <ACTIVE-DIRECTORY-TENANT-ID> -aci <CLIENT-ID> -acs <CLIENT-SECRET>

      where:

      Placeholder Description
      <MANAGEMENT-NAME> Choose a name to represent the Management server.

      This name will later be used in section 4-D to deploy the Check Point Virtual Machine Scale Set so it will be identified and automatically provisioned by this Check Point Management Server. For example, 'my-management'

      <CONFIGURATION-TEMPLATE-NAME>
      Choose a name to represent the configuration template. Configurations required to automatically provision the Gateways in the Virtual Machine Scale Set, such as what Policy to install and which Blades to enable, will be placed under this template name.

      This name will later be used in section 4-D to deploy the Check Point Virtual Machine Scale Set as a reference to the relevant set of configurations to apply on the set. In this way you can maintain multiple sets of configurations to associate with different Scale Sets managed by this Management server. For example, 'my-configuration-template'

      <SIC-KEY> Choose a random string consisting of at least 8 alphanumeric characters. 
      The SIC key creates trusted connections between gateways, management servers and other Check Point components. Trust is required to install polices on gateways and to send logs between gateways and management servers. Make note of this value since it will later be used in section 4-D to deploy the Auto Scaling Group to establish trust between this Management Server and the Gateways in the Auto Scaling Group.
      Note: this value will be obfuscated in the configuration.
      <VERSION> The gateway version (R77.30 or R80.10)
      <POLICY-NAME> The name of a Policy intended to be installed on the Gateways in the Virtual Machine Scale Set. For example, 'Standard'
      <CONTROLLER-NAME> Choose a name to represent the controller. Configurations required to connect to your Azure environment, such as Azure subscription ID and application ID, will be placed under this controller name. You can maintain different types of controllers to automatically provision different cloud environments using this Management server.

      Should you wish to change the controller credentials or their type, the Azure subscription or application ID, this name will be used to reference the controller in order to modify it.

      For example, 'Azure-Production'

      <AZURE-SUBSCRIPTION> The Azure subscription ID, in which the vSEC Security Gateways are being deployed.
      For example: "98e34f37-ece4-4cdc-97dc-44a074f84aff".
      <ACTIVE-DIRECTORY-TENANT-ID> The Azure active directory tenant id retrieved in section (4-B).
      For example: "7113cebb-911c-4122-aa5c-34db449380f7".
      <CLIENT-ID> The application ID created in section (4-B).
      For example: "82fb1445-f40e-46dc-9cd3-c065e14f132b".
      <CLIENT-SECRET> The application key created in section (4-B).
      Note: this value will be obfuscated in the configuration.

      Notes:
      • Each controller in the configuration must have unique credentials.
      • Run [Expert@HostName:0]# service autoprovision test to verify your configuration.
      • If you receive the "autoprov-cfg: command not found" error, please make sure that you have installed the latest Auto Provisioning version. See section 6A Downloading and installing the latest Auto Provisioning version.
      • Values that replace the placeholders should be quoted as required by the shell used.
    5. To apply the modifications type "yes" when the prompt "Would you like to restart the autoprovision service now?" appears and press Enter.

  • (4-D) Deploy the Check Point Virtual Machine Scale Set

    Deploy the following Azure marketplace solution:
    https://azuremarketplace.microsoft.com/en-us/marketplace/apps/checkpoint.vsec
    (select the "Check Point vSEC Autoscale" software plan).

    The template takes the following parameters:

    Parameter Description
    Scale Set Name The name of the VMSS.
    License The type of the license to use. Choose between:
    • Pay As You Go (Billed Through Azure).
    • Bring Your Own License.
    Credentials The SSH public key or the SSH password for managing the server.
    Initial number of gateways The minimal number of gateways in the VMSS.
    Maximum number of gateways The maximal number of gateways in the VMSS.
    Management Server The name of the Management Server you have chosen in section (4-C) Configure the Check Point Management Server. For example, 'my-management'
    Configuration Template The name of the configuration template you have chosen in section (4-C) Configure the Check Point Management Server. For example, 'my-configuration-template'
    Administrator Email Address An administrator e-mail address to notify on scaling operations,
    such as launching of a new gateway, or a gateway termination.
    Subscription The Azure subscription, into which the VMSS is to be deployed.
    Resource Group The Azure Resource group, into which the VMSS is to be deployed.
    Location The Location, into which the VMSS is to be deployed.
    Network setting A pre-existing virtual network and its subnet, or a name of a new
    virtual network and subnet into which the VMSS should be deployed.
    Virtual Machine Size The size of each VM in the VMSS.
    Storage Account Type The type of the storage account used by the virtual machines in the VMSS.
    SIC Key The SIC key you have chosen in section (4-C) Configure the Check Point Management Server.

    After you deploy the template, you must assign the Azure Active Directory Application created in section "(4-B) Create an Azure Active Directory Application and Service principal" a Reader role, so that the Management Server is able to monitor the creation and termination of Check Point vSEC Security Gateways in the VMSS.

    The Management Server needs to have read access to the resource group created when you deployed the template.

    Follow https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-create-service-principal-portal#assign-application-to-role to assign the application you created in section (4-B) a Reader role.

    This can be achieved by assigning the Reader role to the Active Directory application created in section (4-B) on any of the following objects:

    • The resource group containing the VMSS
    • The subscription containing the VMSS

    If the VMSS was deployed into an existing network and this network is not contained in the VMSS resource group you will also need to allow the management Read access to the network object.

    This can be achieved by assigning the Reader role to the Active Directory application created in section (4-B) on any of the following objects:

    • The network
    • The resource group containing the network
    • The subscription containing the network

    Notes:

    • New provisioned Security Gateways will automatically receive the latest published security policy. In order for existing Security Gateways to get the security policy after manual changes, user must install the policy on the existing Security Gateways.
    • Auto Scaling Security Gateways objects are automatically created and deleted according to environment needs. Therefore, it is not recommended to use those objects explicitly in rules, and it is not recommended to manually edit those objects.
  • (4-E) Set up the external Load Balancer

    In this section, we will be setting up the External (Internet facing) load balancer to receive TCP traffic and distribute it to the pool of Check Point vSEC Security Gateways.

    We recommend that you acquaint yourself with: https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview.

    By default, the template you have deployed creates a load balancer that:

    • Listens on TCP port 80 on a static public IP address.
    • Forwards the received traffic to the pool of Check Point vSEC Security Gateways on TCP port 8081.
    • Uses HTTP health probes on TCP port 8081 to determine the health of the Check Point vSEC Security Gateways. The probes are sent to the '/' URL.

    The load balancer can be set up to listen on additional ports and/or on additional public IP addresses.

    • How to configure the load balancer to listen on additional ports:

      Note: The ports 80, 443, 444, 8082 and 8880 cannot be used.

      In the following example, we will extend the load balancer to also listen on TCP port 443 and forward this traffic to the Check Point vSEC Security Gateways on TCP port 8443.

      1. Go to the Azure portal.

      2. Locate the load balancer.
        Note: The load balancer would be in the resource group you created and its name will end with "-lb".

      3. Add a Health Probe:

        1. Click on Health Probes - click on Add.
        2. Give the health probe a name (e.g., vmss-app-1-tcp-8443).
        3. In the Protocol section, select TCP (Azure does not support HTTPS health probes at this time).
        4. In the Interval, enter a health probe interval value (e.g., 5 seconds).
        5. In the Unhealthy threshold, enter a desired value (e.g., 2).
        6. Click on OK.

        Example:

      4. Add a Load Balancing Rule:

        1. Click on Load Balancing Rules - click on Add.
        2. Give the rule a name (e.g., vmss-app-1-tcp-443).
        3. In the Frontend IP address, select the pre-existing Frontend IP address.
        4. In the Protocol, select TCP.
        5. In the Port, select 443.
        6. In the Backend port, select 8443.
        7. In the Backend pool, select the pre-existing VMSS pool.
        8. In the Health probe, select the health probe you have just created.
        9. Select the desired Session persistence.
        10. Set the desired Idle timeout.
        11. In the Floating IP, select Disabled.
        12. Click on OK.

        Example:

    • How to configure the load balancer to listen on additional public IP addresses:

      Such configuration can be useful if you want the VMSS to secure multiple web applications each with its own public IP address.

      In the following example, we will extend the load balancer to also listen on a second public IP address on TCP port 80 and forward this traffic to the Check Point vSEC Security Gateways on TCP port 8083.

      1. Go to the Azure portal.

      2. Locate the load balancer.
        Note: The load balancer would be in the resource group you created and its name will end with "-lb".

      3. Add a Health Probe:

        1. Click on Health Probes - click on Add.
        2. Give the health probe a name (e.g., vmss-app-2-tcp-8083).
        3. In the Protocol, select HTTP.
        4. In the Port, select 8083.
        5. In the Path, enter a URL (e.g., "/").
        6. In the Interval, enter a health probe interval (e.g., 15 seconds).
        7. In the Unhealthy threshold, enter a desired value (e.g., 2).
        8. Click on OK.

        Example:

      4. Use the Azure portal to allocate a new public IP address.

        Example:

      5. Configure Frontend IP pool:

        1. Go back to the load balancer.
        2. Click on Frontend IP pool - click on Add.
        3. Give the IP pool a name (e.g., vmss-app-2).
        4. Select the public IP address you have just created.
        5. Click on OK.

        Example:

      6. Add a Load Balancing Rule:

        1. Click on Load Balancing Rules - click on Add.
        2. Give the rule a name (e.g., vmss-app-2-tcp-80).
        3. In the Frontend IP address, select the newly created Frontend IP address.
        4. In the Protocol, select TCP.
        5. In the Port, select 80.
        6. In the Backend port, select 8083.
        7. In the Backend pool, select the pre-existing VMSS pool.
        8. In the Health probe, select the health probe you have just created.
        9. Select the desired Session persistence.
        10. Set the desired Idle timeout.
        11. In the Floating IP, select Disabled.
        12. Click on OK.

        Example:

  • (4-F) Set up Firewall and NAT rules

    1. Connect with SmartConsole to Security Management Server / Domain Management Server.

    2. Create a Dynamic Object named LocalGateway.

      Note: Skip this step if a Dynamic Object by that name already exists.

      1. In the Object Browser, click on New... - go to More menu - go to Network Object menu - click on Dynamic Object...:

      2. Enter the name LocalGateway:

    3. For each internal load balancer you have, create a Host object to represent the internal load balancer:

      1. In the Object Browser, click on New... - go to More menu - go to Network Object menu - click on Host...:

      2. Enter a descriptive name (e.g., internal-load-balancer-app-1).

      3. Enter the internal load balancer private IP address.

      Example:

    4. For each internal port you have set up (such as "8081"), create a new TCP service:

      1. In the Object Browser, click on New... - go to More menu - go to Service menu - click on TCP...:

      2. Enter a descriptive name (e.g., http-8081).

      3. In the Protocol, select the applicable protocol (either HTTP, or HTTPS).

      4. In the Port, select Customize and enter the port number (e.g., 8081).

      Example:

    5. For each Azure load balancer rule, create a corresponding Firewall rule with the following values:

      • Source: Any (or any other appropriate value)
      • Destination: LocalGateway
      • Services: The service representing the internal port you created above

      Example:

      No. Name Source Destination VPN Services &
      Applications
      Data Action Track Install On
      1 Web Application #1 * Any LocalGateway * Any http-8081 * Any Accept Full Log * Policy Targets

      Example screenshot:

    6. For each load balancer rule, create an appropriate NAT rule with the following values:

      • Original Source: All_Internet (do not use "Any")
      • Original Destination: LocalGateway
      • Original Services: The service you created above (http-8081)
      • Translated Source: LocalGateway - right-click on the cell and set the NAT Method to Hide
      • Translated Destination: The Host object representing the internal load balancer
      • Translated Service: http (or any service representing the port, on which the internal load balancer is listening)

      Example:

      No. Original
      Source
      Original
      Destination
      Original
      Services
      Translated
      Source
      Translated
      Destination
      Translated
      Services
      Install On
      1 All_Internet LocalGateway http-8081 H LocalGateway S internal-load-balancer-app-1 http * Policy Targets

      Example screenshot:

      The above NAT rule will:

      1. Match any traffic arriving to the vSEC Security Gateway on TCP port 8081.
      2. Translate the destination IP address to the IP address of the internal load balancer.
      3. Translate the destination port to the port, on which the internal load balancer is listening.
      4. Translate the source IP address to match the IP address of the vSEC Security Gateway that handles the connection.
        Using this, returning packets will be routed back to the right vSEC Security Gateway.
    7. If HTTPS Inspection is desired, then follow these steps:

      1. If an outbound CA certificate has not yet been created, then follow these instructions to create one:

        Note: You need an outbound CA certificate even if you are only interested in inbound SSL inspection.

        1. In the SmartConsole, go to MANAGE & SETTINGS application - click on Blades - scroll to the bottom - in the HTTPS Inspection section, click on the Configure in SmartDashboard... link.

        2. In the SmartDashboard, go to HTTPS Inspection tab.

        3. In the left tree, click on Gateways - click on the Create Certificate button - fill the relevant information and click on OK.

        4. In the left tree, click on Policy - edit the default rule - in the Destination column, right-click on the Internet and select Remove - it should now show Any (so that inspection would occur with single-interface gateways).

        5. Save the changes (either click on the diskette icon at the top, or press CTRL+S).

        6. Close the SmartDashboard.

        7. In the SmartConsole, click on the Publish at the top.

      2. Create an HTTPS Inspection rule to inspect SSL traffic belonging to this web application:

        1. Create an HTTPS service, similarly to the way you have created the HTTP service in section (4-F) Set up Firewall and NAT rules, step 4 (select port number 8443).

        2. In the SmartConsole, go to MANAGE & SETTINGS application - click on Blades - scroll to the bottom - in the HTTPS Inspection section, click on the Configure in SmartDashboard... link.

        3. In the SmartDashboard, go to HTTPS Inspection tab.

        4. In the left tree, click on Gateways - click on the Server Certificates button - fill the relevant information and click on OK.

        5. In the left tree, click on Policy and add the following rule:

          • Source: Any
          • Destination: Any (do not use the Internet object).
          • Service: select the HTTPS service you have created in the first step.
          • Action: Inspect
          • Certificate: The certificate you created in the previous step
        6. Save the changes (either click on the diskette icon at the top, or press CTRL+S).

        7. Close the SmartDashboard.

        8. In the SmartConsole, click on the Publish at the top.

      3. Enable HTTPS Inspection as explained in section (6-A) Enabling additional Software Blades.

    8. Publish the changes in the SmartConsole.

    9. Install the security policy on any existing vSEC Security Gateway.

 

(5) Configuring Outbound Protection

The Check Point Virtual Machine Scale Set can also be set up to inspect outbound HTTP/HTTPS traffic.
This can be used to inspect and control traffic of various web clients such as:

  • Servers and containers that require software and image updates from repositories located outside the virtual network.
  • Virtual Desktop environments running inside the virtual network and accessing the Internet.

In the diagram below, web clients in private subnets are configured to use an internal load balancer as their HTTP/HTTPS proxy.
This load balancer is configured to forward TCP connections to the Check Point vSEC Security Gateways VMSS.
Each Check Point vSEC Security Gateway is configured as an HTTP/HTTPS proxy listening on the proxy port.
The vSEC Security Gateway inspects the proxied HTTP/HTTPS connections, and can be used to log the URL.

In addition, the vSEC Security Gateways can (optionally) be set up to perform deep packet inspection of encrypted HTTPS traffic using the HTTPS Inspection feature.
With this feature enabled, the web clients should be set up to trust a CA certificate issued by the Check Point Security Management Server during the HTTPS Inspection configuration.

When you deploy the Check Point solution template, the internal load balancer is created automatically. The internal load balancer would have an automatically assigned named ending with "-proxy" to differentiate it from the external load balancer whose name would end with "-lb". The internal load balancer is set to listen on TCP port 8080 and to forward requests received on this port to the Check Point VMSS. The health of the Check Point VMSS is monitored automatically by probes on TCP port 8080.

In the left diagram, servers are set up to send HTTP/HTTPS requests to an internal load balancer as a proxy on TCP port 8080.
The load balancer acting as a TCP load balancer, distributes these requests between the Check Point vSEC VM Sacle Set.
Each vSEC Security Gateway in the VMSS is set up to act as an HTTP/HTTPS proxy.
The vSEC Security Gateway receiving the request, inspects it, and if allowed sends the request out to the Internet.
The health of the proxy service on each vSEC Security Gateway is monitored by a TCP probe sent periodically by Azure from the well-known address: 168.63.129.16.
Note that the internal load balancer is transparent to the Check Point vSEC Security Gateways allowing the gateways to enforce a security policy based on the IP address of the VM that initiated the requests.

Configuration steps:

  1. Management setup

    Note: It is imperative that access to the proxy port of the vSEC Security Gateways is only available from the subnets, in which clients making the HTTP/HTTPS requests are located. Specifically, you want to prevent access from the Internet to this port. Otherwise, malicious clients on the Internet will be able to bounce off the vSEC Security Gateways to attack 3rd party servers.

    1. The proxy is deployed in the same subnets as the gateways belonging to the VMSS.

      Use the Firewall security policy to limit access to the HTTP/HTTPS proxy port (port 8080) only from these subnets:

      • Create a Group object representing the subnets, in which the VMs making the HTTP/HTTPS requests are located.

      • Create a Host object named AzureHealthChecker with an IP address of 168.63.129.16

      • Assuming you named the Group object WebClients, create the following Firewall security rules:

        Source Destination VPN Services &
        Applications
        Data Action Track Install On

        WebClients

        AzureHealthChecker

        LocalGateway

        * Any HTTP_and_HTTPS_proxy * Any Accept Log * Policy Targets
        * Any * Any * Any HTTP_and_HTTPS_proxy * Any Drop Log * Policy Targets
      • If HTTPS Inspection is desired, then follow these steps (once):

        1. In the SmartConsole, go to MANAGE & SETTINGS application - click on Blades - scroll to the bottom - in the HTTPS Inspection section, click on the Configure in SmartDashboard... link.

        2. In the SmartDashboard, go to HTTPS Inspection tab.

        3. In the left tree, click on Gateways - click on the Create Certificate button - fill the relevant information and click on OK.

        4. In the left tree, click on Policy - edit the default rule - in the Destination column, right-click on the Internet and select Remove - it should now show Any (so that inspection would occur with single-interface gateways).

        5. Save the changes (either click on the diskette icon at the top, or press CTRL+S).

        6. Close the SmartDashboard.

        7. In the SmartConsole, click on the Publish at the top.

        8. Enable HTTPS Inspection as explained in section (6-A) Enabling additional Software Blades.

    2. Continue to set up an Application Control and URL Filtering policy to control the outbound traffic.

    3. Enable the Application Control and URL Filtering blades (refer to section "(6-A) Enabling additional Software Blades) by running the following command:

      autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -appi -uf

      Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen in section (4-C) Configure the Check Point Management Server (e.g. 'my-configuration-template') .

      Note: To enable new blades on existing Security Gateways, you must perform a policy installation.

    4. Add a proxy port by running the following command:

      autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -pp 8080

      Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen in section (4-C) Configure the Check Point Management Server (e.g. 'my-configuration-template').

      Note: To apply these settings on existing Security Gateways, you must perform a policy installation.

    5. In addition, if HTTPS Inspection is desired, then enable it by running the following command:

      autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -hi

      Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen in section (4-C) Configure the Check Point Management Server (e.g. 'my-configuration-template').

      Note: To enable new blades on existing Security Gateways, you must perform a policy installation.


    Notes:
    • If you receive the "autoprov-cfg: command not found" error, please make sure that you have installed the latest Auto Provisioning version. See section 6A Downloading and installing the latest Auto Provisioning version.
    • Values that replace the placeholders should be quoted as required by the shell used.
  2. Web clients setup

    Use the Azure portal to find out the private IP address of the proxy:

    1. Go to the resource group created when you deployed the solution.

    2. Click on the proxy load balancer (its name should end with '-proxy').

    3. In the SETTINGS section, click on the Frontend IP pool.

    4. Write down the (private) IP address.

    Example:

    You should configure your web clients to use the internal load balancer as their HTTP/HTTPS proxy.

    Consult the documentation of your web clients in order to determine how to achieve this.

    Note: While some applications might use the operating system proxy settings, other applications might have application specific proxy configuration.

    If HTTPS Inspection is enabled on the vSEC Security Gateways, you should also configure your web clients to trust the HTTPS Inspection certificate generated by the Check Point Management Server.
    Consult the documentation of the web client to determine how to do that.

    Note: While some applications might use a system wide certificate store to determine trust, other applications might have their own separate configuration.

 

(6) Additional information

  • (6-A) Downloading and installing the latest Auto Provisioning version

    Download and install the following add-on package on the newly created Management Server:

    1. Download the add-on package (it is stored on AWS S3 storage service):

      https://s3.amazonaws.com/chkp-images/autoprovision-addon.tgz
    2. Transfer the downloaded TGZ package to the newly created Management Server (into some directory, e.g., /some_path_to_addon/).

    3. Connect to command line on the Management Server.

    4. Log in to Expert mode.

    5. Unpack the add-on package to the root partition ("/"):

      [Expert@HostName:0]# cd /some_path_to_addon/
      [Expert@HostName:0]# tar zxfC autoprovision-addon.tgz /
      (mind the trailing '/')

    6. On R80 Management Server only: Create the need_dbload file:

      [Expert@HostName:0]# touch $FWDIR/scripts/autoprovision/need_dbload
    7. Register the new "autoprovision" service:

      [Expert@HostName:0]# chkconfig --add autoprovision
  • (6-B) Enabling and disabling Software Blades

    You can enable additional Software Blades, such as IPS, Application Control, URL Filtering, Identity Awareness (for vSEC Controller) and HTTPS Inspection, by running the following command:

    autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -<BLADE>

    To disable a blade, delete it by running the following command:

    autoprov-cfg delete template -tn <CONFIGURATION-TEMPLATE-NAME> -<BLADE>

    Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen in section (4-C) Configure the Check Point Management Server (e.g. 'my-configuration-template'), and <BLADE> according to the following table:

     

    Blade Flag
    HTTPS Inspection  -hi
    Identity Awareness
    -ia
    Application Control
    -appi 
    Intrusion Prevention
    -ips
    URL Filtering
    -uf
    Anti-Bot
    -ab
    Anti-Virus -av

    You can enable multiple blades with a single command, for example:

    autoprov-cfg set template -tn my-configuration-template -ips -uf -hi

    Notes:

    • To enable new blades on existing Security Gateways, you must perform a policy installation.
    • Any other attribute that can be set with the set-simple-gateway R80 Web API as documented in the Management API Reference, can be set using the following command:

      autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -nk <PARAMETER-NAME> <PARAMETER-VALUE>

      Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen in section (4-C) Configure the Check Point Management Server (e.g. 'my-configuration-template'), <PARAMETER-NAME> with the parameter name from the Management API Reference and <PARAMETER-VALUE> with the desired value.
    • If you receive the "autoprov-cfg: command not found" error, please make sure that you have installed the latest Auto Provisioning version. See section (6-A) Downloading and installing the latest Auto Provisioning version.
    • Values that replace the placeholders should be quoted as required by the shell used.
  • (6-C) IPS Geo protection based on "X-Forwarded-For" HTTP header

    The IPS Geo protection can filter and/or log traffic based on the country, from which traffic is arriving. This protection is applied to both the source address of the connection as well as to any IPv4 address present in an "X-Forwarded-For" HTTP header.

    Consider the following use cases:

    • A client located in the imaginary country Dystopia, opens a direct connection to the external load balancer. The load balancer will forward the connection to one of the Check Point vSEC Security Gateways, leaving the source IP address unchanged. The Check Point vSEC Security Gateway's IPS Geo protection will identify that country of origin as Dystopia and could log, or drop the connection, if dictated by the policy.

    • A 2nd client, also located in the imaginary country Dystopia, uses a proxy in the imaginary country Utopia to connect to the external load balancer. The proxy in Utopia will add an "X-Forwarded-For" HTTP header to the connection with the IP address of the client in Dystopia. The load balancer will forward the connection to one of the Check Point vSEC Security Gateways. The Check Point vSEC Security Gateway's IPS Geo protection will identify that country of origin as Dystopia and could log, or drop the connection, if dictated by the policy.

    Notes:

    • The External Load Balancer does not hide the original's client IP address.
    • Note that if an HTTP request goes through multiple proxies or load balancers, the "X-Forwarded-For" HTTP header is expected to contain multiple IP addresses.
    • All IPv4 addresses contained in the "X-Forwarded-For" HTTP header would be inspected by the IPS Geo protection.
    • Any IPv6 address in the "X-Forwarded-For" HTTP header would be ignored.

    In addition, refer to sk115532 - IPS Geo protection based on "X-Forwarded-For" HTTP header in Check Point vSEC for AWS / vSEC for Azure.

  • (6-D) Licensing

    As the number of gateways in the VMSS can grow and shrink over time, it makes most sense to use the Check Point vSEC Security Gateways using the Pay As You Go (PAYG) licensing model.
    Note that currently, this licensing model is offered in specific countries only including: Austria, Australia, Belgium, Bulgaria, Canada, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Ireland, Italy, Latvia, Lichtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Taiwan, United Kingdom, United States.

    You can use this solution template to launch BYOL gateways. For more information about licensing, refer to vSEC Central License Management Utility.

    In addition, note that it is not supported to have a VMSS consisting of a mixture of BYOL and PAYG gateways.

  • (6-E) Testing scale in and scale out events

    When the VMSS is deployed, new Check Point vSEC Security Gateways should be automatically created.
    When the vSEC Security Gateways are created, they will execute the First Time Configuration Wizard.
    This normally takes about 10 minutes to complete, but can depend on the VM size.
    After this is completed, the vSEC Security Gateways should be automatically created on the Check Point Management Server, and a policy should be installed on them.
    Confirm that the vSEC Security Gateways were created, and a policy was installed on them using the SmartConsole.
    You should also confirm that you are receiving logs from these vSEC Security Gateways.

    You can test scale in and scale out events by simulating a high CPU load on the vSEC Security Gateways:

    1. Connect to the vSEC Security Gateways over SSH.

    2. Log in to Expert mode.

    3. Create the following shell script:

      [Expert@HostName:0]# vi /var/tmp/simulate_cpu_load.sh
      
      #!/bin/bash
      ncores="$(cat /proc/cpuinfo | grep vendor_id | wc -l)"
      PIDS=()
      for i in $(seq $ncores)
        do
          taskset ff dd if=/dev/zero of=/dev/null &
          PIDS+=($!)
        done
      echo "Load started"
      read -n1 -r -p "Press any key to stop the load..." key
      kill ${PIDS[@]}
      
      

      This shell script will load the CPUs on the vSEC Security Gateways.

    4. Assign the execute permission to the script:

      [Expert@HostName:0]# chmod u+x /var/tmp/simulate_cpu_load.sh
    5. Execute the script:

      [Expert@HostName:0]# ./var/tmp/simulate_cpu_load.sh
    6. The script will load the vSEC Security Gateways's CPUs (you can confirm this by running the top command). After a period of about 10 minutes, a scale out event should be triggered resulting in a newly provisioned vSEC Security Gateway.

    7. After the vSEC Security Gateway is provisioned, stop the script on the old vSEC Security Gateways by pressing any key.

    8. Confirm that the CPU load on the old vSEC Security Gateway is back to normal (you can confirm this by running the top command).

    9. After a period of about 10 minutes, a scale in event should be triggered resulting in one of the new gateways being deleted.

  • (6-F) Autoscale setting

    Scale in and scale out events are controlled by Azure Autoscale.
    For an overview of Azure AutoScale, see: https://docs.microsoft.com/en-us/azure/monitoring-and-diagnostics/monitoring-overview-autoscale.

    By default the solution sets Azure Autoscale as follows:

    • Add a VM to the VMSS if the average CPU usage across the VMSS (as reported by the Azure host) is above 80% for 5 1-minute intervals.
    • Terminate a VM if the average CPU usage across the VMSS (as reported by the Azure host) is below 60% for 5 1-minute intervals.

    Azure Autoscale would also send an e-mail to the e-mail address provided during deployment during a scale in or scale out event.
    Azure Autoscale will ensure that the number of VMs in the VMSS will stay in the range between the minimum and maximum number of VMs as supplied to the template.

    At the time of writing this article, not all the Azure Autoscale settings are exposed through the Azure main portal.
    If a setting is not available through the main portal, you can modify it either using CLI, or through the Azure resource explorer (https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-manager-resource-explorer).

  • (6-G) Automatic rule placement

    The Auto Provision service creates automatic access (in the network layer) and NAT (in the NAT layer) rules for each gateway for each internal load balancer for each listener port. These rules are added at the top of the layers.

    Sometimes it is preferable to add the rules in a specific place in the policy rather than at the top. This can be achieved by creating a section for these rules in Smart Console, and specifying the section name in the Auto Provisioning configuration. To do so, follow these steps:

    1. In Smart Console, within the desired layer (network layer, NAT layer or both) in the relevant Security Policy, create a new section:
      1. Right click on a rule number, under which you wish to create the section.
      2. Choose Create New Section, click Below.
      3. Name the section. Make note of the name.
    2. Connect to command line on the Management Server.
    3. Log in to Expert mode.
    4. Run the following command:

      autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -secn <SECTION-NAME>

      Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen in section (4-B) Configure the Check Point Management Server (e.g. 'my-configuration-template').

      Replace <SECTION-NAME> with the name of the section you have created in step 1. 

    If the section is specified in the configuration template, but it is not found in the rule base, the rules will be added at the top by default.

    Note: changes such as moving the section in the Security Policy or changing the section name in the Auto Provisioning configuration will affect only newly provisioned Gateways. Rules for existing Gateways will remain where they are. If you wish to apply these changes to all of the Gateways in the Auto Scaling Group, terminate the old Gateways and the Auto Scaling Group will automatically create new Gateways to take their place with the new configuration.

  • (6-H) Troubleshooting

    You can test your configuration by running the following command on the Management Server:

    1. Stop the main auto provision service (recommended):

      [Expert@HostName:0]# service autoprovision stop
    2. Start the test:

      [Expert@HostName:0]# service autoprovision test

      Check the output of this command to verify that your setup is working properly.
    3. Start the main auto provision service (if it was stopped before the test):

      [Expert@HostName:0]# service autoprovision start

    Note that the Security Management Server's clock should be set correctly, preferably using NTP. A synchronized clock is needed in order to make API calls into Azure.

    Review logs created by the autoprovisioning daemon on the Security Management Server - $FWDIR/log/autoprovision.elg* files.

    While the vSEC Security Gateway is running the First Time Configuration Wizard and rebooting, it would be reported in $FWDIR/log/autoprovision.elg file as in state INITIALIZING. Then it should report it is in state ADDING and should eventually transition to state COMPLETE. When a vSEC Security Gateway is terminated, it will go into state DELETING and will then go away.

    Follow https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-monitor-log to check the health probe logs and confirm that the gateways are responding to health probes.

    Note that the health probes would be arriving to the gateways from a special IP address 168.63.129.16 as explained here:
    https://blogs.msdn.microsoft.com/mast/2015/05/18/what-is-the-ip-address-168-63-129-16/

 

(7) Known limitations

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment