Support Center > Search Results > SecureKnowledge Details
CloudGuard Auto Scaling for AWS
Solution

Table of Contents:

  1. Overview
  2. Prerequisites
  3. Background
  4. Configuration
    1. Installing and configuring the Check Point Security Management Server
    2. Creating an External Elastic Load Balancer
    3. Deploying the CloudGuard Auto Scaling group
    4. Attaching the External Elastic Load Balancer to the CloudGuard Auto Scaling group
    5. Adding tags to your Internal Elastic Load Balancer
  5. Additional information
    • Configuring Outbound Protection
    • Multiple external ELBs
    • External ELB with multiple ports
    • Multiple VPCs
    • Enabling inbound HTTPS Inspection
    • Updating the AMI of the Auto Scaling group
    • IPS Geo protection based on "X-Forwarded-For" HTTP header
    • Licensing
    • Testing scale in and scale out events
    • Notifications on scale in and scale out events
    • Automatic rule placement
    • Troubleshooting
    • Cross-Zone Load Balancing
    • Removing a Load Balancer

 

Expand all

 

(1) Overview

Auto Scaling is a service offered by Amazon Web Services (AWS) that helps customers automatically adjust their Amazon EC2 capacity according to the current load.
A typical use case consists of a web application served by multiple web servers that are deployed across multiple Availability Zones.
An Elastic Load Balancer (ELB) would distribute network traffic across this group of web servers.
The Amazon EC2 Auto Scaling service 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 setup 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 how to achieve these goals using Check Point Security Gateways.

 

(2) Prerequisites

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

Vendor Topic
AWS
Check Point

(3) Background

  • Network Diagram

    This diagram depicts an Amazon Virtual Private Cloud (VPC).
    The VPC spans 2 availability zones (Availability Zone 1 and Availability Zone 2).
    Each availability zone has a public subnet and a private subnet.
    An External ELB sends incoming traffic to a Check Point Auto Scaling Group residing on the two public subnets.
    The gateways in the group inspect the traffic and, if policy allows, forward the traffic to an Internal ELB.
    The Internal ELB sends incoming traffic to a group of servers residing on the two private subnets.
    The Check Point Auto Scaling Group is set up to increase or decrease the number of
    Check Point Security Gateways in the group based on AWS Cloud Watch metrics.

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

    Note: Before selecting which ELB to deploy, it is suggested to visit https://aws.amazon.com/elasticloadbalancing/details/#compare.

  • Scale Out

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

    1. Auto Scaling launches one or more new instances of the Check Point 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 gateways have finalized the First Time Configuration Wizard, and then automatically:

    1. Initializes a Secure Internal Communication (SIC) channel with them.
    2. Makes any necessary changes to the Security and Network Address Translation (NAT) policies.
    3. Installs a Security Policy on them.

    After a security policy is installed on these gateways, the external ELB automatically recognizes the newly created gateways as InService and starts forwarding new connections to them.
    The newly created 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 below a preconfigured threshold.
    When a scale in event is triggered, Auto Scaling designates one or more of the gateways as candidates for termination.
    The external ELB stops forwarding new connections to these gateways, and later Auto Scaling terminates them.
    The Check Point Management Server detects that these gateways have been terminated and automatically:

    1. Cleans up any automatically created rules in the Security and Network Address Translation (NAT) policies.
    2. Deletes the gateways from its database.

You should have at least 2 Security Gateways - one in each Availability Zone, for redundancy and availability purposes.


(4) Configuration

It is assumed that the following is already created and configured:

  • A VPC with at least two Availability Zones, each consisting of a public and a private subnet.
  • A workload of servers deployed in the private subnets (possibly part of its own Auto Scaling group).
  • An internal Elastic Load Balancer (ELB) that sends traffic to the workload of servers.

The CloudGuard Auto Scaling configuration consists of the following main steps:

  1. Installing and configuring the Check Point Security Management Server.
  2. Creating an External Elastic Load Balancer.
  3. Deploying the CloudGuard Auto Scaling group.
  4. Attaching the External Elastic Load Balancer to the CloudGuard Auto Scaling group.
  5. Adding tags to your Internal Elastic Load Balancer.

