Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Danny
Champion Champion
Champion

Properly stopping a cluster member (cpstop vs. cphastop)

Let's discuss!

Whenever a cluster member needs to be stopped from working within a cluster for some time the question is how to perform this properly.

Check Point's official Best Practice: cpstop
I didn't find an explanation yet, why cpstop was elected to be best practice with so many documented caveats (see below).

Other alternatives are (excerpt):

  • cpstop -fwflag [-default, -proc, -driver]
  • cphastop
  • system shutdown
  • network disconnect

So let's have a closer look at each of the options.

Option 1: cpstop

What it does:

  • Shuts down Check Point processes
  • Unloads the security policy from the kernel
  • Disables IP forwarding (routing) and therefore stops traffic passing
  • Stops the state synchronization between this cluster member and its peer cluster members

Caveats:

  • Leaves the cluster member unprotected
  • Allows connections directly to this Cluster Member as connections are not blocked by the security policy anymore
  • Does not generate logs for Check Point's security management
  • Even with properly configured SSH host access settings the firewall initially answers to SSH requests, therefore IDS systems are likely to report SSH brute force attempts, credential access, lateral movement warnings
  • All SSH access attempts are logged to /var/log/secure which is not as easy to read as SmartLog
  • In case the gateway has an interface leading to the internet and the SSH host access settings contain 'Any' then internet port scanners will pretty soon start to run SSH login attempts, so only a highly secured and strict password security policy is the last resort of gateway protection
  • Check Point recommends to disconnect the gateway before running it, especially if the cluster member needs to be stopped for a longer time

Rationale: Only use cpstop for internal Check Point clusters. For clusters with network interfaces leading to the internet additional security actions are required!

Option 2: cpstop -fwflag [-default, -proc, -driver]

What it does:

  • Depends on the flag/parameter used

Caveats:

  • These flags/parameters are for Check Point internal use.
  • Do not use them, unless explicitly instructed by Check Point Support or R&D to do so.

Rationale: Only use cpstop with flags/parameters if Check Point advises you to do so.

Option 3: cphastop

What it does:

  • Stops the cluster software on a cluster member
  • Stops the state synchronization between this cluster member and its peer cluster members

Caveats:

  • Check Point recommends to use Option 1 as best practice without explaining why

Rationale: Use cphastop whenever you need to stop a cluster member.

Option 4: system shutdown

What it does:

  • Halts the entire system and therefore also stops the cluster member

Caveats:

  • May require physical access to the system to start it again if no LOM card is installed and connected or no terminal console server connected to the serial port

Rationale: Valid option to stop a cluster member if turning on the system is easily possible afterwards.

Option 5: network disconnect

What it does:

  • Stops the cluster member from communicating via network (disconnect can performed in various ways: shut the switch ports, set cluster member's interfaces down, physically disconnecting network cables etc.)

Caveats:

  • Depending on how the network disconnect is performed, if a LOM card is installed and connected or if a terminal console server connected to the serial port the network re-connection may require physical access to the system.

Rationale: Valid option to stop a cluster member if re-connecting the network is easily possible later on.

10 Replies
Timothy_Hall
Champion
Champion

May want to mention that Option 3 is what happens when one does a "Stop Cluster Member" from ye old school SmartView Monitor, which is quite different from clusterXL_admin down.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
(1)
the_rock
Legend
Legend

Excellent explanation @Danny 👍

0 Kudos
_Val_
Admin
Admin

Why reinvent the wheel, if we already have it as an SK (some options you missed :-)): Best Practices - Manual fail-over in ClusterXL?

0 Kudos
(1)
Danny
Champion Champion
Champion

@_Val_ : This thread is about stopping a cluster member and not handling a fail-over.

(1)
_Val_
Admin
Admin

Then options 3 and 5 are not exactly to the task 🙂

0 Kudos
Danny
Champion Champion
Champion

Option 3 is exactly to the point and option 5 is mentioned for completion as Check Point mentions it here as well.

the_rock
Legend
Legend

I agree 100% @Danny . I always use cphastop myself.

Lloyd_Braun
Collaborator

i always used cphastop as it is a lot faster than cpstop. when you have to make that leap of faith that your 'ready'-status cluster node is going to go active, theoretically it would be a lot faster to 'cphastart' and get a cluster node active again. i cannot say i ever had to use cphastart though so not sure it would work as expected during a problematic upgrade.

the_rock
Legend
Legend

I definitely used it in the past with various versions and never had a problem.

0 Kudos
Nik_Bloemers
Advisor

I've personally always used cpstop, mostly because CP themselves say to do so rather than use cphastop as you've mentioned.
"Best Practice - To stop a Cluster Member, use the "cpstop" command." from the ClusterXL admin guide:

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_ClusterXL_AdminGuide/Topics-...

I assume they have their reasons 🙂 But would also like to learn them too.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events