Policy Management on Security Group Members
Because the Security Group
A logical group of Security Appliances that provides Active/Active cluster functionality. A Security Group can contain one or more Security Appliances. Security Groups work separately and independently from each other. To the production networks, a Security Group appears a single Security Gateway. Every Security Group contains: (A) Applicable Uplink ports, to which your production networks are connected; (B) Security Appliances (the Quantum Maestro Orchestrator determines the applicable Downlink ports automatically); (C) Applicable management port, to which the Check Point Management Server is connected. works as one large Security Gateway Dedicated Check Point server that runs Check Point software to inspect traffic and enforce Security Policies for connected network resources., all Security Group Members are configured with the same policy. When you install a policy from the Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server., it first installs the policy on the SMO. The SMO copies the policy and Security Group Member configuration to all Security Group Members in the UP state. When the Security Group Member enters the UP state, it automatically gets the installed policy and configurations that are installed, from the SMO. When there is only one Security Group Member in the UP state, it is possible there is no SMO. Then, that Security Group Member uses its local policy and configuration.
If there are problems with the policy or configuration on the Security Group Member, you can manually copy the information from a different Security Group Member.
The Security Group Member configuration has these components:
-
Firewall policy, which includes the Rule Base
All rules configured in a given Security Policy. Synonym: Rulebase. -
Set of configuration files defined in the
/etc/xfer_file_listfile. This file contains the location of all related configuration files. It also defines the action to take if the copied file is different from the one on the local Security Group Member.
Synchronizing Policy and Configuration Between Security Group Members
Use the asg_blade_config pull_config command in Gaia gClish The name of the global command line shell in Check Point Gaia operating system for Security Appliances connected to Check Point Quantum Maestro Orchestrators. Commands you run in this shell apply to all Security Appliances in the Security Group. to synchronize policies manually.
Optionally it can configure files from a specified source Security Group Member to the target Security Group Member.
The target Security Group Member is the Security Group Member you use to run this command.
To synchronize Security Group Members manually:
| Step | Instructions | |
|---|---|---|
|
1 |
Run:
|
|
|
2 |
Reboot the target Security Group Member, or run these two commands:
|
Note - You can run the asg stat -i all_sync_ips command in Gaia Check Point security operating system that combines the strengths of both SecurePlatform and IPSO operating systems. gClish to get a list of all synchronization IP addresses on the Security Group Member.
Understanding the Configuration File List
The /etc/xfer_file_list file contains pointers to the related configuration files on the Security Group Member. Each record defines the path to a configuration file, followed by the action to take if the imported file is different from the local file. This table shows an example of the record structure.
|
Context |
File name and path |
Action |
|---|---|---|
|
|
|
|
The context field defines the type of configuration file:
-
global_context- Security Gateway configuration file -
all_vs_context- Virtual Systems configuration file
The action field defines the action to take when the imported (copied) file is different than the local file:
-
/bin/true- Reboot is not required -
/bin/false- Reboot is required -
String enclosed in double quotes - Name of a "callback script" that selects the applicable action.
Example - Configuration file list:
|
|
MAC Addresses and Bit Conventions
MAC addresses on the system are divided into these types:
|
Type |
Description |
||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
BMAC |
A MAC address assigned to all interfaces with the This is unique for each Security Group Member. It does not rely on the interface index number. Bit convention for BMAC
|
||||||||||||||
|
VMAC |
A MAC address assigned to all interfaces with the This is unique for each Site. It does not rely on the interface index number. Bit convention for VMAC
|
||||||||||||||
|
SMAC |
A MAC address assigned to Sync interfaces. This is unique for each Security Group Member. It does not rely on the interface index number. Bit convention for SMAC
|
MAC Address Resolver (asg_mac_resolver)
Description
Use the asg_mac_resolver command in Gaia gClish or the Expert mode to make sure that all types of MAC addresses, BMAC, VMAC, and SMAC, are correct.
From the MAC address you provide, the asg_mac_resolver command determines the:
-
MAC type
-
Site ID
-
Security Group Member ID
-
Assigned interface
Syntax
|
|
Example
|
|
Notes:
-
The specified MAC Address comes from BPEth0 on Security Group Member #1 on Site #1.
-
00:1C:7F:01:00:FEis the Magic MAC attribute, which is identified byFE. -
The index length is 16 bits (2 Bytes) identified by 01:00 x x x x x x x x x x x x x x x x.