Support Center > Search Results > SecureKnowledge Details
Check Point response to "Check Point Connection Table Leakage"
Symptoms
Cause

The chain of events:

  1. A cluster (e.g., "Cluster_1") was initially configured and managed by a Management Server (e.g., "Management_1").

  2. One of the cluster members (e.g., "Member_B") of this cluster ("Cluster_1") was detached from the cluster object managed by an original Management Server ("Management_1"), and SIC was reset between this cluster member ("Member_B") and the original Management Server ("Management_1").

  3. A new Management Server (e.g., "Management_2") was installed on the same physical network segment as the first cluster ("Cluster_1") and the original Management Server ("Management_1").

  4. A new cluster (e.g., "Cluster_2") was installed on the same physical network segment as the first cluster ("Cluster_1").

  5. The new cluster ("Cluster_2") was configured on the new Management Server ("Management_2") with the same IP addresses as the first cluster ("Cluster_1")

  6. On the remaining cluster member ("Member_A") of the first cluster ("Cluster_1" managed by "Management_1"), the following command was executed (refer to sk37030):

    [Expert@HostName]# fw -d fullsync IP_address_of_Sync_interface_of_Member_B

    Note: The 'fw fullsync' command initiates a Full Sync between cluster members, followed by the Delta Sync.

  7. The remaining cluster member ("Member_A") of the first cluster ("Cluster_1" managed by "Management_1") tried to initiate a Full Sync with "Member_B", which is located on the same physical network segment.

  8. Since "Member_A" is managed by "Management_1" and "Member_B" is managed by "Management_2", the Full Sync failed (due to untrusted SIC).

  9. The next synchronization phase - Delta Sync completed successfully (since it did not rely on SIC), which resulted in synchronization of kernel tables between these members of different clusters.

Solution

This is not a vulnerability, rather a wrong configuration. The cluster synchronization network is considered to be trusted and protected.

To assure that the Synchronization network is indeed protected, customers are advised to use a dedicated physical network segment or VLANs.

Refer to ClusterXL Administration Guide (R55, R60, R61, R62, R65, R70, R70.1, R71, R75, R75.20, R75.40, R75.40VS, R76, R77) - Chapter 2 'Synchronizing Connection Information Across the Cluster' - The Synchronization Network.

In addition, refer to sk25977 - Connecting multiple clusters to the same network segment (same VLAN, same switch).

 

Credits

Check Point thanks Munis Badar for responsible disclosure of this issue.

This solution is about products that are no longer supported and it will not be updated

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment