Unified Policy Column-based Rule Matching

[DeletedUser]

Under the hood in R77 the policy matching process for Application Control, anti-malware, DLP (Data Loss Prevention and NAT (Network Address Translation) is done using a column-based search process. In R80.10 this process is now used to match the connection against the unified policy. The resulting match is still the first rule to match from the top-down. This has not changed. Only the process for finding the match has changed.

For example consider a firewall policy with service objects defined in the Services & Applications column trying to match an SMTP connection. We match the SYN packet in the three-way handshake. The search order is;

• Destination column
• Source column
• Service column

We search each column in the policy. At the end of the search we update a matched rules array. In each pass some rules can be eliminated from the matched rules array. When the rule base is large, this results in a more efficient matching process.

Consider a policy with only the firewall enabled and the rulebase match of the initial SYN packet in the TCP three way handshake from a client at 192.168.169.1 connecting to the SMTP service listening on port 25 of a mail server at 192.168.170.1.

In the destination column pass of rules 1 through 6, rules 1, 2 and 3 are eliminated from the matched rules array.

 

In the source column pass of rules 1 through 6, rules 4 and 5 are still possible matches in the matched rules array.

In the service column pass of rules 1 through 6, rule 4 is eliminated from the matched rules array and rule 5 is a final match.

For those who are familiar with Check Point chain modules, there isn’t a new Unified Policy chain module. The Unified Policy is enforced for the first packet in the VM chain module where the security rulebase was enforced before. In a Unified Policy rulebase with Application Control and Content Awareness enabled and a more complex policy there may not be a final match on the SYN packet. The rulebase will be executed on parser contexts in subsequent packets.

In Classifying Traffic to Match Unified Policy Column Objects we'll cover a more complex example like that in an example rulebase similar to the R80.10 online help rulebase matching example 3.

[Timothy_Hall]

Excellent, been waiting for some official post/documentation about this feature.  This was going on in R77 too? Which specific versions?

Thanks!

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[DeletedUser]

Good question. Not sure exactly, but when you look at the App Control ATRG, sk73220 (Advanced Access), you'll see references to the new rule base and to the Unified Policy in R80.10.

thx,

bob

[Gaurav_Pandya]

This is really good feature. 

Is it automatically enabled? or we need to enable this feature?

[Timothy_Hall]

Enabled by default in R80.10, the recommendation in my book to get the most out of this feature is to avoid using "Any" in the Destination column as much as possible in all your policy layers.  NAT is the only exception as it has its own unique rulebase lookup caching system (fwx_cache).

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Gaurav_Pandya]

Hi Tim,

I was reading your book and came to know this feature. thanks for sharing information.

Really great book with detailed explanation.

[Daniel_Westlund]

I wonder if it would be worth the trouble to change a rule with Destination Any into a rule that negates RFC 1918 IPs, for rules where the traffic is intended to reach the Internet but not the internal networks?  Or if rules with negations are too ugly and it's not worth the trouble?  There is no Internet cloud object available for Security rules.

[Vladimir]

You can use one of these variants:

Where "All Internet" is actually:

Or better yet, create a group with exception, add "All Internet" to it as a main component and RFC1918 as well as you public IP DMZ ranges as exceptions and use that group as a destination in the Access Control policy.

[RickHoppe]

Read this thread for defining the internet. https://community.checkpoint.com/thread/6099-properly-defining-the-internet-within-a-security-policy

[Timothy_Hall]

Negations are generally fine, although I tended to avoid them in R77.30 management and earlier.  Many times in the past I'd be staring at a rule wondering how the heck certain traffic hit that rule (or missed it) but not noticing that portions of it were negated. Thankfully in R80+ management Check Point made negated cells far more noticeable:

As mentioned in my book anything but "Any" in the Destination/Source/Service columns (including negations) will help to reap the performance benefits benefits of Column-based matching.

--

CheckMates Break Out Sessions Speaker

CPX 2019 Las Vegas & Vienna - Tuesday@13:30

[Brian_Deutmeyer]

