Policy Management on Security Group Members

Because the Security GroupClosed 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 GatewayClosed 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 Management ServerClosed Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server., it first installs the policy on the SMO Security Group Member.

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:

Synchronizing Policy and Configuration Between Security Group Members

Use the "asg_blade_config pull_config" command in Gaia gClishClosed 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 the 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:

> asg_blade_config pull_config

2

Do one of these:

  • Reboot the target Security Group Member:

    reboot -b <Security Group Member ID>

  • Start the Check Point services and remove the ClusterXL Critical Device "admin_down":

    cpstart

    clusterXL_admin up

Note - You can run the "asg stat -i all_sync_ips" command in GaiaClosed 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

global_context

$FWDIR/boot/modules/fwkern.conf

/bin/false

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.

[Expert@MyChassis-ch0x-0x:0]# g_cat /etc/xfer_file_list
#The Columns are:
#1) global_context or all_vs_context - VSX support.
#       It separates the files relevant to all VSs (all_vs_context) from those which are only relevant for VS0 (global_context)
#       In a security gateway mode, there is no difference between the two values
#2) File location in the SMO - where to pull the files from
#3) Action to perform after the file is copied, if it's different.
#       The result of the operation determines if a reboot is needed after the operation - 1 for reboot, 0 for no reboot
#       Please Notice - /bin/false => reboot, /bin/true => don't reboot
#4) [Optional] A local path to copy the file to, needed if different from the source
 
global_context /opt/CPda/bin/policy.xml /bin/true
global_context /etc/upgrade_pkg-0.1-cp989000001.i386.rpm "rpm -U --force --nodeps /etc/upgrade_pkg-0.1-cp989000001.i386.rpm"
global_context /etc/sysconfig/image.md5 "/usr/lib/smo/libclone.tcl --clone --rsip --xfer --reboot"
global_context $PPKDIR/boot/modules/sim_aff.conf "sim affinityload"
global_context $PPKDIR/boot/modules/simkern.conf /bin/false
global_context $FWDIR/boot/boot.conf /bin/false
global_context $FWDIR/boot/modules/fwkern.conf /bin/false
all_vs_context $FWDIR/conf/fwauthd.conf /bin/false
all_vs_context $FWDIR/conf/discntd.if /bin/false
#global_context /var/opt/fw.boot/ha_boot.conf /bin/false
global_context /config/active  /usr/bin/confd_clone /config/db/cloned_db
global_context /tmp/sms_rate_limit.tmp /bin/true
global_context /tmp/sms_history.tmp /bin/true
global_context /home/admin/.ssh/known_hosts /bin/true
global_context /etc/passwd /bin/true
global_context /etc/shadow /bin/true
... output is cut for brevity ...
global_context /etc/smodb.json  "/usr/lib/smo/libclone_smodb.tcl clone_smodb_apply"      /tmp/smo_smodb.json
global_context $FWDIR/conf/prioq.conf   /bin/false
global_context /web/templates/httpd-ssl.conf.templ /usr/scripts/generate_httpd-ssl_conf.sh
all_vs_context $FWDIR/conf/fwaccel_dos_rate_on_install /bin/false
all_vs_context $FWDIR/conf/fwaccel6_dos_rate_on_install /bin/false
global_context $FWDIR/database/sam_policy.db $SMODIR/scripts/compare_samp_db.tcl /tmp/sam_policy.db.new
global_context $FWDIR/database/sam_policy.mng /bin/false
all_vs_context $FWDIR/conf/icap_client_blade_configuration.C /bin/true
global_context $CPDIR/conf/chassis_priority_db.C /bin/true
[Expert@MyChassis-ch0x-0x:0]#

MAC Addresses and Bit Conventions

MAC addresses on the system are divided into these types - BMAC, VMAC, and SMAC:

A MAC address assigned to all interfaces with the naming convention "BPEthX".

This is unique for each Security Group Member.

It does not rely on the interface index number.

Bit convention for the BMAC type:

Bit range

Instructions

1

Distinguishes between VMAC and other MAC addresses.

This is used to prevent possible collisions with VMAC space.

Possible values are:

  • 0 - BMAC or SMAC

  • 1 - VMAC

2-8

Security Group Member ID (starting from 1).

This is limited to 127.

9-13

Always zero.

14

Distinguishes between BMAC and SMAC addresses.

This is used to prevent possible collisions with SMAC space.

Possible values:

  • 0 - BMAC

  • 1 - SMAC

15-16

Absolute interface number. This is taken from the interface name.

When the BPEthX format is used, X is the interface number.

This is limited to four interfaces.

A MAC address assigned to all interfaces with the naming convention "ethX-YZ".

This is unique for each Site.

It does not rely on the interface index number.

Bit convention for the VMAC type:

Bit range

Instructions

1

Distinguishes between VMAC and other MAC addresses.

This is used to prevent possible collisions with VMAC space.

Possible values are:

  • 0 - BMAC or SMAC

  • 1 - VMAC

2-3

Site ID.

Limited to 2 Sites.

4-8

Switch number.

Limited to 32 switches.

9-16

Port number.

Limited to 256 for each switch.

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 the SMAC type:

Bit range

Instructions

1

Distinguishes between VMAC and other MAC addresses.

This is used to prevent possible collisions with VMAC space.

Possible values are:

  • 0 - BMAC or SMAC

  • 1 - VMAC

2-8

Security Group Member ID (starting from 1).

This is limited to 127.

9-13

Always zero.

14

Distinguishes between BMAC and SMAC addresses.

This is used to prevent possible collisions with SMAC space.

Possible values:

  • 0 - BMAC

  • 1 - SMAC

15

Always zero.

16

Sync interface.

Possible values are:

  • 0 - Sync1

  • 1 - Sync2

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

asg_mac_resolver <MAC address>

Example

[Expert@MyChassis-ch0x-0x:0]# asg_mac_resolver 00:1C:7F:01:00:FE

[00:1C:7F:01:00:FE, BMAC] [Chassis ID: 1] [SGM ID: 1] [Interface: BPEth0]

[Expert@MyChassis-ch0x-0x:0]#

Notes:

  • The specified MAC Address comes from BPEth0 on Security Group Member #1 on the Site #1.

  • 00:1C:7F:01:00:FE is the Magic MAC attribute, which is identified by "FE".

  • 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.