Ultimate Guide to Azure VMSS CloudGuard

• What is CloudGuard VMSS?
• How to create VMSS CloudGuard scaling group in MS Azure
• How to configure Azure Service Principals
• How to set a Security Management Server in the cloud
• How to configure Cloud Management Extension (CME)
• How to download SmartConsole and login to the management.
• How to configure vSEC Controller
• How to manage vSEC Central License

Introduction to CloudGuard VMSS

CloudGuard is an IaaS (Infrastructure as a Service) security solution based on CheckPoint firewall technology made primarily to secure public and private cloud environments and it’s compatible with various vendors and cloud providers. CloudGuard (formerly known as vSEC) delivers the same multi-layered threat prevention capabilities known from CheckPoint appliances like Firewall, IPS, Application Control, Antivirus, Anti-Bot and SandBlast to any cloud-based deployment. This guide focuses on Microsoft Azure and its VMSS (Virtual Machine Scale Sets) implementation.

Virtual Machine Scale Sets (VMSS) are an Azure autoscaling solution that can be used to deploy and manage sets of identical virtual machines and automatically increase or decrease their number based on the current needs. This means your infrastructure grows and shrinks together with your realtime application workload. Look at the drawing below to get a better overview.

Creating Check Point CloudGuard scaling group

The first thing to do is to log in to your Azure account and create a new resource. Search for CloudGuard Iaas or simply Check Point.

• 

Choose a Scale Set and Create.

• 

Fill in all the important details into the template starting with gateway scale set name. Its hardly recommended creating a new resource group only for the VMSS scale set.

• 

Here are some of the most important settings that are not easy to change but crucial to VMSS behavior. Choose wisely. Management name and Configuration template name are related to Cloud Management Extension (CME), former Auto Provisioning Service and will be needed later so write them down. To learn about load balancers deployment methods go here.

It is extremely important to have a continuous connection between Management and Gateways and you need to plan it before going any further.

• Backend NIC’s private IP address – a good option if you have Management in Azure or you use VPN or ExpressRoute to connect your on-premises Management to Virtual Networks in Azure (we will use a VPN for the matter of this guide)
• Frontend NIC’s private IP address – if you want to connect your gateways over the Internet using Public IP address attached to Frontend NIC’s. If you go with this option choose Yes under Deploy the VMSS with Instance level Public IP address.

• 

Choose version which should run on your gateways but don’t choose versions higher than your management. At least check compatibility before doing so. License types:

• Bring Your Own License (BYOL) – you need to have a license provided by Check Point attached to your gateways or management. You have 15 days of a trial if you go with this type of license.
• Pay As You Go (NGTP) – Next Generation Threat Prevention basic license
• Pay As You Go (NGTX) – Next Generation Threat Extraction & SandBlast license with Threat Emulation and Threat Extraction

SIC Key is a secret key that is used to establish the initial trust between Check Point components. You can read more here. It’s a one-time password.

• 

Configure your networking settings up to your needs. I stick with default subnets.

• 

• 

At this point, you should be seeing the summary. It can take a while before your newly created template will be validated but in the meantime, please review it very carefully. You can also download the template in JSON to Notepad++ if you wish. After you create your VMSS it can take up to 15 minutes before all components will be provided.

“If you deploy the firewalls in an existing VNET with pre-defined subnets double check if this VNETs resource group also has your app as a contributor via IAM else your CME will fail to connect”

JDR

You can find your created resources under Home->Resource groups.

• 

Configuring Azure Service Principals

As the number of gateways in scale set can dynamically change, a Security Management needs to reacts quickly and adapt its settings accordingly and of course, install the policy on every new gateway as soon as the deployment will finish. This automatic mechanism is called provisioning and its a part of Cloud Management Extension (CME) – dedicated daemon running on Security Management Server

The first step to configure connectivity between CME and Azure is setting the Azure Active Directory Application. For details go here. Remember to write down the following values in KeePass or any other encrypted vault, especially client_secret as it will be only visible once.

• Application IDclient_id
• Key-valueclient_secret
• Directory ID / Tenant IDtenant
• Subscription ID

