Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
DeletedUser
Not applicable

Unified Policy Column-based Rule Matching

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.

Unified Policy Destination Column Pass 

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

Unified Policy Source Column Pass

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.

Unified Policy Service Column Pass

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.

(1)
19 Replies
Timothy_Hall
Legend Legend
Legend

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
DeletedUser
Not applicable

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

0 Kudos
Gaurav_Pandya
Advisor

This is really good feature. 

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

0 Kudos
Timothy_Hall
Legend Legend
Legend

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Gaurav_Pandya
Advisor

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
Collaborator
Collaborator

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.

0 Kudos
Vladimir
Champion
Champion

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.

0 Kudos
RickHoppe
Advisor

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

My blog: https://checkpoint.engineer
0 Kudos
Timothy_Hall
Legend Legend
Legend

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

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
Brian_Deutmeyer
Collaborator

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?

0 Kudos
Norbert_Bohusch
Advisor

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

0 Kudos
Brian_Deutmeyer
Collaborator

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.
0 Kudos
Ben_Gilles
Explorer

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.

0 Kudos
Brian_Deutmeyer
Collaborator

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
Collaborator

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

Vladimir
Champion
Champion

@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

0 Kudos
DeletedUser
Not applicable

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

0 Kudos
Vladimir
Champion
Champion

@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."

0 Kudos
DeletedUser
Not applicable

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."

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events