To deploy a web service secured by an Auto Scaling group of Check Point CloudGuard Security Gateways, and automatically complete this configuration, see this AWS Quick Start.

Installing and configuring the Check Point Security Management Server

To install the Check Point Security Management Server, see section Installing Check Point Security Management Server in sk130372.

The Security Management Server should have the following IAM permissions:

  • ec2:DescribeNetworkInterfaces
  • ec2:DescribeSubnets
  • ec2:DescribeInstances
  • elasticloadbalancing:DescribeLoadBalancers
  • elasticloadbalancing:DescribeTags
  • elasticloadbalancing:DescribeListeners
  • elasticloadbalancing:DescribeTargetGroups
  • elasticloadbalancing:DescribeRules
  • elasticloadbalancing:DescribeTargetHealth
  • autoscaling:DescribeAutoScalingGroups

If you deploy the Security Management Server using the CloudFormation template, select Create with read permissions in the IAM role dropdown field to include these permissions in the IAM policy of the IAM role attached to the Management Server.

To configure the Security Management Server to automatically provision newly deployed CloudGuard Security Gateways, see section Automatic Provisioning with Security Management Server in sk130372.

For more information on how to install a Check Point Security Management Server that manages CloudGuard Security Gateways deployed in AWS and its advanced configuration, see sk130372.

Creating an External Elastic Load Balancer

The external ELB will be set up to receive traffic from the Internet and forward it to the pool of CloudGuard Security Gateways.

It is assumed that an internal ELB with the following settings already exists:

  • The internal ELB is in front of a group of internal server instances.
  • The internal ELB is listening on a unique high port (e.g. 8081).

Notes:

  • Classic Load BalancerApplication Load Balancer and Network Load Balancer are supported.
  • The following ports cannot be used: 444, 8082 and 8880. For more information about using ports 80 and 443, see Using Standard Ports on the Internal ELB Listeners.
  • The internal ELB name (as defined in AWS) must follow certain restrictions to ensure that the Security Gateway will be able to resolve it properly. For more details, refer to sk116653.
  • Do not add tags to the ELB with keys starting with x-chkp-.

Create an External ELB in your VPC with the following settings:

  • Listens on a public port (e.g. port 80).
  • Sends traffic to the high port (e.g. port 8081).
  • Deployed in the same subnets where you intend to deploy the CloudGuard Auto Scaling group.
  • Has a Security Group that allows traffic from any source to the public port.
  • Health checks should use the same high port (e.g. 8081).

Using Standard Ports on the Internal ELB Listeners

If you set the internal ELB listeners to listen to protocol HTTP, HTTPS or SSL\TLS on their standard ports, i.e. port 80 for HTTP and port 443 for HTTPS or SSL\TLS, the CloudGuard Security Gateways will automatically expect to receive traffic from a custom high port. The default high ports are 9080 for port 80 and 9443 for port 443.

The NAT and Firewall rules will be automatically configured with the custom high port as the origin port and the standard port as the destination port.

In order to change the default high ports, or to configure multiple internal ELBs to listen to the standard ports, tag the internal ELB as follows:

  • Key: x-chkp-forwarding
  • Value: a space separated list of <PROTOCOL>-<ORIGIN-PORT>-<DESTINATION-PORT> items representing the desired forwarding rules.

    Replace <PROTOCOL> with the desired protocol (TCP, HTTP, HTTPS or SSL), <ORIGIN-PORT> with the port that the external ELB forwards traffic to, and <DESTINATION-PORT> with the internal ELB listener port, e.g. "HTTP-9081-80 HTTPS-9444-443 TCP-9022-22 SSL-9444-443".

This will modify the created NAT and Firewall rules to the selected protocol, origin and destination port.

Notes:
  • Each internal ELB that listens to standard ports must be configured with a unique origin port.
  • The external ELB should forward traffic to the configured protocols and origin ports.


