Using "fw monitor" command is even easier than you think

Arguably, fw monitor is one the most important troubleshooting tools with Check Point firewalls. It is flexible, extremely powerful and versatile. It is also one of the most frequently misused tools. There is a single compelling reason for both cases.

fw monitor uses INSPECT, an internal C-like language that is used by Check Point to build kernel-based security. Same language is used to define any object, action, protocol and even IPS protections. It is also a huge piece of knowledge that Check Point never shared in full.

Here is a conundrum. You can write extremely complex and very effective filter with fw monitor. The only condition is, you need to possess an intimate knowledge of INSPECT. In other words, to do so, you have to be a Check Point developer.

There are some documents and references about fw monitor usage. There is a well known long-read from 2003, for example. The doc is compelling, very details and yet mostly useless on the field. Who would use IP header offset to filter traffic, really? I have never done that in more than 17 years of working with CP FWs.

There is also a fantastically well written SK30583. It has quite nice set of examples, large list of filtering options and a very elaborate syntax explanation.

However, there is something even better. Imagine you are stuck in a datacenter dungeon, no internet access and some pressing matter to resolve. Where can you find a good reference to fw monitor syntax and options, if SecureKnowledge is not available, and your personal notes are at the office on your desk?

Well, you do not have to pull your hair out. You are working with Check Point FWs, remember? Just get on CLI and look into $FWDIR/lib/fwmonitor.def on one of the firewalls.

The file has a list of all fw monitor macroses you can use.

For example, remember my line from the previous post about kernel debug filter? Here it is:

fw ctl debug -e "accept host(8.8.8.8);" 

I use here host macros that automatically generates filter for source and destination IP addresses.

Now, this is how this macros is described in fwmonitor.def file:

#define host(_addr) (ip_src=(_addr) or ip_dst=(_addr))

Also, remember how annoying it is when your own SSH session is creeping into fw monitor output when you are trying to run a trace? Here is a no_term macros:

#define no_term ((not ssh) and (not telnet)) /* remote terminal */

And just in case you ever forget the rest of traffic filtering syntax, you can always look into $FWDIR/lib/tcpip.def file for reference.


The author thanks Sergei Shir, Check Point SecureKnowledge content developer, for his dedicated work and references provided in the comments to the previous post in this blog.

New certification manager at Check Point Education Services

Everybody, meet Jason "Tug" Tugwell, new Check Point Certification manager.

Jason is the new face in Education Services, but not at Check Point. He joined Check Point in 2007 as a tech advisor and then was leading different TAC teams at Dallas, helping out customers.

I am sure, he will make a difference in Check Point certification process.

Personally, I am looking forward to see more refined technical real world inspired question in the new certification exams.

All the best from here. Tug us well, mister Tugwell.

Kernel debug filter that is almost never used

Some of us are running kernel debug on Check Point FWs from time to time, especially students of my Advanced Check Point Troubleshooting Course.

There are many tricks and best practices, but one that I love the best is applying INSPECT traffic filter on the output. And guess what, this one is rarely used.

The issue is simple. When running FW kernel debug, we are trying to extract as much debug information as possible. Usually Check Point support engineers ask customers to run something like "fw ctl debug all". I assume they find filtering out gigs of text files very rewarding.

On my side, I am trying to keep things simple and controllable, hence enabling only necessary debug flag. Yet, by default you get all kernel output for all packets traversing your FW during the debug session, and that might be still too much when trying to debug a single faulty connection.

This is how "fw ctl debug" help output looks like in practice:

Usage: 
fw ctl debug [-d ] [-s ""] [-v (""|all)] [-k] [-x] [-m ] [-e expr |-i | -u] [+|-]

I have highlighted there the interesting part. If you ever used fw monitor, you know -e flag already. It stands for expression, a traffic filter based on INSPECT syntax.

Same deal here. You can actually limit quite a lot of unnecessary debug printout by filtering only the messages related to some particular traffic.

For example, adding
fw ctl debug -e "accept host(8.8.8.8);" 
to your kernel debug commands you will get output related to traffic to and from the famous Google DNS server.

This saves lots of time and effort when analysing the debug info afterwards. As all the other parameters, this filter is reset with fw ctl debug 0.

Have fun.

Check Point support - are you happy with it?

One of the recurring complaints around Check Point is about support. Every third post at CPUG mentions CP support being slow, ineffective, sometimes calling names.

Even in the latest Gartner Magic Quadrant for Enterprise Network Firewalls 2016 report, one of the cautions says:

 -  Gartner receives anecdotal reports from clients about support issues, mostly focused on the time it might take to get appropriate escalation. Gartner analysts recognize that this is inevitable for a vendor of this scale, but note that the frequency of issues is, of late, slightly higher than its direct competitors. Check Point has recently extended the support quality metrics it monitors to address this issue and monitor its progress.

I am personally not convinced Check Point support is the ultimately worst of all. I have seen some cases with other security and technology vendors and can say one's support experience with Check Point could sometimes be seemed as swift and easy in comparison.

I have also seen quite a few positive examples about Check Point support, mostly with more expensive Diamond plans, but also with some basic cases.

Support experience is a function of many factors: severity of an issue, an understanding of one's own security system and networks, and of course, an understanding of what to expect in the first place. I have seen many occurrences when SLAs and timing were completely misunderstood by a customer. I have even published a quick guide for support plans in 2015.

Granted, support can always be better. There are no magic bullets and "fix all" checkboxes, although sometimes Check Point seems to do miracles while fixing your things.

What is your own experience with Check Point support? Is it adequate, good, bad, mediocre, fantastic? What would you improve? What are you happy with?

Please do not hesitate to share in the comments.