In checkpoint we have three types of packet capture tools as following :
- FW Monitor
- TCP Dump
- fw ctl zdebu
- FW Monitor – Check Point’s FW Monitor is a powerful built-in tool for capturing network traffic at the packet level. The FW Monitor utility captures network packets at multiple capture points along the Firewall inspection chains. These captured packets can be inspected later using the Wire Shark.
- Anything related to policy installation or policy unloading on Security Gateway, will cause FW Monitor to exit.
- It is supported to run only a single instance of FW Monitor at any given time.
- Do not modify Check Point kernel tables used in the security policy while FW Monitor is running, otherwise unexpected behavior may result (including a system crash).
- Packets are defragmented as they leave the Security Gateway in both the inbound and outbound directions.
- If SecureXL is enabled on the Security Gateway, then FW Monitor and tcpdump will show only the non-accelerated packets (e.g., ‘TCP SYN’ will be shown, and ‘TCP ACK’ will not).
Important Note: Traffic captures can be misleading when working with SecureXL since both FW Monitor and Tcpdump do not always show ‘real’ packets that are going out to the network. This is related to the way the SecureXL kernel driver is attached to the network adapter itself. When using SecureXL to confirm whether packets are being handled correctly, either capture the traffic on the directly connected router / switch, or disable SecureXL.
In many deployment and support scenarios, capturing network packets is an essential functionality. The tcpdump / snoop utilities are normally used for this task. The FW Monitor utility provides an even better functionality, but omits many of the requirements and the risks associated with these tools:
- No Security Flaws
tcpdump / snoop are normally used with NICs in promiscuous mode. Unfortunately, promiscuous mode allows remote attacks against these tools. Check Point’s FW Monitor does not use promiscuous mode to capture packets. In addition, most firewalls’ operating systems are hardened. In most cases, this hardening includes the removal of tools like tcpdump / snoop, because of their security risks.
- Available on Firewall Installations
FW Monitor is a built-in tool that does not need a separate installation, or licensing.
- Multiple Capture Positions within the Firewall Kernel Module Chains
FW Monitor allows to capture packets at multiple capture positions within the Security Gateway kernel module chains, both for inbound and outbound packets. This enables to trace a packet through the different layers of the Security Gateway.
- Same Tool and Syntax on All Platforms
FW Monitor is available on all different platforms. tcpdump / snoop are often platform-dependent, or have specific “enhancements” on certain platforms. FW Monitor and all its related functionality and syntax are identical across all platforms.
Normally, Check Point kernel modules are used to perform several functions on packets, such as filtering, encryption and decryption, QoS, etc. FW Monitor adds its own modules to capture packets. FW Monitor can capture all packets that are seen and/or forwarded by the Security Gateway.
|1||Inbound||Before the inbound FW VM||Pre-Inbound||“i”|
|2||Inbound||After the inbound FW VM||Post-Inbound||“I”|
|3||Outbound||Before the outbound FW VM||Pre-Outbound||“o”|
|4||Outbound||After the outbound FW VM||Post-Outbound||“O”|
(*) The traffic direction (inbound/outbound) relates to each specific packet, and not to the connection.
Disable SecureXL for capturing proper logs:
- If you have SecureXL enabled, it fast switches the packets and won’t show you all the detailed logs that you would like to see in your captures. You can disable SecureXL temporarily, if you want to inspect packets at that granularity (i.e ‘I’ and ‘o’). In my experience, disabling SecureXL hasn’t been a problem* and I haven’t seen any performance impact as such.
Right before the capture, turn off SecureXL on the gateway:
Immediately after the capture, turn on SecureXL on the gateway:
To turn on/off SecureXL on multiple VSXs at once:
fwaccel on -a fwaccel off -a
- Ensure that you re-enable after you are done capturing the logs.
Be aware that SecureXL does affect how the traffic passes through the firewall and only disable it if you are 100% sure of what you’re doing. Do it at your own risk, I do not take any responsibility for anything going wrong with this as it does affect the live traffic immediately.
Display all 8 inspection points (iIoO) for a complete two-way traffic on the console:
For specific flow:fw monitor -e ‘accept (src=10.1.1.1 and dst=184.108.40.206) or (src=220.127.116.11 and dst=10.1.1.1);’ -m iIoOORFor specific IP:fw monitor -e ‘accept (src=10.1.1.1 or dst=10.1.1.1);’ -m iIoO
Display 4 inspection points (iO) for a complete two-way traffic on the console:
fw monitor -e ‘accept (src=10.1.1.1 and dst=18.104.22.168) or (src=22.214.171.124 and dst=10.1.1.1);’ -m iO
- Note that we are only gripping iO, that means you are not looking for what is going on at the post-inbound (I) and pre-outbound (o) inspection points and just trying to get fewer output to see if it actually leaves the egress interface or not.
Saving fw monitor logs to a .pcap file to analyze in wire shark:
fw monitor -e ‘accept (src=10.1.1.1 and dst=126.96.36.199) or (src=188.8.131.52 and dst=10.1.1.1);’ -m iIoO -o wireshark.pcap
- By default, the capture file is saved to the /home/admin directory.
- Use WinSCP to access the Security Gateway and copy the file to your local drive to it in Wire shark.
|Ctrl+C||This is the break sequence|
|-e||Custom expression. Sets the filter for fw monitor.|
|-o||Writes the raw packet data output to a file.|
|Captures only the number of inbound (ci) and outbound (co) packets. This is useful if you have many packets going between a source and destination and the break sequence can take time to stop those captures.-vSpecifies the virtual device where the fw monitor needs to run|
2. TCP Dump – TCPDUMP is a powerful tool for debugging on checkpoint, tcpdump feeds directly to the screen packets crossing an interface, if dumped to a file TCPDUMPS can be read by wire shark. you need to be in expert mode to invoke TCPDUMP.
Some Examples of TCPDUMP I have used
tcpdump -w capture.pcap -i eth-s1p2c0 host 10.1.1.1 and host 184.108.40.206 tcpdump -nni any –
host 10.1.1.1 -w capture.pcap tcpdump -nni any host 10.1.1.1 and host 220.127.116.11 -w capture.pcap
Capture your output in pcap format to open in wire shark
tcpdump -i eth1 src 10.1.1.1 and dst 18.104.22.168 – for specific source and destination
tcpdump -i mgmt host 192.168.1.1
Please refer below article for more TCP dump syntax.
What’s the difference between TCP Dump and FW Monitor ?
Tcpdump displays traffic coming or leaving to/from a firewall interface while FW monitor would also tell you how the packet is going through the firewall including routing and NAT decisions.
It captures traffic at 4 important points in the firewall namely i, I, o & O. You would see them in the capture in the same sequence.
i – Preinbound, just where the packet is received on the interface. If you see only this then the packet is dropped by address spoofing or the access rule.
I – Postinbound, where the packet has gone across the incoming interface. If you don’t see the next line in capture after this at ‘o’, you could infer that it’s a routing issue.
For both i & I the interface is the incoming, where the packet enters the firewall.
o – Preoutbound, the place where the packet is received at the exit interface within the firewall. If this is the point beyond which the capture is not seen, then you may need to check NAT.
O- Postoutbound, If you see this then make you are sure that the packet has left the firewall and the ACL, route and NAT all are working as expected.
FW Monitor -e “accept src=10.1.1.201 or dst=10.1.1.201;” -o monitor2.out
It captures at position i & O of firewall monitor, and you can be sure the traffic has left the firewall. This is similar to the way captures work on a Cisco PIX/ASA.
So, which one you use ?
Consider you run tcpdump and see the incoming traffic but don’t see the traffic leaving the exit interface. You can guess it’s a routing or a NAT issue. But to make a sure shot without wasting time by looking in routes or the NAT rules you could run FW Monitor and know what the issue is.
3. fw ctl zdebu – fw ctl zdebug” is a power tool that is not exhausted from being used with “fw ctl zdebug drop”. There is not much to be found in Check Point KB or in the documentation. “fw ctl zdebug” is an R&D tool for testing software in development. Therefore, the insert should be used with care. It starts a debugging in the background until it is aborted with CTRL+C. On productive systems it can have a high performance impact. Furthermore, the debug buffer is not the largest.
What happens when you execute! It is a macro that executes the following commands:
fw ctl debug -buf 1024
fw ctl debug [The option behind “fw ctl zdebug”]
fw ctl kdebug -f
[Wait until CTRL+C is pressed]
fw ctl debug 0
Here are some good examples for debugging:
fw ctl zdebug + packet
fw ctl zdebug + packet | grep -B 1 TCP |grep -B 1 “(SYN)” <<< change SYN-ACK,ACK,FIN,… and/or UDP,TCP…
fw ctl zdebug + all |grep -A 1 “Monitor” | grip “22.214.171.124” <<< change IP address
fw ctl zdebug + all |grep -A 2 “Monitor”
fw ctl zdebug + sync
fw ctl zdebug + conn |grep “After VM:” |grep “(SYN)”
fw ctl zdebug + xlate
fw ctl zdebug + monitorall <<< use with host IP “| grep 126.96.36.199” or network range “| grep 1.1.”
fw ctl zdebug + monitor <<< use with host IP “| grep 188.8.131.52” or network range “| grep 1.1.”
fw ctl zdebug + filter conn | grep -A 8 “rule 1” <<< change rule number – show connetions to rule xyz
fw ctl zdebug + filter monitor | grep -A 8 “rule 2” <<< change rule number – show connetions to rule xyz
Attention, if you turn on debugging, this will affect the performance of the firewall.
Please find useful reference links