Procedure:

  • Show/Hide instructions for Classic Load Balancer
    1. Open the Amazon EC2 console.
    2. In the left navigation pane, select Load Balancers.
    3. Click Create Load Balancer.
    4. Select Classic Load Balancer.
    5. Fill in the Load Balancer Port, the Instance Port and select subnets.

      Example: 
    6. Assign Security Groups.

      Example:
    7. Configure Security Settings.

    8. Configure Health Check.

      Example:
    9. Do not add any EC2 instances to the ELB. This will be configured at a later stage through the Auto Scaling group.

      Example:
    10. Review the configuration.

      Example:
  • Show/Hide instructions for Application Load Balancer

    1. Open the Amazon EC2 console.
    2. In the left navigation pane, select Load Balancers.
    3. Click Create Load Balancer.
    4. Select Application Load Balancer.
    5. Fill in the Load Balancer Port and Availability Zones.

      Example: 


    6. Configure Security Settings.
    7. Configure Security Groups.

      Example:


    8. Configure Routing: fill in the port that the Load Balancer will route traffic to.

      Example: 


    9. Do not register any targets. This will be configured at a later stage through the Auto Scaling group.
    10. Review the configuration.

      Example: 


    Content Based Routing

    Instead of deploying multiple internal ELB to route traffic to multiple applications, it is possible to use Content Based Routing with Application Load Balancer. To do so, follow these steps:

    1. After deploying an Application Load Balancer, open the Amazon EC2 console.
    2. In the left navigation pane, select Load Balancers.
    3. Select the desired Application Load Balancer.
    4. Select the Listeners tab.
    5. Select the listener that routes the traffic to the desired applications.
    6. Click View/edit rules.
      Example:


    7. Select the + icon.
    8. Add the conditions and actions for your applications.
    9. Click Save.
      Example:



    Note: Each listener on the Application Load Balancer has a default rule that cannot be removed and will be applied to any traffic that does not match any other rule.

    Content Based Policy

    In order to protect multiple applications with Content Based Routing, configure Content Based Policy on the Management Server, as described in the following steps:

    1. Verify that the Application Control blade is enabled on the Auto Scaling Security Gateways.
    2. Open SmartConsole.
    3. Select the SECURITY POLICIES tab.
    4. Select the desired policy tab (e.g. Standard).
    5. Right-click Policy tab and click Edit Policy.


    6. Select the + icon on the Access Control pane, and click New Layer....


    7. Name the new policy layer (e.g. Application Control Layer), and tick Applications & URL Filtering.
    8. Click OK twice.


    9. Select the newly created Access Control policy layer.

    For each application, configure an Access Control rule:

    1. Select the Add Rule Above icon.
    2. Configure the rule's Name, Source, Destination, Action and Track.
    3. Select the + icon under the Services & Applications tab.


    4. Select the * icon.
    5. Select Custom Application/Site.
    6. Select Application/Site.


    7. Select a name to the new application (e.g. application1).
    8. Add the application URL to the list. Regular expressions are supported.
    9. Click OK.


    10. Install Policy to apply the new rules to existing gateways (new gateways in the Auto Scaling group will enforce the policy automatically).
      Example:

  • Show/Hide instructions for Network Load Balancer

    1. Open the Amazon EC2 console.
    2. In the left navigation pane, select Load Balancers.
    3. Click Create Load Balancer.
    4. Select Network Load Balancer.
    5. Fill in the Load Balancer Port and Availability Zones.
      Example:


    6. Configure Routing: fill in the port that the Load Balancer will route traffic to.
      Example:


    7. Do not register any targets. This will be configured at a later stage through the Auto Scaling group.
    8. Review the configuration.
      Example:



    Notes:
    • For each internal ELB listener, a Security Policy rule is created. By default, the rule service is a TCP rule. If the traffic is actually HTTP, HTTPS or SSL\TLS, it is recommended to modify the service to be an HTTP, HTTPS or SSL\TLS service. To achieve that, tag the internal ELB with each of the associated listener's ports:
      • HTTP:
        • Key: x-chkp-http-ports
        • Value: a colon separated list of port numbers, e.g. 8081:8083:9081
      • HTTPS:
        • Key: x-chkp-https-ports
        • Value: a colon separated list of port numbers, e.g. 8443:8444:9444
      • SSL\TLS:
        • Key: x-chkp-ssl-ports
        • Value: a colon separated list of port numbers, e.g. 8443:8444:9443

        Notes:

        • To apply IPS Protections for the SSL\TLS protocol, enable the IPS Protections Software Blade on the gateways and configure the desired protections via SmartConsole (SSL\TLS IPS Protections are only supported on R80.20).
        • Traffic arriving at the gateways from load balancers that terminate connections, i.e. Application Load Balancer and Classic Load Balancer Layer 7, originates from the load balancers and inspected as such.
      •  

    • One of the Network Load Balancer key features is preserving the origin's client IP address. Therefore, the automatically added rule will allow traffic from Any source. In order to restrict the traffic that is received from the Network Load Balancer, you can add tags to the internal ELB that will determine the allowed traffic by its source IP address.

      To allow traffic from specific IP addresses or networks according to their CIDRs:
      • Key: x-chkp-source-cidrs
      • Value: a list of white space separated network/mask, from which traffic is allowed, e.g. 1.0.0.0/8 192.168.0.0/16
      Example:

      To allow traffic from a preconfigured SmartConsole object:
      • Key: x-chkp-source-object
      • Value: a single preconfigured SmartConsole object name, from which traffic is allowed, e.g. chkp-allowed-source
        Note: to avoid unexpected behavior, the name of the object must not match the CIDR format.
      Example:



      Important: These tags can only be used with an external Network Load Balancer.
    • The source IP addresses of the clients are preserved and provided to the Check Point Security Gateway, and not to the internal application.

