- Products
- Learn
- Local User Groups
- Partners
- More
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
Join our TechTalk: Malware 2021 to Present Day
Building a Preventative Cyber Program
Be a CloudMate!
Check out our cloud security exclusive space!
Check Point's Cyber Park is Now Open
Let the Games Begin!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
Introduction |
---|
This overview gives you an view of the changes in R80.20 fw monitor. All R80.10 and R80.20 changes are contained in this command overview (cheat sheet). You could download the cheat sheet at the end of this article as a PDF file. Unfortunately not all information for R80.20 is included in SK30583 "What is FW Monitor?". Therefore this small overview with the changes. I hope it helps you.
Cheat Sheet |
---|
Download |
---|
Download: R80.20 fw monitor cheat sheet PDF (new R80.20 version)
Chapter |
---|
More interesting articles:
- R80.x Architecture and Performance Tuning - Link Collection
- Article list (Heiko Ankenbrand)
Cheat Sheet:
- R80.x cheat sheet - fw monitor
- R80.x cheat sheet - ClusterXL
Copied from sk30583:
Note: Relevant for R80.20 from Jumbo Hotfix Accumulator for R80.20 (Take 73)
[-w whole packet] [-F simple filter "{src IP},{src port},{dst IP},{dst port},{protocol num}"] [-U clear]
-F: any hint how to filter for networks instead of single IP addresses?
10.1.1.0/24 --> doesn't filter at all
10.1.1.0/255.255.255.0 --> "Set operation failed: failed to get parameter simple_debug_filter_saddr_1"
10.1.1.0,24: --> oviously not possible
Check Point's documentation is vague on exactly how the filter should look. They include braces. That looks like JSON. Should the filter be in the form of a JSON object? A list of objects? Can't tell, since they don't include any examples.
I just tested and this exact form worked for me:
[Expert@MyFW ACTIVE]# fw monitor -F "10.20.30.40,0,0,0,0"
FW monitor will record only ip & transport layers in a packet
For capturing the whole packet please do -w
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_0] bond1.2345:i[44]: 10.20.30.40 -> 192.168.128.64 (TCP) len=1000 id=45972
TCP: ***** -> ***** ...PA. seq=******** ack=********
[vs_0][fw_0] bond1.2345:i[40]: 10.20.30.40 -> 192.168.128.64 (TCP) len=40 id=45973
TCP: ***** -> ***** ....A. seq=******** ack=********
[vs_0][fw_0] bond1.2345:i[40]: 10.20.30.40 -> 192.168.128.64 (TCP) len=40 id=45974
TCP: ***** -> ***** ....A. seq=******** ack=********
monitor: caught sig 2
monitor: unloading
Even more vague is the answer to how we can capture traffic post-outbound O without the need to add another filter with the NATted address.
As described in the examples on the bottom of the SK:
fw monitor -F "x.x.x.x,0,y.y.y.y,0,0" -F "y.y.y.y,0, x.x.x.x ,0,0"
Filter 1: source ip: x.x.x.x, source port: any, destination ip: y.y.y.y, destination port: any, protocol: any.
Filter 2: source ip: y.y.y.y, source port: any, destination ip: x.x.x.x, destination port: any, protocol: any.
This does not take into account a (possible) NAT translation and thus will not capture/display it.
Any ideas?
@Jan_Boonen Use AND expression and include NAT-ed address, if you know it. Alternatively, use source or destination alone for the IP that is not NAT-ed
fw monitor is thoroughly described in the CLI admin guide
Several aspects are described in the CLI reference guide, but not all.
Specifically, there are no examples of filters (either INSPECT or simple).
We are adding those "as we speak"
Normally, we can insert inspection points in different parts of the chain (fw ctl chain). But when trying to insert at the very beginning, it complains:
fw monitor -F "x.x.x.x,0,0,0,0" -F "0,0,x.x.x.x,0,0" -pi 0 -ci 10 -co 10
...
monitor: No room for inbound module before SecureXL stateless check
Tried -pi 1 and -pi 3 with messages saying
-pi 1 "monitor: No room for inbound module before SecureXL VPN before decryption"
-pi 3 "monitor: position 5 is already occupied by fw offload inbound"
since it is weekend and utilization is low, I was able to use -p all and I was able to get packets from the very beginning of the chain:
[vs_0][ppak_0] eth***.***:i0 (SecureXL stateless check)[44]: *.*.*.* -> **.**.**.** (TCP) len=60 id=32469
TCP: 35344 -> 443 .S.... seq=e4948974 ack=00000000
[vs_0][ppak_0] eth***.***:i3 (SecureXL lookup)[44]: *.*.*.* -> **.**.**.** (TCP) len=60 id=32469
TCP: 35344 -> 443 .S.... seq=e4948974 ack=00000000
...
However, in R80.40 CLI Reference Guide, it says: The chain module position parameters "-p{i | I| o | O} ..." parameters do not apply to the accelerated traffic, which is still
monitored at the default inbound and outbound positions.
So, if accelerated traffic is not displayed at chain position 0, are we seeing all packets that came in? Is it possible that SecureXL is processing something (possibly dropping it) without us ever knowing it?
Thank you.
BTW, it was done on R80.20 with JHF take 160.
You can't specify a chain position in combination with -F. When using -e you are basically writing inspection code that is inserted as new chain modules into the chain sequence of modules in the F2F path to grab the traffic; in that case you can most definitely specify chain positions. However all the -F option is doing is setting a kernel debug in the SecureXL Implementation Module (sim) to grab packets matching the -F criteria as they go by, whether they are accelerated or not. All inbound traffic must pass through SIM first no matter the processing path (SXL, PSLXL, F2F, etc.) or whether it gets dropped somewhere later, so you should see everything with -F. Unfortunately you don't have the full suite of INSPECT capabilities for what is essentially a kernel debug via -F, which is why the matching criteria is so restrictive with that fw monitor option.
I was initially certain that using fw monitor -p all (DON'T RUN THIS ON A PRODUCTION FIREWALL) would only show traffic in the F2F path, but it looks like that is not the case on R80.40:
So next I tried stepping through with commands fw monitor -pi 1, fw monitor -pi 2, etc. trying to see the earliest point a successful insertion could occur without getting a "no room" message as reported by @Srdjan_B. It seemed to succeed with fw monitor -pi 7 which is still located inside the SecureXL sequences, but in reality it just stuffed the fwmonitor module at the equivalent of "i" (module #14) in the F2F path:
So once again it is not possible to use the INSPECT filters in fw monitor with anything other than -e, and -F with its restrictive syntax must be used if traffic is not F2F. The lone exception seems to be fw monitor -p all (DON'T RUN THIS ON A PRODUCTION FIREWALL) which is somehow getting its hooks into the early SecureXL chain sequences on the Firewall Worker, but there doesn't seem to be any further granularity available for insertion points that early.
Please add the -F parameter.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY