R80.20 cheat sheet - fw monitor

[HeikoAnkenbrand]

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 

[David_M_Almas]

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]

[ClaudiaPeter]

-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

[Bob_Zimmerman]

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

[Jan_Boonen]

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?

[_Val_]

@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

[Uri_Lewitus]

fw monitor is thoroughly described in the CLI admin guide

[Bob_Zimmerman]

Several aspects are described in the CLI reference guide, but not all.

Specifically, there are no examples of filters (either INSPECT or simple).

[Uri_Lewitus]

We are adding those "as we speak" 

[Srdjan_B]

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.

[Timothy_Hall]

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.

[HO]

Please add the -F parameter.