Go to Azure Portal -> Favorites -> Azure Active Directory or use search. Find App registrations in the Manage list and choose New registration. Choose a name (check-point-autoprovision)and set Redirect URI ( https://localhost/check-point-autoprovision) and click Create.

• 

You can find the needed information in the Overview, except Object-ID, cause we will assign the Contributor role to a resource group and this value will change.

• 

Create a new application secret under App registrations->Certificates & secrets. Set the secret to never expire. Store the value somewhere safe. This will be your client_secret.

• 

The final step is to create a role assignment. You can find this option under Resource groups->(Name of your resource group)->Access control(IAM). Choose Add a role assignment and create a Contributor role as below.

• 

The service principal is now set up but you need to copy-paste one last important information for later use – Subscription ID. You can find this value in Home->Subscriptions.

• 

How to set a Security Management Server

Managing the firewall policy and security gateways without the Security Management Server is impossible. In this section, I will help you install and configure a new management server in the cloud. If you already have the management server and just want to connect it to your VMSS deployment jump directly to the next part. If you want to migrate from management in the cloud to your on-prem or the other way around check this.

Starting a Security Management Server in the cloud is as easy as deploying the VMSS but my tip here is to create a new resource group for it. Go to Marketplace and choose Check Point Security Management.

• 

Just like before fill in the template information.

• 

The general rule is that your management needs to be at least the same version that your security gateway is but there are some exceptions when it comes to CloudGuard. In this case, I go with version R80.30

• Allowed GUI clients – this option allows you to limit access to security management to specified addresses only

• 

I will deploy security management in new VNET (vnet_cloudguard_mgt) and configure peering between this VNET and VNET01 (in which VMSS resides). I do this because I will use public IP to reach the management and want to separate both environments but you can simply create a new network in existing VNET.

• 

• 

After the validation and terms acceptance, you should now be waiting for your deployment to finish. It can take a while so go grab a tea or coffee if you like. Details about the server can be checked in Resource Group -> (name of the resource group) ->Virtual Machine. You can find the Public IP here. Don’t forget to add the Access control (IAM) role if you want to use this resource group as dynamic objects in the security policy.

• 

You can check the connectivity by running the ping from the gateway to the management. You can use Serial Console built-in Azure.

Configuring Cloud Management Extension

Cloud Management Extension or simply CME is a utility that runs on Check Point Management Server and allows integration between Check Point CloudGuard IaaS solutions and cloud platforms such as Azure. It’s formerly known as Auto-provision.

If you don’t have your own on-premises management you can add Security Management instance in the cloud. This procedure is described here. Come back to this section after you finish.

Configuring CME is relatively simple when we’ve all the needed information upfront. Here is the list of the information you need to have at the line of sight before we start. Most of them I’ve asked you to store earlier in this guide so it should be easy-peasy for you.

• management name from configuration template (“my_management”)
• configuration template name (“my_template”)
• SIC password
• installed gateway version (R80.20)
• firewall policy name (“Standard” – but only if not changed)
• Azure Subscription ID
• Azure Directory/Tenant ID
• Azure Application ID
• Azure Secret / client-secret

Let’s start with downloading and installing the CME agent on the management. You can do this by manually downloading the agent from this website (you need to have valid Check Point account) or by using Check Point Upgrade Service Engine (CPUSE). I will go with the second option. CPUSE is available over HTTPS on your management server under Upgrades(CPUSE)->Status and Actions or by SSH using a command installer download and installer install.

• 

Please be aware that you need to have an administrator lock and view All packages to be able to see and install the CME package. Install the newest available CME wrapper. This package doesn’t require a reboot but you need to reestablish SSH session if you have one.

You can check if the installation was successful by starting a new SSH session and using the following command in expert mode.

To configure the CME we need to create an Azure controller and set all service principals together with template information. Admin Guide describes this procedure vaguely so here is my brief explanation of some concepts.

• Controller – allows setting authentication method for specific cloud provider (in this case Azure)
• Management – in our case we set localhost but if needed CME plugin can be installed on a different host and access management API remotely (remember to adjust Management API settings accordingly). At least there is an option to do this but I’ve never tested this 🙂
• Template – describes what settings should be set on the security gateways during the initial phase (blades, security policy, etc.)

In this output, you can find the required minimum to connect VMSS gateways to security management.

The official guide suggests starting with INIT configuration but I suggest to stop the CME service first. Why? Well, mainly to configure blades information before enforcing the configuration to gateways. In other words, if you will run the INIT config as below when CME service is running you’ll need to set blade, API, etc. manually which can be cumbersome. So first stop the CME service:

Don’t restart the service when asked. It will turn on the CME and our plan to add some blades will be ruined 🙂

Blades and other parameters can be configured within the template. Below I show how to turn on IPS and Identity Awareness. We need Identity Awareness for VSEC to work. For a full list of options, you can use –help or check this part of CME admin guide.

You can check the CME configuration after the initial configuration. The output so as the configuration file is stored as JSON file in $FWDIR/conf/autoprovision.json

When you’re done with the configuration start the CME with:

If you have done all the steps without any mistakes or typos you should now be able to see your fresh VMSS gateways in the Smart Console. If you don’t see anything except the management itself go to the troubleshooting section.

• 

Smart Console and logging to the Security Management for the first time

SmartConsole is a windows-only application (sorry MAC users) that manages the security policy, display logs, and audit information. This is the first weapon of choice and must-have for any Check Point administrator as WEB-GUI or CLI are used only for network configuration and you can’t configure security rules from there. Well, of course, there is also an API if you prefer 🙂

SmartConsole can be downloaded directly from Security Management’ s Web GUI. Connect to the Public IP of your management server using a browser of your choice. HTTPS-only.

• 

Localize the following button on the top of the page and download the installer. It should take approx. 15 minutes to install the app and you need to have at least 1GB of free space on your hard drive.

• 

After the installation, you should be able to find the SmartConsole App in StartMenu. Login with the same credentials and using the same IP.

• 

You should now have the same look as I have. For more details about SmartConsole go here.

• 

How to configure vSEC controller

In order to fetch dynamic data from Azure like resource groups, instance names, tags, etc. you need to configure the Data Connection. It’s called vSEC controller (or CloudGuard Controller) and is by default installed from R80.20 on Security Management. If you want to check if it’s available on your on-premise management, check the below command. If you don’t have it go to this website or download the wrapper using CPUSE in WEB GUI or CLI.

From R80.30 vSEC controller starts automatically when you configure Data Connection. To do this open Smart Console and using Object panel (on the right) go to New…->More->Server->Data Center->Microsoft Azure. The following window should appear. Fill the information from your Azure account (the same we already used when configuring auto-provision/CME). Application Key equals Secure Key/client secret. Publish the configuration.

If Test Connections shows status other than connected check if your security policy/proxy is allowing this traffic (on-premise solution only). Go to the troubleshooting section for further details.

• 

When a data connection is established you can use new types of objects inside the policy. Those objects will be then enforced dynamically on the gateway and the gateway itself will adjust the security policy as soon as new information from Azure will be fetched. By default Azure is asked every 60 seconds but this value can be changed in $FWDIR/conf/vsec.conf. You should change this value on both management and gateway.

To use Azure objects go to Security Policy in SmartConsole, add a new rule and use plus button on the source or destination. Choose Import…->Data Center->(name of the controller). A new window will pop out. I will use Virtual Machine and VMSS types to configure security rule from the management to the gateways allowing all traffic. Remember not to mix this type of object with others.

• 

This is how it looks in the rulebase. Publish and Install the Policy.

• 

You can check if the rule works by establishing an SSH connection from the security management to the security gateway.

How to manage vSEC Central License

Central License is a type of shared license installed only on the Security Management. This license is pushed automatically to the gateway in the Virtual Machine Scale Set during the initial setup and is removed after the gateways are stopped or deleted. In order to push the license to gateways, you need to have a valid shared license in the vSEC pool. There is not much information there but I recommend checking this part of the admin guide.

In this guide, I’m using gateways with 15-days trial but I’ll show you how to generate a shared license, install the license on the Security Management and configure vSEC Central License tool to distribute those licenses on all Azure machines. You can always use Azure Pay-as-you-go license for VMSS. Just calculate the cost before you make the decision.

First, you need to buy a proper license from checkpoint.com. You can contact sales if you struggle to find the right license for your environment. The most important factor, in this case, is the number of CPU cores you need per gateway and software blades that should have corresponding contracts. After you acquire a new license, it must be assigned to only one Security Management server. To do this login to your UserCenter account and go to My Check Point->Product Center. Your license should now be visible in the list under Family: Security VE Gateway. I’ve obfuscated my account number, certificate key of this license and IP address of Security Management to which this license is attached for security reasons.

• 

Open this license. A new tab will pop up with Product Information, so as the number of Seats (CPU cores) and built-in blades.

• 

To attach the license to the management go to License. Fill the information based on your configuration. Set an address to the IP you see on the Gateway tab in your SmartConsole next to your security management. Now go to License Information from the previous tab and Get License.

Save the file on your hard disk and upload using WinSCP or similar tool on your Security Management Server but remember that user you login needs to start directly in /bin/bash. (set user admin /bin/bash). You can also install the license using SmartUpdate by using Licenses & Contracts -> Add License -> From File…

• 

Below I describe the CLI method. Login via SSH to your Security Management.

Now check if your license was correctly attached.

Turn on the vSEC Central License. Those commands run only in Expert Mode.

Open vSEC License CLI.

You should now be able to see the License Pool with the number of seats at your disposal. Those licenses will be automatically distributed to all provisioned gateways. Remember that only CloudGuard gateways that were already provisioned will receive those licenses. You can verify this by running cplic print on each gateway or with option 3 in vsec_lic_cli after a few minutes. You can use option 4 to trigger license distribution.