Create a Post
Showing results for 
Search instead for 
Did you mean: 

Max Capture Update 1: Taking "Triggered" Packet Captures

This article provides updates for the Shadow Peak "Max Capture: Know Your Packets" self-guided video series that covers taking packet captures on Check Point Security Gateways using tools such as fw monitor, tcpdump, and cppcap.  New techniques and updates for this course will be provided free of charge to all CheckMates users in posts such as this one.

Today's topic has long been a sore spot for Check Point Gateways that some other firewall vendors are able to provide: the ability to take "triggered" packet captures that occur when a certain set of criteria are met and automatically save the capture for later review.  While Check Point gateways do have some limited abilities to take automatic packet captures in response to a Threat Prevention signature being matched, these captures are only helpful for identifying "false positives" and not really useful as a general network troubleshooting tool.  Page 8 of the Max Capture course incorrectly states that "triggered" captures are not possible on Check Point.

However with the recent introduction of Custom Threat Indicators, I have devised a way to essentially force triggered captures using the Threat Prevention blades which I will document in this post.  But first off, why might we need this capability?

The most common scenario is that some random, intermittent traffic is arriving at the firewall and we want to get a packet capture of it.  It could even be arriving at an internal interface of the firewall bearing a source IP address that is completely invalid, making it very difficult to trace its origin.  While we could start a manual tcpdump/cppcap capture and leave it running for a long period of time hoping to catch this traffic, the possible performance and even stability impacts to the firewall using this technique are a definite risk.

However if you suspect in any way that this traffic could be some kind of "phone home" malware communication, or otherwise have some kind of nefarious purpose, I'd strongly recommend enabling the Anti-bot blade and ensuring it is configured to scan this mystery traffic.  The Anti-bot blade is very easy to configure and does a great job positively identifying malicious traffic, so I'd strongly recommend enabling Anti-bot first and see what happens.  The Anti-bot blade is a "subscription" blade that must be repurchased yearly so if you don't have a current license for it, contact your Check Point reseller to obtain a 30-day evaluation license.

1) First off some caveats:

a) The mysterious traffic must be accepted by the Access Control policy, as the capturing mechanism is part of Threat Prevention which is generally applied after Access Control.  So if the mysterious traffic is currently being dropped by your Access Control policy you'll need to add a rule allowing it.  If the mysterious traffic is trying to talk to a site on the Internet, carefully consider the security ramifications of suddenly allowing this traffic through your firewall as it may be trying to exfiltrate confidential data.

b) You must have either (or both) the AV or ABOT blades enabled on your firewall as they perform the actual capture; a subscription-based license is required for these blades.  This same technique will probably work with custom Snort signatures that are part of the IPS blade, but support for Snort seems to be on the way out in favor of the Custom Indicators that we will use.

c) When a triggered capture fires, you will only get the first 100KB of data in your saved capture.  While this amount can be increased I would not recommend it, see here for more information: sk148492: Packet capture for IPS logs with "Prevent" or "Detect" actions does not show the desired n...

d) When a triggered capture fires, another similar capture for the same custom indicator will not be performed for a period of 10 hours by default which is the TP log suppression interval.  Subsequent matches against the custom indicator within the suppression period will also not create separate log entries, but a counter called "Suppressed Logs" will be incremented in the original log entry.  To reset the TP log suppression interval on the gateway and cause a fresh capture to be taken when the traffic happens again, reinstall just the Threat Prevention policy to the gateway (Access Control policy does not need to be included).

e) This technique is not documented or supported by Check Point, and using the TP packet capturing mechanism in this unusual way may cause performance and even stability issues on the firewall, or overwrite needed captures for diagnosis of false positives!  USE AT YOUR OWN RISK!

2) So in our specific example scenario we are seeing highly intermittent traffic arriving at an internal interface of the firewall sourced from many different internal addresses for destination IP address on TCP destination port 22.  First we must ensure that this traffic is allowed by our Access Control policy:



3) We need to create a custom indicator in a .csv file to match the traffic, note all we can specify is an IP address here which can be either source or destination:



4) Next we import the observable into the SmartConsole, note that the Action should probably be Detect not Prevent.  If you set Prevent here the traffic will not be forwarded by the firewall and you'll only get the first packet of the connection in the capture but not see any replies.  This might be an acceptable trade-off if you suspect the mystery connection is attempting to exfiltrate confidential data.



5) Now head to your Threat Prevention policy, and unhide the Source, Destination, and Services columns which are normally hidden and set to Any by default:



6) Create a new Threat Prevention Rule at the top of the policy.  Leave "Protected Scope" set to Any, then populate the Source, Destination, and Services fields as much as possible.  THIS IS VERY IMPORTANT; if the source IP, destination IP and destination port are always the same for the mysterious traffic, FILL IN *ALL* THREE FIELDS HERE!  You should hopefully be able to fill in at least two of the three fields, DO NOT fill in only one field or leave them all set to Any!  Note that either the Source or Destination IP in this rule will need to match the IP address specified in the observable CSV file.



7) Next create a new TP profile and add it to the Action of your new TP rule, ensure that only Anti-Virus is checked on the General Policy screen (Anti-bot will probably work for this as well assuming that "AB" is specified in the .csv file, but I haven't tried it).  Also ensure that "Enable indicator scanning" is checked on the Indicators screen, and that all options are selected in the rule's Track column including Packet Capture.  Note that if you have more than one TP policy layer in your Policy Package (not common), this rule will need to be at the top of all of them to ensure it is matched correctly.





😎 Publish and install both the Access Control and Threat Prevention policies to your gateway and wait for the mysterious traffic to occur:





9) Clicking on the src- file hyperlink in the log card reveals the first 100KB of the connection, or less if the connection did not reach that threshold:



10) VERY IMPORTANT - As soon as you have obtained the capture you need, REMOVE the rule from your Threat Prevention policy specifying the capturing profile along with the Custom Indicator you added and reinstall the Threat Prevention policy to the gateway!

Hopefully you found this article helpful, in the next Max Capture update article I'll cover some odd interactions when fw ctl zdebug + drop and fw monitor -F are run simultaneously along with a solution.  Thanks for reading!

New 2021 IPS/AV/ABOT Immersion Self-Guided Video Series
now available at
0 Replies