Note:

  • For HTTPS protocol, you should configure the listeners with HTTPS protocol. In addition, the server's SSL Certificate must be provided. In order to enable inbound HTTPS Inspection on the Security Gateways, use the same server certificate on the Security Gateways (refer to section "Enabling inbound HTTPS Inspection").

     

Deploying the CloudGuard Auto Scaling group

First, make sure you are subscribed to the Check Point Security Gateway solution on the AWS marketplace (once per AWS account).

To check if you are already subscribed:

  1. Log in to the AWS portal.

  2. After you have logged in, review your current subscriptions.

If you are not yet subscribed:

  1. Log in to the AWS portal.

  2. After you have logged in, select and subscribe to one of the following licensing options for Check Point CloudGuard IaaS Next Gen Firewall:

    1. R77.30
    2. R80.10
    3. R80.20

Use the following Cloud Formation template to deploy the Check Point Auto Scaling Group:

The template takes the following parameters:

Replace <PASSWORD> with the desired administrator password.

Parameter Description
VPC The ID of your existing VPC (e.g., vpc-0123456789abcdef0), into which to deploy the Security Gateways.
Subnets Select a list of preexisting public subnets in the selected VPC, in which the Security Gateways will be deployed.
Gateways Addresses Either private, or public.

Determines if the Security Gateways are controlled using their private or public address.
Management Server The name of the Security Management Server you have chosen when Setting up Automatic Provisioning.

For example, 'my-management'.
Configuration Template The name of the configuration template you have chosen when Setting up Automatic Provisioning.

For example, 'my-configuration-template'
Name

Optional

AWS Name tag of the Security Gateways.

Instance Type The EC2 instance type for the Security Gateways.
Key Name A public/private key pair, which allows you to connect securely to your instance after it launches.

When you created an AWS account, this is the key pair you created in your preferred region.
Minimum Group Size The minimum number of Security Gateway instances in the Auto Scaling group.
Maximum Group Size The maximum number of Security Gateway instances in the Auto Scaling group.
Email Address

Optional

The email address that notifications about scaling events should be sent to.

Load Balancers An optional comma separated list of Classic Load Balancers names (without spaces), to associate with the Auto Scaling group. If you have created a Classic Load Balancer in the previous step Creating an External Elastic Load Balancer, fill in its name here.
Target Groups An optional comma separated list of Target Groups ARNs (without spaces) to associate with the Auto Scaling group. If you have created a Application or a Network Load Balancer in the previous step Creating an External Elastic Load Balancer, fill in the Target Group ARN here.
Version & license The version and licensing option you have selected above.
Admin Shell

