Additional Information

Configuring Outbound Protection

There is an option to set up the CloudGuard Auto Scaling Group to inspect outbound HTTP/HTTPS traffic.

Administrators can use this 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 that run inside the VPC and access the Internet.

In the diagram that follows, 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 that listens on the proxy port. The gateway inspects the proxied HTTP/HTTPS connections, and can be used to log the URL.

Connections that arrive at the Security Gateways have a source IP address that belongs to the proxy ELB rather than the web client. Because the ELB acts 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.

Currently, the original client's IP address can only be logged and cannot be used to enforce access rules in the security policy.

For additional information, see AWS ELB proxy protocol.

In addition, you can set up the gateways to do deep packet inspection of encrypted HTTPS traffic with the HTTPS Inspection feature. When this feature is enabled, the web clients must be set up to trust a CA certificate issued by the Management Server during the HTTPS Inspection configuration. See "Creating an Outbound Certificate" section.

Configuration steps:

Security Management setup:

Important - It is necessary to allow access to the Security Gateways' proxy port only from the internal ELB. Specifically, if you want to prevent access from the Internet to these ports. Otherwise, malicious clients on the Internet can 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 to limit access to the HTTP/HTTPS proxy ports only from these subnets:

In SmartConsole, create network object for each subnet in which the gateways are deployed.
Create a network group object that include the VPC subnets from the previous step, e.g. 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

Note - This table regards the Application Load Balancer. If you are using Network Load Balancer, set the source from "GatewaysSubnets" to "WebserverSubnets."

Run the following command on the Security Management to add proxy port:

autoprov_cfg set template -tn < TEMPLATE-NAME> -pp <PROXY-PORT>

Where:
- <TEMPLATE-NAME> - Specifies the name of the Auto scaling Group's template that you selected when setting up Automatic Provisioning.
- <PROXY-PORT > - Specifies the port on which the proxy would be listening.
If you want to use HTTPS Inspection, to enable it see Enabling and disabling Software Blades.

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 must also configure your web clients to trust the HTTPS Inspection certificate generated by the Management Server.

For instructions, see the web client documentation.

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 necessary, 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 must forwards traffic on the same port, on which the internal ELB is listening.
You must allocate unique TCP/UDP ports for each such pair (such as 8081, 8083, and other ports).

External ELB with multiple ports

If necessary, an external ELB can listen on multiple TCP/UDP ports (e.g. 80, 443). Traffic that arrives on these ports can be forwarded on either a single port or multiple ports.

Example sub cases:

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

In both cases, there must be a corresponding internal ELB. The internal ELB must be listening on the same set of ports, to which the external ELB forwards its traffic.

Note - The ports used to forward traffic should be unique

Cross-Zone Load Balancing

ELB supports Cross Zone Load Balancing. With Application Load Balancer, this feature is enabled by default upon creation.

With Network Load Balancer, it is necessary to manually enable this feature, after the Load Balancer is created:

Open the Amazon EC2 console.
From the main menu bar Load Balancers.
Right click on the newly created Network Load Balancer > Edit attributes.
Select the checkbox next to Cross-Zone load balancing.
Click Save.

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

Removing an Elastic Load Balancer

To remove a Load Balancer:

Delete the Load Balancer entirely.

or,
Remove the x-chkp tags from the Load Balancer.

Make sure to wait for the CME cycle to finish (30 seconds by default), before applying any other changes.

Multiple VPCs

If necessary, the CloudGuard Security Gateways and the internal servers can be placed in different VPC's.

To place them in different VPC's:

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.

Enabling inbound HTTPS Inspection

Follow these steps to enable HTTPS Inspection:

Note - An outbound CA certificate is necessary for inbound SSL inspection. If you have an outbound CA certificate you can skip these steps. Otherwise, create one in "Creating an Outbound Certificate".

Creating an Outbound Certificate

To create an Outbound Certificate:

In SmartConsole, from the left navigation panel, select Gateways & Servers.
Right click on one of the CloudGuard Autoscaling Gatways and click Edit.
From the left tree, select HTTPS Inspection.
In Step 1 click on Create to create new certificate, enter the required information and click OK.
In Step 2 you can export the newly created certificate for distributing the CA on client computers.
For more information click on Learn more.
Click OK.
From the left tree, select Security Policies > HTTPS Inspection > Policy.
Go to the Destination column, and edit the default rule.
Right-click Internet > Remove.
Any shows. This means that the inspection takes place with a single-interface gateway.
Publish the SmartConsole session.

Creating an HTTPS Inspection Rule to Inspect SSL Traffic

This procedure creates an HTTPS Inspection rule to inspect SSL traffic that belongs to a web application:

Create a new HTTPS service:
1. In the Right Object Browser, click New > More > Service > TCP.
2. Enter service name, e.g. https-8443.
3. For Protocol, select HTTPS.
4. For Port, select Customize and enter the port number.
Create an HTTPS Inspection rule to inspect SSL traffic belonging to this web application:
1. From the left tree, select Security Policies > HTTPS Inspection > Policy.
2. Add the following rule:
  - Source - Any
  - Destination - Any (do not use the Internet object)
  - Service - The HTTPS service you created
  - Action - Inspect
  - Certificate - The certificate you created
3. Publish the SmartConsole session
Enable the HTTPS Inspection blade as explained in sk130372 > Enabling and disabling Software Blades section.

Using custom Check Point metrics to trigger AWS Auto Scaling events

CloudGuard Security Gateways can report their statistics to the AWS CloudWatch service. For more information, refer to sk108769: Amazon Web Services (AWS) CloudWatch integration.

In order to use metrics in AWS Auto Scaling Groups, Cloud Guard Gateways report their metrics as a group by adding a unique CloudWatch dimension to each metric. The Dimension field allows the user to view CloudGuard metrics in CloudWatch as a group.

It is also possible to use those group metrics to trigger AWS Auto Scaling Group scaling events. In Auto Scaling Group deployment, by default, scaling policies are created based on the AWS EC2 CPU Utilization metric.

There are situations in which different Gateway statistics are required based on custom metrics: The Gateway can report different aspects of performance measuring that might be more relevant to and accurate for the user. For a list of all available custom metrics, refer to sk108769.

In order to properly use Cloud Guard custom metrics in AWS Auto Scaling Groups, do the following:

In AWS CloudWatch Service: Create a new CloudWatch Alarm based on the CloudGuard custom metric.
In AWS EC2 Service: Replace the Auto Scaling Group Scaling Policy to be triggered from the new CloudWatch Alarm.

Create a new CloudWatch Alarm

Note - To create a CloudWatch Alarm, you must have metrics that are already reported by instances. You cannot create an Alarm before the Auto Scaling Group is already deployed and reporting metrics.

Open your AWS CloudWatch Console.
Under Alarms, create a new Alarm.
Choose select metric and select custom namespace Check Point.

Select the AutoScalingGroup dimension.

You should now see all metrics reported by CloudGuard Gateways with the Auto Scaling Group identifier.

Note - CloudGuard Auto Scaling Group identifier combined out of the instances CloudFormation stack name with generated random suffix.

Select the required metric for the alarm and click select metric.
Under Specify metric and conditions, define your threshold and conditions:
- Keep the statistics field on average.
- Use static threshold type.
In the Configure actions section, make sure to remove all actions (scaling actions will be linked from the auto scaling menu).
Add a description for the alarm (unique name and description.)
Preview and create the new alarm.

The new Alarm should appear with its status in the AWS CloudWatch Alarms view.

Configure the Auto Scaling Group in EC2

This section describes how to link the new alarm to an Auto Scaling Group 'scaling policy' instead of to the default scaling policy:

In AWS EC2 console, find and select the required Auto Scaling Group and go to the Scaling policies tab.
Delete all existing Scaling policies to set up the new alarm.
Select Add Policy to create a new Scaling Policy.
Select create a simple scaling policy or create a scaling policy with steps which supports Alarms (refer to the AWS documentation to learn more about types of scaling policies)
Under execute policy when select the new custom Alarm you created in the section above.
Complete the policy name and action to take.
Important - In order to complete the scaling behavior for scale down flows, as well: Repeat the two sections above with an additional Alarm for the state in which the Gateways group should reduce its size and an additional Scaling Policy action defining how to scale down.

