Word Template - community.checkpoint.com · Web viewAuto Scaling CloudGuard (VSEC) Gateways in MS Azure using Scale Sets and testing (scale out and in) Lab Environment: In this

Auto Scaling CloudGuard (VSEC) Gateways in MS Azure using Scale Sets and testing (scale out and in)

Lab Environment:

In this guide, we will see how “Azure Autoscale” increases or decreases CloudGuard (VSEC) virtual security gateways in a VM Scale Set, depending on network traffic load distributed by the external load balancer. The gateways will then inspect incoming traffic from the internet which will be forwarded to the internal load balancer distributing traffic across a group of web servers which will also be scalable depending on traffic in the internal subnet.

©2018 Check Point Software Technologies Ltd. All rights reserved | P. 1

TABLE OF CONTENTS:

1. Create a Virtual Network (VNET) with public (frontend) and private (backend) subnets.

2. Deploy Check Point Management Server in Azure

3. Create CloudGuard Controller through Azure AD Application and Service Principal (Virtual Gateway auto provisioning)

4. Configuring Management Server with CloudGuard Controller (Gateway Auto Provisioning API)

5. Deploying Check Point CloudGuard Virtual Machines Scale Sets (VMSS)

6. External Load Balancer Configuration (load balancing and health probes)

7. Deploying basic Nginx web server in private subnet.

8. Internal Load Balancer Configuration.

9. Firewall and NAT rules

10. CloudGuard Virtual Machines Auto Scaling testing


EXERCISE 1: Create a Virtual Network (VNET) with Frontend and Backend subnets

- Open Azure Portal on https://portal.azure.com, follow steps 1-8 as shown below

- Name: VMSS_VNET.- Address space is 10.0.0.0/16- Create a resource group: VMSS_VNET- If you’re using a subscription with Visual Studio Credits use one of the

following locations, whichever is the closest: East US, South Central US, West Europe, Southeast Asia, West US 2, West Central US


https://portal.azure.com/

- Location: East US- Create your Frontend Subnet as shown in step 7 and ensure it’s CIDR is

10.0.0.0/24 - After completing step 9, you can monitor deployment process by clicking

on the bell icon as shown below

- Once the VNET deployment is successful, let’s create a backend subnet.


- Name: BackEnd- Address space: 10.0.1.0/24- NSG (network security group) which are basic firewall (ACL) rules at the VNET

and VM level. Leave empty since we will use CloudGuard gateways later. - Route Table: leave empty

- Click OK

This concludes Exercise 1.


Exercise 2: Deploying a Check Point Management Server in Azure


- Name: CPMgmt- Select password as authentication type and enter your password- Create a new resource group for your Management Server: rg_CPMgmt - Location: East US- Click OK, when you’re done


- Check Point CloudGuard (VSEC) version= R80.10- License Type = Select BYOL- VM size = leave as recommended (1xStandard D3 v2)- Allowed GUI clients= 0.0.0.0/0 (for demo purposes)- Click OK when you’re done

Follow steps 1-4 for the Management Server network settingsClick OK once you’re done


Next, Azure will validate your settings and click OK again for deployment.

Once the management Server (CPMgmt) is successfully deployed go to:


Home-> Resource Groups--> rg_Mgmt-->CPMgmt Notice the management server’s public IP address. To access web UI, type from your web browser. https:// ”CPMgmt Public IP”

Install the latest Jumbo Hotfix Take and HFAs.

This concludes Exercise 2


Exercise 3: Create an Azure AD Application and Service Principal//

This service will be used by CPMgmt (management server) created in exercise 2 to monitor the automatic creation, the state, and complete the provisioning of newly provisioned security gateways in our VMSS (Virtual machine scale set).

Whenever Azure Autoscaling deploys additional CloudGuard (VSEC) gateway instance(s) (example due to high CPU load, unhealthy virtual gateways, or failure of any sort) the management server CPMgmt will automatically detect the creation of new instances, initialize a SIC communication and install security policy on them.

- Select Azure Active Directory --> App Registrations --> New application registration.

- In the next step, you will be prompted to enter the details below- Once you’re done click OK


- Enter App Name: check-point-autoprovision- In the Sign-on URL field ensure you enter “https://localhost/check-point-

