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.