Change the admin shell to enable advanced command line configuration.

Password Hash

Optional

To manage the environment's security, administrators can connect to the Management Server with SmartConsole clients and via the Gaia WebUI.

You can set the administrator password for the Management Server using this field. To protect the administrator password you must provide the password's MD5-based BSD password algorithm 1 salted hash instead of the password itself.

You can pre-generate the password's salted hash with the following command:

openssl passwd -1 -1 <PASSWORD>
SIC Key The SIC key you have chosen when Setting up Automatic Provisioning.
Allow upload & download Set this parameter to No if you don't want to automatically download Software Blade Contracts and other important data. You can improve your experience with the product by sending data to Check Point. Visit the Check Point Cloud Services page for more information.
CloudWatch metrics Select true to report Check Point specific CloudWatch metrics.
Bootstrap Script

Optional

Comma separated commands to run on the initial boot.

Proxy Type

Either none, internal, or internet-facing

Whether to create an ELB acting as an HTTP/HTTPS proxy.

Proxy Port

Optional

The TCP port, on which the proxy would be listening (default is 8080).

Proxy Clients

Optional

The CIDR range of the clients of the proxy.

Notes:

  • Newly provisioned Security Gateways will automatically receive the security policy published most recently. In order for existing Security Gateways to get the security policy after manual changes, manually install the policy on the existing Security Gateways.
  • As scaling events occur, Security Gateways objects are automatically created and deleted. Therefore, it is not recommended to use those objects explicitly in rules, and it is not recommended to manually edit those objects.
  • R80.10 is supported as a Security Gateway, as part of an Auto Scaling group, from AMI version 015.245 and above.

Attaching the External Elastic Load Balancer to the CloudGuard Auto Scaling group

If you have specified a Classic Load Balancer name or a Target Group ARN in the CloudGuard Auto Scaling group CloudFormation template, the load balancer has been attached to your newly deployed CloudGuard Auto Scaling group and you can proceed to section Adding tags to your Internal Elastic Load Balancer.

Otherwise, manually attach the external ELB to the CloudGuard Auto Scaling group.

Show/Hide how to manually attach the external ELB to the CloudGuard Auto Scaling group

  1. Open the Amazon EC2 console.
  2. In the left navigation pane, select Auto Scaling Groups.

  3. Select the CloudGuard Auto Scaling group.

  4. On the Details tab, click the Edit button.

    Example:
  5. Attach the external ELB to the Auto Scaling group:

    • If you have created a Classic Load Balancer, add it to the list of Load Balancers.

      Example: 


    • If you have created an Application or a Network Load Balancer, add the Target Group to the list of the Target Groups of the Auto Scaling group.

      Example:


  6. Click the Save button.

Adding tags to your Internal Elastic Load Balancer

Add AWS tags to the internal ELBs, so that they can be recognized by the Security Management Server. The Management Server will then be able to automatically provision the Security Gateway to forward traffic to these internal ELBs:

  1. Open the Amazon EC2 console.
  2. In the left navigation pane, select Load Balancers.

  3. Select your internal ELB.

  4. On the Tags tab, add the following tags:

    • x-chkp-management
    • x-chkp-template
    • x-chkp-ignore-ports (optional)

    Example:

    Notes:

    • The values for the tags x-chkp-management should match the name of the Management Server (e.g. 'my-management') and x-chkp-template should match the name of the configuration template (e.g. 'my-configuration-template') you have chosen when Setting up Automatic Provisioning.
    • The value for the optional tag x-chkp-ignore-ports should be a colon separated list of Load Balancer ports (frontend ports), which should be ignored.
      That is, traffic on these ports is not expected to go through the gateways in the Auto Scaling group (for example, these ports can serve traffic arriving directly to the ELB from peered networks).
    • The internal ELB Security Group should allow, at minimum, the following traffic from the gateways subnets:
      1. All ICMP traffic 
      2. TCP traffic to the port to which the internal ELB is listening