Notes -

It is possible to use more than one metric for triggering auto scaling events, however, you should fine-tune your thresholds with great attention to avoid conflicts or loops of Scaling Policies.
You can use CloudWatch Metrics Math to create an additional custom metric composed of two different custom metrics. For more information about Metric Math. refer to Amazon CloudWatch: Using Metric Math.
Warning - Dimension is based on the group IAM Instance Profile. Do not use the Auto Scaling Group IAM Instance Profile for different instances which are not part of the Auto Scaling Group. If a different ASG instance will report metrics with the same Instance Profile ID, this might cause unexpected results such as faulty metrics reporting and undesired scaling events.
EnableCloudWatch parameter must be enabled in the CloudGuard Auto Scaling Group CloudFormation deployment template in order to report statistics.

Updating the Auto Scaling Group

Notes:

Starting 01/01/2023 AWS no longer supports new instance types and features with launch configurations.

If your Auto Scale Group uses Launch Configuration, we recommend replacing it with Launch Template. Refer to Replace launch configuration with launch template section.
If you change the Security Gateway version, make sure you can use the existing Management Server with the newer Auto Scaling Group version you are deploying.

Updating AMI

For Launch Template:
1. Find the target AMI ID:
  1. Open AWS Marketplace and search for CloudGuard.
  2. Select the listing matching the one used to deploy the autoscaling group.
  3. Click Continue to subscribe.
  4. Click Continue to configuration.
  5. Select the target version and build (For example: R81.20-631.1427).
  6. Select the region of your autoscaling group.
  7. Copy the AMI ID.
2. Update the autoscaling group launch template:
  1. Open the Amazon EC2 console.
  2. From the main menu bar select Launch Templates and select the launch template of the Auto Scaling Group.
  3. Click Actions > Modify template (Create new version).
  4. In Auto Scaling Guidance Check Provide guidance to help me set up a template that I can use with EC2 Auto Scaling.
  5. Go to Application and OS Images (Amazon machine image) and click Browse more AMIs.
    1. In the search box enter the AMI-ID (“ami-xxxxxxxxxxxxxxxxx”) copied in step #1.
    2. Click the Community AMIs tab.
    3. Click the Select button next to the AMI matching the AMI-ID you pasted in the search bar.
    4. If you get the alert: Some of your current settings will be changed or removed if you proceed, review the changes and Confirm if you agree.
  6. In Network settings section mark Select existing security group.
  7. Examine your configuration in all other sections and create the launch template version.
3. From the Navigation Toolbar, select Auto Scaling Groups.
4. Select the applicable Auto Scaling Group, click Edit.
5. In the Launch Template section, select the new version and select Update.
6. To apply this update, manually stop the Security Gateways one by one. The Auto Scaling Group deploys new Gateways with the updated AMI and not with the terminated gateways.
For Launch Configuration:
1. Open the Amazon EC2 console.
2. From the Primary menu bar, select Launch Configurations and select the launch configuration of the Auto Scaling Group.
3. Click Actions > Copy launch configuration.
4. Go to Amazon machine image (AMI) and select the new AMI.
  
  Follow these steps to find the desired AMI id:
  1. Open the AWS Marketplace.
  2. Search for Check Point and click on the relevant product listing.
  3. Click Continue to Subscribe.
  4. Click Continue to Configuration.
  5. Select the relevant Software Version and Region.
  6. Copy the Ami Id.
5. Examine your configuration in all other sections and create the launch configuration.
6. From the Navigation Toolbar, select Auto Scaling Groups.
7. Select the applicable Auto Scaling Group, click Edit.
8. In the Launch Configuration section, select the newly created launch configuration, named the same as the previous configuration with Copy concatenated to it, and select Update.
9. To apply this update, manually stop the Security Gateways one by one. The Auto Scaling Group deploys new Gateways with the updated AMI and not with the terminated gateways.

Notes -

Avoid other configuration changes during the upgrade.

To avoid downtime, make sure to terminate a Security Gateway only after a previous gateway has finished its initialization and replaced its predecessor.

These updates necessitate additional actions:

If you have changed the Security Gateways version, update the relevant configuration template in the Auto Provisioning configuration. Use this command:

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

Replace <CONFIGURATION-TEMPLATE-NAME> with the name of the configuration template you selected when Setting up Automatic Provisioning, such as 'my-configuration-template', and <NEW-VERSION> with the new version of the Gateways.

Replace launch configuration with launch template

Copy a launch configuration to a launch template:
1. Open the Amazon EC2 console.
2. On the navigation pane below Auto Scaling, select Launch Configurations.
3. Select the launch configuration you want to copy and select Copy to launch template > Copy selected. It creates a new launch template with the same name and options as your selected launch configuration.
4. For New launch template name, you can use the name of the launch configuration (the default) or enter a new name. Launch template names must be unique.
5. Select Copy.
Replace the launch configuration for an Auto Scaling Group:
1. Open the Amazon EC2 console, and select Auto Scaling Groups from the navigation pane.
2. Select the check box next to your Auto Scaling Group.
  
  A pane opens at the bottom of the page, showing information about the selected group.
3. On the Details tab, select Launch configuration, Edit.
4. Select Switch to launch template.
5. For Launch template, select your launch template.
6. For Version, select the launch template version, as needed. After you create versions of a launch template, you can select if the Auto Scaling Group uses the default or the latest version of the launch template when scaling out.
7. When you have finished, select Update.

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.

Testing Scale In and Scale Out Events

When the Auto Scaling Group is deployed, new Check Point gateways must be automatically created. When the gateways are created in AWS, they execute the First Time Configuration Wizard. This normally takes about 10 minutes to finish, but can depend on the instance type.

After this finishes, the gateways must be automatically created in the Management Server, and a policy must be installed on them. Make sure that the gateways were created, and a policy was installed on them using SmartConsole. In addition, check that you receive logs from these gateways.

To test scale in and scale out events, simulate a high CPU load on the gateways:

Connect to the Security Gateways over SSH.
Log in to the Expert mode.
Create this shell script:

vi /var/tmp/simulate_cpu_load.sh

Copy and paste this code to the file:

Copy

#!/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 loads the CPUs on the gateways.

Assign the execute permission:

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

/var/tmp/simulate_cpu_load.sh

The script loads the gateways' CPUs (run top command). After a period of about 10 minutes, a scale out event should be triggered that results in a newly provisioned Security Gateway.
After the gateway is provisioned, stop the script on the old gateways by clicking any key.
Confirm that the CPU load on the old gateways is back to normal (run top command).
After a period of about 10 minutes, a scale in event should be triggered that terminates 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 Cloud Management Extension (CME) 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. To do this, create, a section for these rules in SmartConsole, and specifying the section name in the automatic provisioning configuration.

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 Title and click Below.
3. Name the section. Make note of the name.

Use SSH to connect to the Security Management Server.
Log in to Expert mode.
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 selected when Setting up Automatic Provisioning, e.g. 'my-configuration-template'.

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

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

For more information, see the Automatic Rule Placement section in the Cloud Management Extension R80.10 and Higher Administration Guide.

Note - Changes such as moving the section in the Security Policy or changing the section name in the automatic provisioning configuration impact only newly provisioned Gateways. Rules for existing Gateways remain in place. If you want to apply these changes to all of the Security Gateways in the Auto Scaling Group, then terminate the old gateways and the Auto Scaling Group automatically create new gateways to take their place with the new configuration.

Licensing

With the CloudFormation template (refer to section Step 5: Deploying the CloudGuard Auto Scaling Group), it is possible to launch Security Gateways based on the Bring Your Own License (BYOL) or Pay as You Go (PAYG) licensing models.

For more information on how to install the Bring Your Own License (BYOL), see the CloudGuard IaaS Central License Management Utility.

Important - Auto Scaling Group with a mixture of BYOL and PAYG Security Gateways is not supported.