Confusion of SMART (the Check Point Security Management Architecture) components and relation to each other.
The Check Point mulit-layered management solution can be confusing.
This FAQ is an attempt to clarify the most basic components for a Check Point deployment and their relation to each other.
Check Point has made it nearly impossible to manage their security software without a management server, and its GUI Client. You could alter configuration files to achieve a level of configuration, but due to the verbosity of such files, and inaccurate (possibly purposefully misleading) labeling within such files make this a grand feat with incredible administrative overhead. Furthermore, Check Point will not support such manual configuration, as doing so, you are bound to break your firewall.
So their SMART is a must for management. The SMART has three necessary components in order to deploy and configure a Check Point Firewall. 1) The Security Gateway, which is a collection of security software that make the Next-Gen / UTM firewall itself; 2) the Management module, which is the combined services that manage said firewall; and 3) SmartConsole, which is a collection of Windows OS GUI clients designed to control the management module (for clarification, these are installed on our Terminal Servers which you must use for managing the firewalls), and specifically for the firewall management is the SmartDashboard utility.
All three components are software services, and can actually be installed on the same device (if you don’t mind your deployment running from a Windows server, which although supported, I would never recommend)! But, even if it is all installed on the same server, each component still operates on its own. It is because of this that I recommend thinking about the Firewall and Management as completely separate servers, regardless of whether or not it is in a stand-alone deployment.The ONLY exception to this is that the Management module, and firewall modules share the use of the active Objects DB (the user DB is not shared, as the management module utilizes a “prospective” DB for users, that can be updated with the “Save” function)– see “Users and Objects DB, and “Install Database…” explained” FAQ for more details.
Check Point supports three deployment types as follows:
Distributed Deployment — In this deployment the Security Gateway (SG) and Security Management Server (SMS) is installed on different devices. This deployment is recommended as both components do not share the same physical resources of a device; however, considering that a minimal management server licensing runs greater than $9,000 (MSRP), you can see how the price restrictions may affect a customer’s decision in the deployment type. Check Point considers “Bridge Deployment” a separate deployment type, per install guide, but as this requires a Distributed Deployment (as far as where the management component is installed), I will only note it here.
Stand-alone deployment — In this deployment the Security Gateway and Management Server are installed on the same device. This isn’t recommended as the two components must share physical resources. This becomes problematic when you attempt to perform management items on the server, such as installing policy or querying with SmartView Tracker or Monitor.
Full HA stand-alone — This deployment is a 2 stand-alone members, HA cluster which both devices have both SG and SMS installed and the SG will utilize ClusterXL (HA only, IE Load Sharing requires distributed deployment to be supported) or VRRP (the SG’s HA component) and the SMS will use management HA component. As both SG and SMS ARE SEPARATE SERVICES, their HA components are completely separate as well. For example, in this deployment, you may have one server that is the primary and active SG while at the same time it is the standby SMS. Please see “Management HA Explained” and “ClusterXL Quick Review” FAQs for more information (both releases TBD).
So we have established that there are 3 necessary components, but how do these components interact with each other? That is fairly straight forward: When you start your SmartDashboard client, it will connect to the SMS and loads the “prospective” configurations from it –> After modifying the policy, you must issue a “Save” function (even installing the policy requires this save function which SmartDashboard will advise when attempting to do the install), which sends all the modifications made back to the SMS, overwriting the SMS’s current “prospective” configurations. Currently (even in a stand-alone deployment) the SG component has no clue about these changes. In order to make these changes active, you must issue a policy install command (done so through SmartDashboard > “Policy” menu > “Install…”). When you do so, the “prospective” configurations, in its entirety, are then sent from the SMS to the SG, overwriting the SG’s current “active” configurations. The SMS also sends commands to reload the SG’s current configuration with the newly overwritten ones, so in essence, the fwd (SG process) is restarted with the new configuration immediately.
Note: The fact that policy install sends the SMS prospective configurations IN ITS ENTIRETY — which overwrites the current SG’s active configuration IN ITS ENTIRETY — is something that is very useful to note. A policy install may clear up a lot of odd issues that occur (see “Check Point Proves the Chaos Theory” FAQ for more details).
OK, great, now I get how they interact with each other, but how do they COMMUNICATE with each other? In a stand-alone deployment, obviously the SMS has direct access to the SG through the system OS. So when the SMS is transferring the configuration, its really simply by issuing remove and copy commands… That is the SMS issues OS commands that remove the current “active” configuration files before copying the “prospective” configuration, from a separate location, over to replace them. But the communication of SmartConsole to the stand-alone server, and communication between all components in a distributed deployment, is handled by a Check Point proprietary protocol: Secure Internal Communications (SIC).
SIC is a communication protocol that utilizes x.509 certificates and TLS (SSLv3? they don’t specify exact encryption proto used in their docs), in order to establish a trust between all Check Point components. This trust MUST be established in order for the components to communicate. In order to establish the trust between SmartConsole and the SMS, you must first authenticate the user through SmartConsole, then SMS will provide its certificate in response to that client, finally a pop-up will come up on the screen displaying that SMS’s certificate key with an option to “OK” it. Click OK and trust is established — the only check the SMS does against a SmartConsole client connection is a check against the GUI clients list (configurable ACL, basically), and the user authentication (though cert auth is an option for the USER auth, the SMS does not install certs on your client machine). SIC between SMS and SG is more envolved, and starts with configuring a SIC one-time password (pre-shared key like) on the SG, then through SmartDashboard, defining that same key on that SG’s object. The initial communication is authenticated by this key, but then the SMS (which also utilizes a full fledged Certificate Authority aka ICA) creates a SIC cert for the SG and sends it to the SG. It then does an exchange of key information, and if that information is as the SMS / SG both expect, trust will be established.