(5) Additional information

Configuring Outbound Protection

The CloudGuard Auto Scaling group 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 VPC.
  • Virtual Desktop environments running inside the VPC and accessing the Internet.

In the diagram below, web clients in private subnets are configured to use an ELB as their HTTP/HTTPS proxy.
This Proxy ELB is configured to forward TCP connections to the CloudGuard Auto Scaling group.
Each Security Gateway is configured as an HTTP/HTTPS proxy listening on the proxy port.
The gateway inspects the proxied HTTP/HTTPS connections, and can be used to log the URL.

The connections arriving at the Security Gateways have a source IP address belonging to the proxy ELB rather than the web client.
Because the ELB is acting as a TCP proxy and not as an HTTP proxy, no "X-Forwarded-For" HTTP header is present to identify and log the original client.
Instead, the ELB is set up by the CloudFormation Template to add a Proxy Protocol header.
This allows the Security Gateways to log the original client address.

Notes:

  • The proxy protocol is only supported in the context of HTTP/S connections as described here.
  • At the moment, the original client's IP address can only be logged and cannot be used to enforce access rules in the security policy.

Additional information on the subject can be found:

In addition, the gateways can 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 Management Server during the HTTPS inspection configuration.

Configuration steps:

  1. Management setup

    It is imperative that access to the proxy port of the Security Gateways is only available from the internal ELB.
    Specifically, you want to prevent access from the Internet to these ports, otherwise, malicious clients on the Internet will be able to bounce off the gateways to attack 3rd party servers.

    The proxy ELB is normally deployed in the same subnets as the CloudGuard Auto Scaling group.
    Use the firewall rule base in order to limit access to the HTTP/HTTPS proxy ports only from these subnets:

    • Create a group object representing the VPC subnets, in which the gateways are deployed.

    • Assuming you named the group GatewaysSubnets, create the following rules in the firewall security rule base:

      Source Destination VPN Services &
      Applications
      Action Track Install On
      GatewaysSubnets GatewaysSubnets * Any HTTP_and_HTTPS_proxy Accept Log Policy Targets
      * Any GatewaysSubnets * Any HTTP_and_HTTPS_proxy Drop Log Policy Targets

      If outbound HTTPS Inspection is desired, then follow these steps (once):

      1. In the SmartConsole, go to MANAGE & SETTINGS tab - click on Blades - scroll to the bottom - in the HTTPS Inspection section, click on the Configure in SmartConsole... link.
      2. In the SmartConsole, 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 SmartConsole.
      7. In the SmartConsole, click on the Publish at the top.
  2. Enable the Application Control and URL Filtering blades (refer to section Enabling and disabling Software Blades).

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

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

    Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen when Setting up Automatic Provisioning, for example, 'my-configuration-template' and <PROXY-PORT> with the proxy port, for example, '8080'.

  4. If HTTPS Inspection is desired, enable it (refer to section Enabling and disabling Software Blades).

  5. To apply the modifications type "yes" when the prompt "Would you like to restart the autoprovision service now?" appears and press Enter.

  6. CloudFormation template settings

    When you deploy the CloudGuard Auto Scaling group using the CloudFormation template, use the following optional parameters to enable the proxy ELB to act as a forward proxy:

    • Proxy Type: internal
    • Proxy Port (default is 8080).
    • Proxy Clients: either the CIDR range, or the private subnets (where the workload of server resides)
  7. Web clients setup

    Use the AWS management console to determine the DNS name of the proxy ELB.
    You should configure your web clients to use the proxy ELB as their HTTP/HTTPS proxy.
    Consult the documentation of your web clients in order to determine how to achieve this.

    Notes:

    • While some applications might use the operating system proxy settings, other applications might have application specific proxy configuration
    • Systems hosted in EC2, normally require that access to the metadata service on 169.254.169.254 is not directed through a proxy

    If HTTPS Inspection is enabled on the Security Gateways, then you should also configure your web clients to trust the HTTPS Inspection certificate generated by the 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.

Multiple external ELBs

