- Products
- Learn
- Local User Groups
- Partners
-
More
| Policy Installation Flow |
|---|
Policy installation process has several stages:
1) Assuming the initiation was made by the SmartConsole the web service policy installation command is sent to the Check Point management (CPM) on the management server.
2) The first stage is the process that CPM convert the objects with Java from new DB language/ files to the old set language and to files. Then the policy installation process is verifying compiling it to a "language" the security gateway can understand and implement. The verification and compilation stages are performed by the FWM and in the future by CPM process.
Note: The translated policies of CPM for FWM can be found for the „Standard“ policy here:
$FWDIR/conf/Standard.W
3) FWM process is responsible for code generation and compilation. For example, the process reads the policy from „$FWDIR/conf/Standard.W“ and other files and use them for the policy verification and conversion. The FWM process performs verification and conversion of the files and database information for the installation targets for which policy installation is requested.
For this the fw_loader of the corresponding Check Point version is started to verify and convert the policy.
Note:
For the corresponding Check Point versions, the fw_loader and other tools can be found in the following path on a R80.30 management server:
/opt/CPsuite-R80.30/fw1/bin/fw_loader R80.30
/opt/CPR7520CMP-R80.30/bin/fw_loader R75.20, R75.30
/opt/CPR7540CMP-R80.30/bin/fw_loader R75.40, R75.45, R75.46, R75.47
/opt/CPR76CMP-R80.30/bin/fw_loader R76, R76SP to R76SP.50
/opt/CPR77CMP-R80.30/bin/fw_loader R77, R77.10, R77.20, R77.30
/opt/CPR75CMP-R80.30/bin/fw_loader R75, R75.10
One question that keeps coming up is. Which config files are used on the management server to compile policies with user specificlally INSPECT code?
For this purpose, different directorys are used for each Check Point gateway version according to the above scheme similar to fw_loader.
/opt/CPsuite-R80.30/fw1/lib R80.30
/opt/CPR7520CMP-R80.30/lib R75.20, R75.30
/opt/CPR7540CMP-R80.30/lib R75.40, R75.45, R75.46, R75.47
/opt/CPR76CMP-R80.30/lib R76, R76SP to R76SP.50
/opt/CPR77CMP-R80.30/lib R77, R77.10, R77.20, R77.30
/opt/CPR75CMP-R80.30/lib R75, R75.10
Here are the most important config files, which we can customize Check Point INSPECT code individually:
|-> user.def -> User-defined implied rules that can be added in Check Point INSPECT language (sk98239)
|-> fwui_head.def
|-> table.def -> Definitions of various kernel tables for Check Point security gateway (sk98339)
|-> auth.def
|-> base.def
|-> crypt.def -> VPN encryption macros (sk98241)
|-> services.def
|-> proxy.def
|-> crypt.def
4) After code generation and compilation, the FWM process invokes the Check Point Policy Transfer Agent (CPTA) command that sends the policy to all applicable security gateways.
5) The CPD process on the security gateway on port 18191 receives the policy files and save this in the following directory „$FWDIR/state/__tmp/FW1“ on the security gateway. The file integrity of the policy will checked now.
Once complete, the cpd invokes“fw fetchlocal“ to load the new policy with the following command from the temporary policy directory:
fw fetchlocal -d $FWDIR/state/__tmp/FW1
6) The FWD process on the security gateway updates all of the user-mode processes responsible for enforcement aspects. These include VPND process for VPN, FWSSD processes for security server issues and so on. All security server daemons running on the gateway are notified of the new policy by FWD and adjust their behavior accordingly, which could include restarting, stopping or starting if a new feature was enabled.
7) The new policy is loaded into the INSPECT kernel instances while traffic is still being queued. This process happens very quickly. Chain sequences are rebuilt, and may end up adding or removing chain modules from the sequences if blades were enabled or disabled since the last policy push.
The new policy is prepared, the Check Point kernel holds the current traffic and starts queuing all incoming traffic. The atomic load takes place. This process should take a fraction of a second. At this point if "Connection Persistence" is set to "Rematch connections" on the gateway object, a CPU-intensive rematch of all open connections against the new policy is performed to ensure that all current connections are still allowed by the new policy.
Note SecureXL:
If enabled SecureXL is restarted as well and recalculates its various state tables based on the new policy.
During policy load, SecureXL is disabled and re-enabled afterwards. Here I am not quite sure if this is the case with R80.20 as well.
8). The traffic queue on firewall kernel is released and all of the packets are handled by the new security policy.
9) The CPD waits for fw_fetchlocal to complete the process and then informs the management server of the command's status installation succeeded or failed.
10) The FWM process received the policy installation status from CPD process from security gateway and then presents them in SmartConsole.
Note:
Here I am not 100% sure whether the FWM or the CPM distributes the policy installation information to the SmartConsole. According to sk115557, this should be the FWM.
| Firewall Processes |
|---|
CPM Process
CPM process is responsible for writing all information to the PostgreSQL and SOLR databases.
All the communications between the different GUI clients are done through web services. Is a component within CPM. Whenever we connect to the SmartCenter server with SmartConsole we are basically opening a connection from the GUI machine to the CPM process „java à solr-solrj-v4_X_X.jar“ on the SmartCenter server over port 19009 via web service.
- web_services is a component within CPM process that serves GUI and remote client (like remote API) and responsible to transfer the request to the dleserver
- DLE server (dleserver) is a component within the CPM server that contains all the logic of the server to writing the info to the database and SOLR
- object_store is a component within the CPM server, responsible to write the information to SOLR search engine and to the PostgreSQL database
PostgreSQL DB
The CPM process is also responsible to perform all database tasks, such as:
- creating objects
- removing objects
- modifying objects
Whenever we create an object via SmartConsole we are basically sending a command to the CPM process on the SmartCenter server requesting it to create the object or changing it.
SOLR
SOLR is the Full Text Search engine that contains full clone of all data from PostgreSQL database.
FWM Process
The FWM process is used for installing security policy to the backward compatibly R7x.x security gateways after the CPM process converts the objects from Java to old policy file format. It runs only on management products such as security management server, log server, SmartEvent, etc.
- Serving the embedded GUI clients and authentication requests
- Collecting statuses
- Policy compilation for backward compatibly R77.X security gateways
- VSX database operation
- SIC operations via SmartConsole
- Database install
- License attach and detach from SmartUpdate
- Some of management HA functionality
- Performs legacy operations
CPD Process
The CPD process runs on all Check Point products (security management server products as well as security gateways). There are 3 major responsibilities:
- SIC - we contact CPD process during SIC negotiation to validate and/or push the certificate.
If the CPD process on a certain security gateway is down, policy installation on that security gateway will fail due to a SIC issue. After SIC was established, the rest of the communication to the security gateway will be via port 18191. - Status collection - the FWM process requests the CPD process for the statuses from security gateways and security management server and then presents them in SmartView monitor. If the CPD process is down, we will not be able to receive the gateways and security management statuses in SmartView Monitor.
- Installing security policy on the security gateway.
FWD Process
The FWD process is responsible for sending and receiving the logs from the different Check Point entities to the security management\log server (sometimes they are on the same machine).
- On Security Management server side: FWD process listens on port 257, waiting for logs to be sent from various security gateways that are connected to it.
- On the security gateway side: FWD process opens a connection to the FWD on the log\security management server on port 257.
| SK’s |
|---|
sk33208 - How to debug FWM daemon on Multi-Domain Management / Provider-1
sk86320 - How to debug the CPD daemon
sk86321 - How to debug FWD daemon
sk112334 - How to debug SmartConsole / SmartDashboard
sk115557 - R80.x Security Management server main processes debugging
sk103918 - Policy installation fails with the error "Operation failed, install/uninstall has been im...
1 Solution