autoprovision”- Wait for the Web App/API to be deployed successfully. Once deployment is

completed, populate application information following steps belowAzure Active Directory -> App Registrations --> Select All apps --> click on the Web app/API you just created.


In the next menu, write down “Application ID” (client ID), we will use it for the management server configuration.

- Create a key for your web app/API you just created. Select Settings--->keys.


- Set your key to never expire and click Save. Write down the key value as you will not be able to retrieve it later. We will use it later for CPMgmt server configuration

Now we need to assign our newly created web app/API a “reader” role at minimum to either the subscription or the resource group containing the VM Scale Set. This will allow our management server “CPMgmt” to monitor the creation and termination of VSEC security gateways in the VMSS. To assign a role we will use Azure Access Control IAM (Identity Access Management) service.


- Select Subscriptions --> Visual Studio Professional --> Access Control (IAM) -->

- click on “+ Add” --> Select “reader” role --> select webapp/API name


Last parameter needed for CPMgmt server configuration is our Directory ID (tenant ID):

- Select Azure Active Directory --> Properties --> and write down Directory ID (tenant ID), we’ll use it to configure CPMgmt server.

To recap, we have our Application ID (client ID), Directory ID (tenant ID), and application key all written down, also we have assigned a “reader” role to the webapp/API application. We are now ready to configure CPMgmt server.

This concludes Exercise 3


Exercise 4 – Configure CPMgmt server with our Gateway_Auto_Provisioning API

- Connect to CPMgmt using “ssh” client such as putty - Log into Expert Mode and run the command “autoprov-cfg -h”

We will use the “init” argument of the autoprov-cfg command to create our controller template.

- Run “autoprov-cfg init Azure –h” to review the required placeholders.


Note that placeholders should be replaced by quotation marks when running the command

Example: autoprov-cfg init Azure -mn "CPMgmt" -tn "template_name" -otp "your_SIC" -ver "R80.10" -po "your_policy_name" -cn "VsecController" -sb "Your_Azure_Subscription" -at "TenantID" -aci "ClientID" -acs "webapp/API_Key"

Yellow flags must match existing predefined values in exercise 2 and 3. Refer to exercise 3 for the values of the following flags (–at, -aci, -acs).Your Azure subscription ID which can be found under Home-->Subscriptions

An Example of the fully entered command with required flags shown below:


When prompted to restart autoprovision service, type Y + Enter- To test autoprovision service, run command, service autoprovision test.

The expected outcome should say “All tests passed successfully”


Useful autoprov-cfg commands:“autoprov-cfg show all”, to view your controller template configuration

“autoprov-cfg set –h” to either change management or templates arguments, or controller configuration settings.Example: autoprov-cfg set management –h; autoprov-cfg set template –h; autoprov-cfg set controller -h

Important: Values of required flags are case sensitive. Your command may work however you won’t get the expected outcome in exercise 5.



Exercise 5: Deploying Check Point CloudGuard Gateways Virtual Machine Scale Set (VMSS)

From Azure portal home page, select create a new resource--> Check Point CloudGuard IaaS Autoscale --> Create

In the next page you will be prompted to enter CloudGuard Auto scale basic configuration details:

a. Gateway Scale set name : VsecVMSSb. Select password as authentication type, enter your passwordc. Configure Initial and maximum number of gatewaysd. Management name= CPMgmte. Policy template name (we must enter the value of the -tn flag in the API

autoprov-cfg command, during CPMgmt configuration in exercise 3)f. Create a new resource group: rg_VsecVMSSg. Location: US East


Important: (5 and 6)Management Name and Policy template name must match the values entered in the webapp/API application settings while creating the AD and Service principal and configuring the API with management server with autoprovision-cfg command in exercise 3 and 4.

In the CloudGuard (VSEC) Settings, we must ensure the version and SIC key match what was defined in the autoprovision configuration while running API autoprovision-cfg command in exercise 4.


For Network Settings, Select VMSS_VNET and assign Scale set to the FrontEnd subnet. Once this step completed, Azure will validate the settings, then click OK to deploy Scale set


Newly provisioned gateways in CloudGuard Scale Set will automatically establish SIC with CPMgmt and receive the latest published security policy via our controller (Web_API) which at this stage should be the cleanup rule.