In relation to rule base matching...Overly simplified, I have the following rule (rule #20) that looks like this:

SRC:me  DST:1.1.0.0/16 SRV:TCP443

In order to break apart this rule to be more restrictive, I know that my machine is accessing a resource in this network (server.domain.com), whose IP changes hourly in this network, so I create a new rule (rule #10) that utilizes a domain FQDN object and looks like this:

SRC:me  DST:server.domain.com [a FQDN Domain Obj]  SRV:TCP443

After installing policy, the traffic is still matching my IP based rule (what was rule #20) instead of the FQDN rule.  Does rule base matching evaluate IP based rules before domain object (FQDN type) rules?

[Norbert_Bohusch]

No, but can you share a nslookup from relevant gateway for the used FQDN.

[Brian_Deutmeyer]

So in this case, the client and the gateway show the same answer for nslookup:

# nslookup server.domain.com

Non-authoritative answer:
Name:   server.domain.com
Address: 1.1.190.138

The logs says the connection is matching the IP based rule further down in policy instead of the FQDN rule.

[Ben_Gilles]

Curious as well, could you send a screenshot of the FQDN object definition?  

Based on what you have here:

SRC:me  DST:server.domain.com [a FQDN Domain Obj]  SRV:TCP443

I am curious if you have included in the Domain Object Definition the preceding ".", as in ".server.domain.com".  The preceding "." is required to act as a FQDN object vs. a legacy style domain object.

We have had success using the FQDN objects, and matching correctly.  Just a thought as to why it may be failing based on what we saw here.

[Brian_Deutmeyer]

We do have the preceding "." configured and the FQDN box is checked.  We also use FQDN objects successfully where there isn't a matching IP rule further down in policy.  This happens to be a case where we have a larger IP based rule that we want to migrate to all FQDN objects.  When I dump the dns_reverse_cache_tbl, I see the IP in question, it just seems to be matching IP based rules before my FQDN rule.  And to make this weirder, I see some flows matching my FQDN rule and some the IP based rule.  

[Brian_Deutmeyer]

Just to follow up... Installing JHF154 resolved my issue.

[Vladimir]

@DeletedUser , the title of this post is "Unified Policy Column-based Rule Matching", but I'd appreciate it if you ca clarify how same logic is not applicable to a Non-Unified policy with the single Firewall blade enabled.

Thank you,

Vladimir

[DeletedUser]

As I understand it, the unified policy uses the column-based match using subsequent packets in a connection when more security features are enabled. With only firewall enabled it's a simple top down, first match of the first few packets of a connection during the connection setup. The first falls through to more complex inspection that relies on pattern matching required to identify an SMTP application signature, for instance. While the latter, firewall only, is done comparing the tuple against the rulebase. 

hth,

bob

[Vladimir]

@DeletedUser , thank you for the prompt reply. My confusion stems in part due to you explicitly mentioning "Firewall only enabled in the depicted scenario." Given that and, with packet mode showing identical behavior, it seems that the column-based processing is working in the Firewall only policies or layers:

"For example consider a firewall policy with service objects defined in the Services & Applications column trying to match an SMTP connection. We match the SYN packet in the three-way handshake. The search order is;

• Destination column
• Source column
• Service column

We search each column in the policy. At the end of the search we update a matched rules array. In each pass some rules can be eliminated from the matched rules array. When the rule base is large, this results in a more efficient matching process.

Consider a policy with only the firewall enabled and the rulebase match of the initial SYN packet in the TCP three way handshake from a client at 192.168.169.1 connecting to the SMTP service listening on port 25 of a mail server at 192.168.170.1."

[DeletedUser]

Understand how that is confusing. If it helps, would read to the bottom....

"For those who are familiar with Check Point chain modules, there isn’t a new Unified Policy chain module. The Unified Policy is enforced for the first packet in the VM chain module where the security rulebase was enforced before. In a Unified Policy rulebase with Application Control and Content Awareness enabled and a more complex policy there may not be a final match on the SYN packet. The rulebase will be executed on parser contexts in subsequent packets."