If needed, you can create additional external ELBs that forward traffic to the same pool of CloudGuard Security Gateways.

To do so, for each additional external ELB:

  • Create an additional internal ELB.
  • The external ELB should forwards traffic on the same port, on which the internal ELB is listening.
  • You should allocate unique TCP ports for each such pair (e.g., 8081, 8083, ...).

External ELB with multiple ports

If needed, an external ELB can listen on multiple TCP ports (e.g., 80, 443).

Traffic arriving on these ports can be forwarded on either a single port, or multiple ports.

Consider the following sub cases:

  • Listening on multiple ports (e.g., 80, 443), forwarding on a single port (e.g., 8081).
  • Listening on multiple ports (e.g., 80, 443), forwarding on multiple ports (e.g., 8081, 8443).

In both cases, there should be a corresponding internal ELB.
The internal ELB should be listening on the same set of ports, to which the external ELB is forwarding.
The ports used to forward traffic should be unique.

Multiple VPCs

If needed, the CloudGuard Security Gateways and the internal servers can be placed in different VPCs. To achieve this:

  • Put the internal ELB in the same VPC as the internal servers.
  • Make sure that the Security Gateways can resolve the hostname of the internal ELB.
  • Make sure that there is connectivity from the Security Gateways to the internal ELB by either using VPC peering, or through an Internet Gateway.

Note: Currently, the Network Load Balancer does not support connectivity from clients to your load balancer over AWS managed VPN connections or VPC peering, so the internal ELB cannot be Network Load Balancer. However, it is possible to use an internet-facing Network Load Balancer and route traffic to it over the Internet. For more details, refer to AWS Network Load Balancer Documentation.

 

Enabling inbound HTTPS Inspection

If inbound HTTPS Inspection is desired, then follow these steps:

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

    Important: an outbound CA certificate is required even if you are only interested in inbound SSL inspection.

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

    2. In the SmartConsole, 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. 

      Note: if a certificate has already been created, its details will appear instead of the Create Certificate button.

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

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

  2. Create a new HTTPS service:

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

    2. Select a name (e.g. https-8443).

    3. For Protocol, select HTTPS.

    4. For Port, select Customize and enter the port number (e.g. 8443):

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

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

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

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

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

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

    6. Close the SmartConsole.

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

  4. Enable the HTTPS Inspection blade as explained in section Enabling and disabling Software Blades.

Updating the AMI of the Auto Scaling group

  1. Open the Amazon EC2 console.
  2. In the left navigation pane, select Launch Configurations.
  3. Select the launch configuration of the Auto Scaling group.
  4. Click Actions and then Copy launch configuration.
  5. In the AMI Details section click Edit AMI.
  6. Find the new AMI and click Select.
  7. Verify your configuration in the following screens and create the launch configuration.
  8. In the left navigation pane, choose Auto Scaling Groups.
  9. Select the relevant Auto Scaling group, click Actions and then Edit.
  10. In the Launch Configuration drop-down box, select the newly created launch configuration, named the same as the previous configuration with Copy concatenated to it, and select Save.
  11. To apply this update, manually terminate the Security Gateways, one by one. The Auto Scaling group will deploy new Gateways with the updated AMI instead of the terminated gateways.

Notes:

  • To avoid downtime, make sure to terminate a Security Gateway only after a previous gateway has finished its initialization and replaced its predecessor.
  • The following updates require additional actions:
    • If you have updated from an AMI version earlier than R80.10 take-026.303 to a later version, note that the user data has changed. It is recommended that you copy the user data from the most recent Security Gateway Auto Scaling Group CloudFormation teamplate to the newly created launch configuration copy, in the Advanced Details section under the Configure details tab.
    • If you have changed the Security Gateways version (e.g. from R77.30 to R80.10), update the relevant configuration template in the Auto Provisioning configuration. This can be achieved with the following command:

      autoprov-cfg set template -tn <CONFIGURATION-TEMPLATE-NAME> -ver <NEW-VERSION>

      Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you have chosen when Setting up Automatic Provisioning, (e.g. 'my-configuration-template') and <NEW-VERSION> with the new version of the Gateways.

