This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
ABOUT CHECKMATES CYBER SECURITY COMMUNITY & FAQ
Help

Who rated this post

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Don_Paterson
Advisor
Advisor
a month ago
In response to Lars_de_Mooy

The Check Point Security Management Server (SMS) has the Postgres database system running in it.

Stored inside the Postgres DB are all the Check Point objects, policies and config. Pretty much everything you see in the SmartConsole apart from the logs.

Customer specific config on top of the out of the box config.

 

The management API allows customers to bypass the SmartConsole and interact with the Postgres database via the API (for example, using command line).

That means that they can manually manage objects and rules, or fully automate that via the API.

https://sc1.checkpoint.com/documents/latest/APIs/#introduction~v1.9.1%20

 

Since CME is integrate in the SMS and needs to get some configururation, that can be done via the SMS API (but also using the autoprov-cfg command in some cases).

The autoprov-cfg command is the original command for configuring the CME (if I understand properly).

 

The CME config includes building a controller (at the 36 minute mark in Jeff’s video), which represents the connection/binding with Azure and the subscription.

In some cases we can run autoprov-cfg show all to see the controller. Meaning that we can see out controller build specifically to plug into Azure.

More controllers can be built for plugging into AWS and GCP etc.

One CME, many controllers.

It’s like the old AD binding.

 

Through that connection (the controller) the CME can interact with the public cloud.

 

Going further…

 

To understand the history and one of the original purposes of the CME you need to know about cloud scaling solutions.

Scaling solutions like Azure VMSS (Virtual Machine Scale Sets) and AWS Auto Scaling Groups are at the heart of cloud elasticity.

You can create a VMSS, which is a group of one or more identically configured VMs (in our case CloudGuard SG VMs) and along with that comes the Azure Load Balancer, which distributes connections amongst the CloudGuard SGs.

If you deployed, for example, 2 VMSS instances (CloudGuard gateway VMs) and then they get to a point where they are experiencing high CPU usage because of growing traffic load then Azure would detect  that and spin up a new identical CloudGuard gateway to help the current ones because they have reached and exceeded a CPU high water mark (80%).

 

That is the scale out event.

 

The CME (Cloud Management Extension) was developed as a new add-on the SMS, with the objective to interact with the cloud and be able to detect scale out events.

That is only possible by having the CME talk to the Azure API (yet another API).

Given the right details the CME can go into the Azure subscription via the API and discover the specially tagged VMSS solution and within there the instances.

The scale out event brings a new instance, which the CME detect by regularly checking on the VMSS.

 

And so, the main task of the CME was initially (and still valid and important now) is to monitor scaling solutions and whenever a scale out event happens the CME detects that and then update the SMS (via the SMS’s API)

Working together with the SMS API the CME gets the new Scale set VM (CloudGuard SG) automatically added to the SmartConsole (adding the gateway object into GATEWAYS & SERVERS) which includes getting  the trust established between the SMS and the new SG, and then any software blades enabled (like IPS for example) on top of the already enabled FW blade.

After that the policy install happens, again automatically.

The CME learns the IP address of the new gateway so that all of that is made possible over the network.

 

The new SG is known to Azure (obviously) and Azure starts to send health probes to the new SG (port 8117 TCP – from IP 168.63.129.16).

When the new SG is ready and policy install is completed and the SG starts to respond to the health probes then the LB starts to forward traffic to the 3rd SG.

 

Scale in event is all of that in reverse(kind of), and happens after no less than 5 minutes and when the low water mark is reached (60% aggregate CPU across the 3 SGs).

 

 

The Overview in here is a bit light weight and fluffy/cloudy.

https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CME/Content/Topics-CME/Overview.htm

https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/overview

 

Behind a vWAN solution (the NVA) there is something like a VMSS (I believe it is VMSS but not like the normal VMSS) and the CME is involved in configuration within that solution.

 

I’m not experienced in the vWAN solution so Jeff can fill in the blanks and correct me if needed.

 

Hope that all makes sense and helps.

 

0 Kudos
(1)
Who rated this post