CloudGuard Auto Scaling For AWS

7/5/2021 CloudGuard Auto Scaling for AWS
Free Demo Contact Us Support Center Blog My Account
PRODUCTS SOLUTION SUPPORT & SERVICES PARTNERS RESOURCES
Support Center > Search Results > SecureKnowledge Details
Search Support Center
CloudGuard Auto Scaling for AWS Technical Level
Rate This Email Print
Solution ID sk112575
Technical Level
Product CloudGuard Network for AWS

Version R77.30, R80, R80.10, R80.20, R80.30, R80.40, R81
OS Gaia
Platform / Model AWS
Date Created 31-Jul-2016
Solution
Table of Contents:
1. Overview
2. Prerequisites
3. Background
4. Configuration
A. Installing and configuring the Check Point Security Management Server
B. Creating an External Elastic Load Balancer
C. Deploying the CloudGuard Auto Scaling group

D. Attaching the External Elastic Load Balancer to the CloudGuard Auto Scaling group
E. Adding tags to your Internal Elastic Load Balancer
5. Additional information
A. Configuring Outbound Protection
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk112575 1/25
g g
B. Multiple external ELBs
C. External ELB with multiple ports
D. Multiple VPCs
E. Enabling inbound HTTPS Inspection
F. Updating the AMI/Version of the Auto Scaling group
G. IPS Geo protection based on "X-Forwarded-For" HTTP header
H. Licensing
I. Testing scale in and scale out events
J. Notifications on scale in and scale out events
K. Automatic rule placement
L. Troubleshooting
M. Cross-Zone Load Balancing
N. 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
Amazon EC2 Auto Scaling
Elastic Load Balancing (ELB)

AWS
Identity and Access Management (IAM)
CloudWatch
Check Point R80.10, R80.20 or R80.30

Check Point
Check Point in AWS
(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:
A. Auto Scaling launches one or more new instances of the Check Point Security Gateway.
B. 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:
A. Initializes a Secure Internal Communication (SIC) channel with them.

B. Makes any necessary changes to the Security and Network Address Translation (NAT) policies.
C. 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:
A. Cleans up any automatically created rules in the Security and Network Address Translation (NAT) policies.
B. 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.

sa g a d co gu g e C ec o Secu y a age e Se e
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 Balancer, Application Load Balancer and Network Load Balancer are supported.
The following ports cannot be used: Ports defined in sk52421 (Ports used by Check Point software), 32768 – 65535 as defined in sk162619 (FWD daemon listening on
multiple random high ports), 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, SSL, UDP or TCP_UDP), <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.
y p , g p
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
Show/Hide instructions for Application Load Balancer
Show/Hide instructions for Network Load Balancer
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:
Bring Your Own License (BYOL) CloudGuard IaaS Next Gen Firewall & Threat Prevention
Pay As You Go (PAYG) Next Gen Firewall & Threat Prevention (NGTP)
Pay As You Go (PAYG) Next Gen Firewall & Advanced Threat Prevention (NGTX)
Click here to deploy Security Gateway Auto Scaling using Cloud FormationTemplate.
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.
Either private, or public.
Gateways
Addresses
Determines if the Security Gateways are controlled using their private or public address.
The name of the Security Management Server you have chosen when Setting up Automatic Provisioning.
Management
Server
For example, 'my-management'.
The name of the configuration template you have chosen when Setting up Automatic Provisioning.
Configuration
Template
For example, 'my-configuration-template'
Optional
Name
AWS Name tag of the Security Gateways.
Instance Type The EC2 instance type for the Security Gateways.
A public/private key pair, which allows you to connect securely to your instance after it launches.
Key Name
When you created an AWS account, this is the key pair you created in your preferred region.
Minimum The minimum number of Security Gateway instances in the Auto Scaling group.
Group Size
Maximum
The maximum number of Security Gateway instances in the Auto Scaling group.
Group Size
Optional
Email Optional
Address The email address that notifications about scaling events should be sent to.
Load 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
Balancers Load Balancer in the previous step Creating an External Elastic Load Balancer, fill in its name here.
Target 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
Groups Network Load Balancer in the previous step Creating an External Elastic Load Balancer, fill in the Target Group ARN here.
Version &
The version and licensing option you have selected above.
license
Admin Shell Change the admin shell to enable advanced command line configuration.
Optional
To manage the environment's security, administrators can connect to the Management Server with SmartConsole clients and via the Gaia WebUI.
Password You can set the administrator password for the Management Server using this field. To protect the administrator password you must provide the
Hash 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 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
& download with the product by sending data to Check Point. Visit the Check Point Cloud Services page for more information.
CloudWatch
Select true to report Check Point specific CloudWatch metrics.
metrics
Bootstrap Optional
Script
Comma separated commands to run on the initial boot.
Either none, internal, or internet-facing

Proxy Type
Whether to create an ELB acting as an HTTP/HTTPS proxy.
Optional
Proxy Port
The TCP port, on which the proxy would be listening (default is 8080).
Optional
Proxy Clients
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
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/UDP traffic to the port to which the internal ELB is listening
(5) Additional information

Note: By default, every Check Point Security Gateway and Security Management Server's WebUI is accessible from the internet by browsing to http://<virtual-machine-
public-ip>. Restricting access to the WebUI is possible by configuring a Network Security Group, or by configuring the Check Point Gateway and Management Server
settings.
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.
Vi t lD kt i t i i id th VPC d i th I t t
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:
The Proxy Protocol: http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt

AWS ELB proxy protocol: http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html
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:
Services &
Source Destination VPN Action Track Install On

Applications
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):
a. 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.
b. In the SmartConsole, go to HTTPS Inspection tab.
c. In the left tree, click on Gateways - click on the Create Certificate button - fill the relevant information and click on OK.
d. 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).
e. Save the changes (either click on the diskette icon at the top, or press CTRL+S).
f. Close the SmartConsole.
g. 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).
To apply the modifications type "yes" when the prompt "Would you like to restart the autoprovision service now?" appears and press Enter.
1. 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)
2. 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.
C lt th d t ti f b li t i d t d t i h t hi thi
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/UDP ports for each such pair (e.g., 8081, 8083, ...).
External ELB with multiple ports
If needed, an external ELB can listen on multiple TCP/UDP 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:
A. 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.
i. 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.
ii. In the SmartConsole, go to HTTPS Inspection tab.
iii. 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.
iv. 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).
v. Save the changes (either click on the diskette icon at the top, or press CTRL+S).
vi. Close the SmartConsole.
vii. In the SmartConsole, click on the Publish at the top.
B. Create a new HTTPS service:
i. In the Object Browser, click on New... - go to More menu - go to Service menu - click on TCP...:
ii. Select a name (e.g. https-8443).
iii. For Protocol, select HTTPS.
iv. For Port, select Customize and enter the port number (e.g. 8443):
C. Create an HTTPS Inspection rule to inspect SSL traffic belonging to this web application:
i. 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.
ii. In the SmartConsole, go to HTTPS Inspection tab.
iii. In the left tree, click on Gateways - click on the Server Certificates button - fill the relevant information and click on OK.
iv. 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
v. Save the changes (either click on the diskette icon at the top, or press CTRL+S).
vi. Close the SmartConsole.
vii. In the SmartConsole, click on the Publish at the top.
D. Enable the HTTPS Inspection blade as explained in section Enabling and disabling Software Blades.
Updating the AMI/Version of the Auto Scaling group
1. If you are changing the Security Gateways version, verify that your existing Management Server can be used with the newer Auto Scaling group version that you are
deploying.
3. In the left navigation pane, select Launch Configurations.

4. Select the launch configuration of the Auto Scaling group.
5. Click Actions and then Copy launch configuration.
6. In the AMI Details section click Edit AMI.
7. Find the new AMI and click Select.
8. Verify your configuration in the following screens and create the launch configuration.
9. In the left navigation pane, choose Auto Scaling Groups.
10. Select the relevant Auto Scaling group, click Actions and then Edit.
11. 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.
12. 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:
Avoid any 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.
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
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) or Pay as You Go (PAYG) licensing models.
For more information on how to install the Bring Your Own License (BYOL), refer to CloudGuard IaaS Central License Management Utility .
For more information on how to install the Bring Your Own License (BYOL), refer to CloudGuard IaaS Central License Management Utility .
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:
/ /t / i l t l d h
./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:

a. Right click on a rule number, under which you wish to create the section.
b. Choose Create New Section, click Below.
c. 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
g g g g p g g p
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 cme stop
2. Start the test:
service cme 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 cme 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:
O C2
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]
Enter your comment here

Comment
SECURE YOUR EVERYTHING ™ Follow Us    

©1994-2021 Check Point Software Technologies Ltd. All rights reserved.
Copyright | Privacy Policy

CloudGuard Auto Scaling For AWS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CloudGuard Auto Scaling For AWS

Uploaded by

Copyright:

Available Formats

7/5/2021 CloudGuard Auto Scaling for AWS

Free Demo Contact Us Support Center Blog My Account

PRODUCTS SOLUTION SUPPORT & SERVICES PARTNERS RESOURCES

Support Center > Search Results > SecureKnowledge Details

Search Support Center

CloudGuard Auto Scaling for AWS Technical Level

Rate This Email Print

Product CloudGuard Network for AWS

C. Deploying the CloudGuard Auto Scaling group

Any security solution used should be as scalable as the setup it is protecting.

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

Amazon EC2 Auto Scaling

Elastic Load Balancing (ELB)

Check Point R80.10, R80.20 or R80.30

This diagram depicts an Amazon Virtual Private Cloud (VPC).

Each availability zone has a public subnet and a private subnet.

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.

When a scale out event is triggered:

A. Initializes a Secure Internal Communication (SIC) channel with them.

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

1. Installing and configuring the Check Point Security Management Server.

Installing and configuring the Check Point Security Management Server

Creating an External Elastic Load Balancer

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

Listens on a public port (e.g. port 80).

Using Standard Ports on the Internal ELB Listeners

Show/Hide instructions for Classic Load Balancer

Show/Hide instructions for Application Load Balancer

Show/Hide instructions for Network Load Balancer

Deploying the CloudGuard Auto Scaling group

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.

The template takes the following parameters:

Replace <PASSWORD> with the desired administrator password.

Either private, or public.

openssl passwd -1 -1 <PASSWORD>

Either none, internal, or internet-facing

Adding tags to your Internal Elastic Load Balancer

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:

(5) Additional information

Configuring Outbound Protection

Additional information on the subject can be found:

The Proxy Protocol: http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt

Source Destination VPN 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):

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

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

1. CloudFormation template settings

Proxy Type: internal

2. Web clients setup

Consult the documentation of the web client to determine how to do that.

Multiple external ELBs

To do so, for each additional external ELB:

Create an additional internal ELB.