IPS Geo protection based on "X-Forwarded-For" HTTP header

When the Check Point CloudGuard Auto Scaling group is deployed behind a load balancer, you can log and control the country of origin of the clients as explained in sk115532 - IPS Geo protection based on "X-Forwarded-For" HTTP header in Check Point CloudGuard for AWS / CloudGuard for Azure.

Licensing

As the number of Security Gateways in the Auto Scaling group can grow and shrink over time, the Pay As You Go (PAYG) licensing model makes the most sense.

With the CloudFormation template (refer to section "Deploying the CloudGuard Auto Scaling group"), it is possible to launch Security Gateways based on the Bring Your Own License (BYOL) licensing model.
Refer to CloudGuard IaaS Central License Management Utility for more information on how to install it.

In addition, note that it is not supported to have an Auto Scaling group consisting of a mixture of BYOL and PAYG Security Gateways.

Testing scale in and scale out events

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

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

  1. Connect to the Security Gateways over SSH.

  2. Log in to Expert mode.

  3. Create the following shell script:

    vi /var/tmp/simulate_cpu_load.sh
  4. Paste the following code to the file:

    #!/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 gateways.

  5. Assign the execute permission:

    chmod u+x /var/tmp/simulate_cpu_load.sh
  6. Execute the script:

    ./var/tmp/simulate_cpu_load.sh
  7. The script will load the gateways's CPUs (run top command). After a period of about 10 minutes, a scale out event should be triggered resulting in a newly provisioned Security Gateway.

  8. After the gateway is provisioned, stop the script on the old gateways by pressing any key.

  9. Confirm that the CPU load on the old gateways is back to normal (run top command).

  10. After a period of about 10 minutes, a scale in event should be triggered, terminating one of the existing gateways.

Notifications on scale in and scale out events

The CloudGuard Auto Scaling CloudFormation template takes an email address as a parameter. When the template is deployed, an SNS (Simple Notification Service) topic is created and the email address is subscribed to that topic. Amazon EC2 Auto Scaling sends a notification to this SNS topic whenever a new instance is added or terminated. You can add, remove or change this list of subscribers through the AWS SNS web portal.

Automatic rule placement

The autoprovision service creates automatic access (in the network layer) and NAT (in the NAT policy) rules for each Security Gateway for each internal ELB 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 SmartConsole, and specifying the section name in the automatic provisioning configuration. To do so, follow these steps:

  1. In SmartConsole, 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 Security 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 when Setting up Automatic Provisioning, (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 automatic 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 Security 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.

Troubleshooting

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

  1. Stop the main autoprovision service (recommended):

    service autoprovision stop
  2. Start the test:

    service autoprovision test

    Check the output of this command to verify that your setup is working properly.

  3. Start the main autoprovision service (if it was stopped before the test):

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

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

While the CloudGuard 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 gateway is terminated, it will go into state DELETING and will then go away.

The external ELB should be associated with the Auto Scaling group.
Confirm that the Cloudguard Security Gateways appear on the Instances tab of the external ELB.
Confirm that the Security Gateways Status is reported as InService.
Consult the Health Check setting on the external ELB.

Cross-Zone Load Balancing

ELB supports Cross Zone Load Balancing. With Classic Load Balancer (that was created from AWS Console) and Application Load Balancer, this feature is enabled by default upon creation.
With Network Load Balancer, this feature needs to be manually enabled after the load balancer is created:
  1. Open the Amazon EC2 console.
  2. In the left navigation pane, select Load Balancers.
  3. Select the newly created Network Load Balancer.
  4. Select the Description tab.
  5. Scroll down to Attributes, and click Edit Attributes.
  6. Tick the box next to Cross-Zone Load Balancing.
  7. Click Save.
    Example:


This step is required when one of the load balancers, internal or external, is deployed in more Availability Zones than its targets.

Removing a Load Balancer

If you wish to remove a load balancer from your setup, you can do so by deleting it entirely or removing the x-chkp tags from it. After doing so, please make sure to wait for the autoprovision cycle to be completed (30 seconds by default), before applying any other changes.

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