Reminder: Once Vsec VMSS (VM Scale Set) is deployed, and for the autoprovision service to work we must ensure that:

- “Reader Role” has already been assigned to our WebApp_API created as shown in exercise 3.

- The newly deployed VMSS should be part an existing VNET (Demo_VNET) and a dedicated resource group (rg_VsecVMSS)

In case it doesn’t work, review exercise 4; ensure you’ve entered the correct values for the required flags for the autoprov-cfg command.

This concludes exercise 5.


Exercise 6: Configuring the External Load Balancer

By default, VsecVMSS template deployed in exercise 4 creates an external load balancer (VsecVMSS-lb) listening on port 80 on a static public IP. The external load balancer then, forwards all received HTTP traffic to the CloudGuard (Vsec) gateways of the VMSS listening on port 8081. The external load balancer also performs health checks on VSEC gateways on port 8081 to the “/” URL.

a. Select Load balancers --> VsecVMS-lb --> Health Probes --> VsecVMSS-app-1


Name: VsecVMSS-app-1Port: 8081Path: /Interval: 5Unhealthy Threshold: 2Click “Save”

b. Select Load Balancers --> VsecVMSS-lb --> Load Balancing Rules --> VsecVMSS-app-1


Name: VsecVMSS-app-1Port: 80Backend Port: 8081Backend Pool: VsecVMSS-poolHealth Probe: VsecVMSS-app-1(HTTP:8081)Leave everything else as it is.Click “Save”



Exercise 7: Deploying Nginx Web Server in our private subnet

In the topology described in the introduction, our private subnet is constituted of a web server scale set. For simplicity and demo purposes, we will instead deploy a basic Nginx web server in our private subnet.

a. Click “Create a resource” ---> type “Nginx Certified by Bitnami” ---> “create”

b. Name: MywebserverVM disk type: HDDUsername: webadminAuthentication type: Password --> Enter your passwordResource Group: Create new --> rg_webserverLocation: East US


c. Select VM size

d. Network SettingsAvailability set= noneNetwork= VMSS_VNETSubnet= BackendPublic IP= NoneNetwork Security Group= None(Leave everything else as it is)

Once validation is passed, click on “create”This concludes exercise 7.


Exercise 8: Configuring Internal Load Balancer

In this exercise, we will create an internal load balancer in our BackEnd subnet, and then assign our webserver created in exercise 7 in the load balancer backend pool of virtual machines.Finally, we will test internet connectivity to our webserver and analyze logs.

Select “Load Balancers” ---> “Add”Name: Internal_LBType: InternalSKU: BasicVirtual Network = VMSS_VNETSubnet= BackEndIP address assignment: StaticPrivate IP= 10.0.1.5Resource Group= Use existing --> rg_webserver

Once the internal load balancer has been created, next step will be configuring its backend pool of instances, health probe and load balancing rules.


a. Select “load balancers” --> “Internal_LB” --> “Backend pools” --> “Add”

b. On the next screen enter the followingName= Webserver_VMsAssociated to = single virtual machineTarget virtual machine = mywebserverNetwork IP Configuration= ipconfig (10.0.1.6) from the dropdown.


c. Select “Load Balancers’ --> “Internal_LB” --> “Health Probes” --> “Add”

Name: Webserver_HealthProtocol: HTTPPort: 80Path: /Interval: 5Unhealthy Threshold: 2Click “Save”


d. “Load Balancers” --> “Internal_LB” --> “Load Balancing Rules” --> “Add”

Name: Webserver-tcp-80Frontend IP address: 10.0.1.5Protocol: TCPPort: 80Backend Port: 80Backend Pool: Webserver_VMsHealth Probe: Webserver_Health (HTTP:80)


Exercise 9: Configuring Firewall and NAT Rules

In this exercise we will create a dynamic gateway object (given that CloudGuard gateways will be scaling out and in), internal load balancer host objects, TCP service objects (for port 8081 used in the external load balancers); then create firewall and NAT rules to inspect and redirect incoming HTTP traffic.

Connect to Check Point Smart Console

- Create a “LocalGatewayExternal” object for our dynamic gatewaysNote: “LocalGatewayExternal” dynamic gateway object applies for 2 vCPU gateways and above (see highlight). 1 vCPU virtual machines dynamic gateway objects remain “Localgateway”

In exercise 5 completed earlier, we deployed D3v2 virtual machines for our VMSS.


The dynamic object name can be obtained by running the commands below from any running virtual security gateway. (Ensure you create a rule allowing ssh connections from CPMgmt to dynamic gateway object)

- Create an Internal Load Balancer object. In exercise 8, we assigned an IP address which is 10.0.1.5 to the Internal Load Balancer.



- Create a TCP service object for HTTP-8081

- Create firewall and NAT rules


Ensure you change the Translated source: LocalGatewayExternal to “Hide NAT”

Firewall rule# 3 allows all incoming HTTP requests forwarded to the external load balancer to our any available virtual gateway part of our VMSS on ports 8081.

NAT rule# 1 will redirect all incoming internet traffic hitting the virtual gateways to the internal load balancer which will then distribute the load between the virtual machines sitting in the backend pool.NB: Use Hide NAT in “Translated Source” field for the dynamic gateway object

- Testing connectivity of our webserver to the internet Locate your external load balancer public IP address under: “Load Balancers --> VsecVMSS-lb --> Overview


Enter http://your_external_load_balancer_public_IP in your web browser

You can also analyze logs, by double clicking on either one.


http://your_external_load_balancer_public_IP/

This concludes exercise 9.


Exercise 10: Auto Scaling Testing (CPU stress tests)

In this exercise we will run a script simulating a high CPU load on our virtual gateways, which will force the deployment of a new Virtual gateway. Also, our autoprovision service will then establish SIC and push policy on the newly provisioned Gateway using the autoprov-cfg service.

Note: CPU stress tests take an average of 7-10 minutes for the auto scale of CloudGuard gateway to take effect. This is mainly because; newly provisioned virtual gateways go through First Time Wizard. Blink Gaia Fast deployment is currently been tested to be included to the VMSS deployment templates.

For demo purposes, we suggest to change Azure Scaling parameters to reflect information as shown below:Resources groups --> rg_VSecVMSS --> Scaling

Scale Out = Average CPU > 30% Increase instance count by 1Scale In = Average CPU < 50% Decrease instance count by 1


a- Connect to your virtual security gateways/ 10.0.0.6-7 in Expert Mode from CPMgmt using Putty

b- Create a script called simulate_cpu_load.sh in the var/tmp directory

Copy-Paste script below in the /var/tmp/simulate_cpu_load.sh file

#!/bin/bashncores="$(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+=($!) doneecho "Load started"read -n1 -r -p "Press any key to stop the load..." keykill ${PIDS[@]}


Assign the execute permission to simulate_cpu_load.sh script

c- Repeat the same for the other virtual gateway 10.0.0.7

d- Run script on both virtual gateways

The script will load our virtual gateways CPU to 100%.

If you provided an email for auto scale alerts, next step you should receive an email similar to the one below


e- In your Azure Account, we can verify gateways auto scaling status by looking at the number of instances in your VSecVMSS.

“Home” --> “Resource groups” -> “rg_VsecVMSS” --> “Instances”

Important: It may take between 5-7 minutes for the new virtual gateway to be deployed and our API (controller) to communicate with Azure subscription to fetch changes in Azure, establish SIC and push policy. To reduce wait times, especially for demo purposes it is possible to tweak Azure Auto Scaling


parameters (load balancers health probes intervals, CPU usage minimum value to scale out/in, etc.…), as well as reducing poll wait times using the autoprov-cfg command.

f- Scale out output in Smart Console --> Gateways and Servers should look similar than image below

Notice that the auto provision service took over. It established SIC and installed the policy on new virtual gateway. This process was completely hands-off


g- Press any key on either virtual gateway putty session to stop script

You should receive an email alert about our VsecVMSS scaling down from 3 to 2 CloudGuard virtual machines.

And automatically our VsecVMSS will shrink back to its minimum number of instances, which in this exercise was defined as 2 virtual machines.

This concludes exercise 10 and our lab.


Documents

Word Template - community.checkpoint.com · Web viewAuto Scaling CloudGuard (VSEC) Gateways in MS Azure using Scale Sets and testing (scale out and in) Lab Environment: In this