This site is protected by Check Point Web Application Firewall (WAF) with automatic AI-Based management.

Preemptive zero-day Prevention.

Check Point Cli Commands

Cli commands

Some good cli commands that are useful, I always forget the syntax so it's good to have them in one place.

 

### Cluster XL Debug

# Expert

clish -c "show routed cluster-state detailed"

# clish

show routed cluster-state detailed

##### VPN

### VPN encryption domain overlap

vpn overlap_encdom > temp.txt

### list tunnels

vpn tu tlist -p peer_ip

##### FW

### proxy arp and active local.arp

fw ctl arp -n

### CCC (good script (dangerous))

curl_cli http://dannyjung.de/ccc | zcat > /usr/bin/ccc && chmod +x /usr/bin/ccc

Check Point Endpoint protection - SandBlast Agent

Check out the new features from Check Point with their new SandBlast Agent.

https://youtu.be/rXwCqrDcZJ4

https://www.checkpoint.com/products/endpoint-sandblast-agent/

Also take notice of that with the new firmware for the SMB series SandBlast is also available even on all embedded devices from the 700 to 1400 series.

IA (Identity Awareness) can be a pain, here are some short notes that helps in the troubleshoting. Check the smartlog that there is full access between the AD DC and the FW Gateway as the DCE-RPC uses dynamic high ports to communicate.

## Debug PFP on
pdp d s all all

## Debug PDP Off
pdp debug off

# Check logfile
tail -f /$FWDIR/log/pdpd.elg

# Check if PDPD is running
ps aux -| grep pdpd

# Try to restart it by killing, it will autorestart
killall pdpd

# Verify connectivity to AD (LDAP and WMI) that runs over DCE-RPC. 
Solution Title: How to use test_ad_connectivity to troubleshoot AD Query connectivity.
Solution ID: sk100406
Solution Link: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100406

# Check pdp
pdp connections pep

# check pep
pep s pdp a

# View and control the AD Query (ADQ) status.
adlog a dc - Displays a table specifying which Domain Controllers this Security Gateway is connected to, their connectivity status and the number of events fetched in the last hour

adlog a query all - (or 'adlog a q a' for short) - Displays all of the identity information currently known by AD Query (ADQ)
If this shows error kill the pdpd and verify that it restarts. see above

adlog a query ip 1.1.1.1 - (or 'adlog a q i 1.1.1.1' for short) - Displays the information currently known for 1.1.1.1

Export Checkpoint policy to HTML or XML format

Even if the SmartDashboard console is fantastic sometimes you need to play with the ruleset in different formats.

Try the Web Visualization Tool from Check Point

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk64501

Note: You don't have to reboot your computer as the last step in windows, you can temporarily add the path manually. I hate to reboot.

c:\Users\admin> set path=%path%;your_path_to_application 

tcpdump of SYNners

Shows a list of the top 10 Source IP-addresses that starts a new TCP connection (SYN).

# tcpdump -nnt -i Lan1 "tcp[tcpflags] & (tcp-syn) != 0" and "tcp[tcpflags] & (tcp-ack) == 0" >/var/log/tmp/lan1_syn.txt

# awk '{print $2}' /var/log/tmp/lan1_syn.txt | sed 's/.[^.]*$//'| sort -n | uniq -c | sort -n | tail -n10

LDAP Account unit - SSL fingerprint

when using secure channel on port 636 for the LDAP servers the encryption is verified by a Fingerprint against the AD servers certificate. When this certificate is updated in AD you must 'Fetch' a new fingerprint or this connection will not continue to work.

This could be a complicated task to know about and remember.

Solution:
CP solutions is to simply delete the fingerprint and leave that field blank, now you would never have this problem. The downside is you have an increased risk for man-in-the-middle attack.

Another solution would be to have 1 AD server with higher priority and keep that on standard port 389 not encrypted. Then monitor the log for traffic for that host, then you know you have problem with a encrypted AD server. This is also a security risk since all user password will be sent in clear text. So in my mind the first solution is a better choice.

Nagios plug-in Checkpoint

check_cpfw1_v3 is a really good plug-in for checking your cluster status, your management server and other things, I have used it for several years with success.

Nagios plug-in

Status of cluster interfaces is displayed as "Partially up"

Does SmartView Monitor show this randomly for interfaces, or the output from 'cphastat -f all'?
Don't worry this is only that the status of cluster interfaces is checked incorrectly and the hotfix from CP is only cosmetic, I got this confirmed the other day in a chat session with CP.

Solution ID: sk106488
Solution Link: sk106488

"NAT Hide failure - there are currently no available ports for hide operation"

Today we finally hit the wall and run out of available free ports for NAT. In my case this was an expected error to occur sooner or later due to too many hosts hiding behind the same IP.

We solved this incident by changing the hide_max_high_port from 60.000 to 50.000 in the DB using GuiDBtool and then installed the policy. This gave us additional 10.000 ports for hide NAT.

Some useful hints to troubleshoot:
fw tab –t connections –f –u | awk ‘{print $9”,”$11”,”$13”,”$15”,”$43}’ > /tmp/connections.txt

Summary - top 20 sources
awk -F"," '{print $1}' /tmp/connections.txt | sort -n | uniq -c | sort -rn | head -20

Summary - top 20 destinations
awk -F"," '{print $3}' /tmp/connections.txt | sort -n | uniq -c | sort -rn | head -20

From R77.30 You can check the allocation
[Expert@HostName]# fw ctl get int fwx_nat_dynamic_port_allocation


Solution ID: sk103656
Solution Link: sk103656 

Other good resources for this:
Connections with Hide NAT are dropped during policy installation due to NAT port allocation failure when CoreXL is enabled
sk86401

NAT table reaches its maximum capacity on ClusterXL, which causes traffic issues
sk36708

Load on Module Failed - R77.30 GAIA

Recently several GAIA R77.30 cluster has failed with "Load on Module Failed" on policy installation and then the cluster members have become in 'down' state and stopped run trafic.

According to Checkpoint R&D this is a bug in Aplication Control and the only solution so far is to disble that blade. Contact Checkpoint to retrieve a hotfix.

Checkpoint OPSEC LEA Splunk

If you intend to index your Firewall logs into Splunk, consider the size. Normally indexed logs in Splunk is half the original size but in this case, because the Checkpoint format is in binery, the log ends up 3 times as big.

With that in mind, and with Smart Log actually working so good, I wouldn't index all logs but only the Management logs.