Following my post on Check Point CCSA Exam notes, in this post I’m gonna write notes on CCSE exam. Though this time I won’t fall into configuration and try to only point out the more important and real-world-applicable things.
Management Server HA
- When adding a new Check Point host as a Secondary Management Server, do not Initialize SIC before selecting Network Policy Management feature!
- After adding the host, save and Install the policy; synchronization will then work.
As a reminder, whenever you reset the SIC for a Gateway from Management Server, it should be re-initialized from the Gateway by cpconfig; don’t forget to exit cpconfig!
Check Point calls its clustering solution ClusterXL which supports up to 8 Cluster members and can be implemented in two main flavors:
- Multicast mode: 50/50, very efficient and excellent performance
- Unicast mode: 70/30, to be used in environments where an intermediate device has issues with multicast MAC address (IGMP Snooping)
Expert@GAiA-2:0]# cphaprob state Cluster Mode: Load Sharing (Unicast) with IGMP Membership Number Unique Address Assigned Load State 1 192.168.0.101 30% Active (pivot) 2 (local) 192.168.0.102 70% Active
- High Availability (HA)
- New Mode: Each member has its own physical IP address
- Legacy Mode: Both members have the same physical IP address
To make kernel changes permanent, they should be written in $FWDIR/modules/fwkern.conf
To make sure that Clustering Synchronization is in good shape:
GAiA-2> fw ctl pstat | grep -A 10 Sync: Sync: Version: new Status: Able to Send/Receive sync packets Sync packets sent: total : 3427, retransmitted : 0, retrans reqs : 0, acks : 198 Sync packets received: total : 4736, were queued : 0, dropped by net : 0 retrans reqs : 0, received 364 acks retrans reqs for illegal seq : 0 dropped updates as a result of sync overload: 0 Callback statistics: handled 99 cb, average delay : 1, max delay : 1
GAiA-1> fw tab -t connections -s HOST NAME ID #VALS #PEAK #SLINKS localhost connections 8158 32 56 30 GAiA-2> fw tab -t connections -s HOST NAME ID #VALS #PEAK #SLINKS localhost connections 8158 33 62 31
In a clustered environment, it’s a good practice to disable synchronization for uncritical services; this will extremely decrease utilization on the cluster and improve the performance in enterprise throughput environments.
As it’s obvious in the CLI snippets, cphaprob state indicates the Cluster status.
When configuring a Cluster Synchronisation Network over a VLAN interface, it is only supported on the lowest VLAN tag of the interface!
Here, you will find a really good overview of Check Point Clustering solutions.
To initiate a manual Failover, there’s a special shell script at $FWDIR/bin/clusterXL_admin on/off which sets the member’s ClusterXL state respectively.
Check Point has provided a good read on this here.
Check Point provides two software based features to maximize the firewall performance; CoreXL and SecureXL. Both are included in the OS without any license requirement.
With SecureXL, some CPU intensive operations are processed by virtualized software instead of the Firewall kernel; thus the firewall can provide better inspection and process the traffic more efficient and accelerate the throughput.
From SecureXL perspective, there are three traffic flows:
- Slow path: Packets and connections are inspected by the Firewall and SecureXL won’t process them.
- Medium path: These are packets which need deeper inspection and can’t use Accelerated path. Although it could be unnecessary for the Firewall to inspect them and they can be offloaded by another feature. As an example mentioned in the Check Point documentation, packets that are inspected by IPS cannot use the accelerated path and can be offloaded to the IPS PSL (Passive Streaming Library). As a result, these packets will be processed faster by SecureXL than the packets on Slow path.
- Accelerated path: Packets which are offloaded from the Firewall to SecureXL, and are quickly processed.
The initial packets of a TCP connection are processed in the Slow path and will be identified by the five tuple attributes: source address, destination address, source port, destination port and protocol. From that point on, packets matching that tuple will take the Accelerated path. This explains how SecureXL provides Throughput Acceleration.
SecureXL should be enabled via cpconfig, and then can be dynamically disabled/enabled by fwaccel command. Keep in mind that fwaccel configuration doesn’t survive a reboot!
To check the status of SecureXL (Firewall Acceleration) and enabled features:
Expert@GAiA-2:0]# fwaccel stat Accelerator Status : on Accept Templates : enabled Drop Templates : disabled NAT Templates : disabled by user Accelerator Features : Accounting, NAT, Cryptography, Routing, HasClock, Templates, Synchronous, IdleDetection, Sequencing, TcpStateDetect, AutoExpire, DelayedNotif, TcpStateDetectV2, CPLS, WireMode, DropTemplates, NatTemplates, Streaming, MultiFW, AntiSpoofing, ViolationStats, Nac, AsychronicNotif, ERDOS Cryptography Features : Tunnel, UDPEncapsulation, MD5, SHA1, NULL, 3DES, DES, CAST, CAST-40, AES-128, AES-256, ESP, LinkSelection, DynamicVPN, NatTraversal, EncRouting, AES-XCBC, SHA256
It’s definitely a must-to-implement on multi-core platforms! With CoreXL the firewall kernel is copied into multiple instances, each running on one processing unit, as a totally independent inspection kernel.
Do note that CoreXL is not supported when one of the following features are enabled:
- Check Point QoS (Quality of Service)
- Route-based VPN
- IPv6 on IPSO
- Overlapping NAT
CoreXL is enabled/disabled via cpconfig and requires a reboot to take effect.
Number of instances can be set when CoreXL is enabled by following the same menu.
IKE DoS Protection
The IKE protocol requires the receiving Security Gateway to allocate memory for the first IKE Phase 1 request packet that it receives.
An attacker can send a huge amount of well-formed IKE first packets, while spoofing a different source IP address for each. Following IKE requirement, the receiving firewall must reply to each, and assign memory for every single IKE first packet. This can utilize Memory and CPU resources, and as a result could prevent legitimate users’ connections.
Check Point Security Gateway classifies VPN sources in two categories with respective DoS protection mechanisms:
- Identified: an allowed source machine/IP; the gateway by default requires the peer to respond to an IKE notification in a way that proves that the IP address of the peer is not spoofed. This is called Stateless IKE DoS protection.
- Unidentified: Unknow sources, such as a SecuRemote / SecureClient, or a Check Point Security Gateway with a dynamic IP address; here the Security Gateway requires the peer to solve a mathematical puzzle. Solving this puzzle consumes peer CPU resources in a way that makes it difficult to initiate multiple IKE negotiations simultaneously. This IKE DoS protection method is called Puzzles.
Each mentioned method, plus None, can be used in both cases; although it doesn’t make sense to interchange them. Why would someone want to degrade performance by requiring a known peer to solve a puzzle?!
I had to remove Secondary Management role from a Firewall. What I found easiest to achieve this was to running the First Time Configuration Wizard again.
Upon completing the initial configuration, the First Time Configuration Wizard creates the following special (empty) file on the appliance:
- SecurePlatform OS:
- Gaia OS:
The existence of this file is checked each time the user tries to configure the appliance.
In my case, running GAiA R77 I had to do as below:
[Expert@GAiA-1]# rm -i /etc/.wizard_accepted [Expert@GAiA-1]# rm -i $FWDIR/conf/ICA.crl [Expert@GAiA-1]# rm -i $FWDIR/conf/InternalCA.*