Table of Contents
The Need for Unified Policy
- Policy Granularity & Control multiple blades can be configured within the same rule
- Simplicity - one Policy to Manage Everything
The Check Point Unified Policy
Check Point's latest firewall innovation brings the industry's strongest access control to organizations of all sizes. You can easily create access policies which combine capabilities of blades such as traditional FireWall, Application Control, Content Awareness, Mobile Access and more.
For information about Unified Policy, refer to the "Creating an Access Control Policy" section in the Next Generation Security Gateway R80.10 Guide.
Process Flow Diagrams and Description
Unified Policy Inspection Diagram
Blades (e.g: Application Control\Content Awareness) contain Classifiers that deal with traffic classification. Rule matching is done with the classification output.
*Blades may have multiple Classifiers.
Classifiers attach tag/object IDs to traffic.
Classifier notifies the Manager regarding matched objects (Application\Files\Zones\etc). The matched object is called a CLOB (Classification Object). (CLOB is a compound of: Type, ID, additional info) (Examples of CLOB Types: Source Network, Destination Network and Service in FW1 Blade)
All Classifiers are implemented as CMI_LOADER applications.
Classifier examples: Network (FireWall-1), Identity, Application Control, URL Filtering, Content Awareness
Saves rulebase matching state and classification objects (CLOBs).
A Transaction represents one request-response.
A Transaction contains classification collections objects (Observers) for special flags handling.
A Connection (Unified Policy connection) contains Transactions.
A Unified Policy Connection is stored in the Connection table.
CLOBS are distributed to a Publisher-Observer system (via the Manager)
Mediator between other components
Responsible for the whole rule base execution process.
Creates connection/transactions, as required.
Column based match:
- First column (Usually destination) adds all rules matching its column to the possible rules list.
- Consecutive columns filter out all rules not matching their column from the possible rules list.
- When all columns have finished their matching, the first possible rule is the matched rule.
Column match requires specific CLOB types (e.g: Application, Security Zone, Dynamic Object, file type, AccesRole, etc.)
- In case CLOB type is not available, column will return with Need more data state until relevant CLOB type is available.
- Status: Possible, Match, No Match
- CLOB types that are needed to complete the match (e.g: Application, Security Zone, Dynamic Object, file type, AccesRole, etc.)
Unified Policy Troubleshooting
Understanding Possible Match
What is possible/final match?
Possible match is the status in which the rule base needs more data in order to finish matching. This means a "required for match" clob was not reported yet.
Final match is the status in which the first "possible rule for match" is fully matched (only occurs when all "required clobs for match" of this rule are reported)
How do we identify a Possible Match in the debug?
You can see in the SUMMARY section:
up_rulebase_execute_match: [SUMMARY ffffc20034753df8] POSSIBLE dir 0,
10.101.0.2:59150 -> 126.96.36.199:80, IPP 6;
up_rulebase_execute_match:  'Network' (0): POSSIBLE;
Why did you get "Possible Match"?
Before the SUMMARY section, you can see something like this:
"column Destination returned need more data. Clob type 20 is not ready yet"
In order to know what clob type 20 is, you can check in the clobs.conf file:
Another important source of information to use when exploring the "required clobs for match" is the UP tables:
There is a table called "up_X_clob_type_scheme" for each sub policy (layer), where X is the layer id. These tables map a rule number to its "required for match" clobs and its active clobs.
How do you know the sub policy (layer) id?
Let us look at our SUMMARY section:
up_rulebase_execute_match: [SUMMARY ffffc20034753df8] POSSIBLE dir 0, 10.101.0.2:59150 -> 188.8.131.52:80, IPP 6;
up_rulebase_execute_match:  'Network' (0): POSSIBLE;
The marked number is the sub policy (layer) id. In our case it is "0" (called "network" layer).
Finally, look for the table up_0_clob_type_scheme (using fw tab t up_0_clob_type_scheme):
9108 (id of the table)
<RULE : ACTIVE_MASK ,ACTIVE_MASK ,REQUIRED_4_MATCH ,REQUIRED_4_MATCH >
<1 : 08000010 ,00000000 ,08000010 ,00000000 >
<3 : 0c100012 ,00000000 ,0c100010 ,00000000 >
<16777215 : 00000000 ,00000000 ,00000000 ,00000000 >
- 16777215 - no match rule number
- 16777214 early drop optimization rule number
Let us check what is required for a match for rule 3 (<3 above) because rule 3 uses a missing clob, for example:
0c100010 in binary 1100000100000000000000010000
(Note: The position of the active bits indicates which clob types are required.)
The "required for match" clob types for rule 3:
4 - CLOB_TYPE_SERVICE
20 - CLOB_TYPE_DESTINATION_DOMAIN
26 - CLOB_TYPE_PROTOCOL
27 - CLOB_TYPE_ SERVICE_APPLICATION
In our example, at this point, inadequate information about "destination domain" was received (as shown above), and it is required for rule 3. That is the reason you could not "solve" the destination column and ended up with "Possible Match".
Understanding Early drop optimization
What is early drop optimization?
Dropping connection before there is a final rule match.
It happens when all "possible rules for match" are DROP or REJECT.
See explanation in sk111643 - Early Drop - dropping connection before final rule match
How do we identify early drop optimization in the Logs?
Double-clicking on the entry in the Access Rule Name column will open this:
How do you identify early drop optimization in the debug?
up_sub_policy_post_columns_calc: all possible rules have DROP/REJECT action - dropping the connection;
up_rulebase_execute_match: [SUMMARY ffffc200213b8228]
MATCH_ON_DROP_RULES dir 0, 10.11.1.3:37559 -> 184.108.40.206:80, IPP 6;
Connection terminated before detection
What is it?
This occurs when a connection ends (for some reason) before the rule base reaches a full match on a rule. Despite the termination, a matching process is done in order to determine what log (what matched rule) to show. See explanation in sk113479 - Unified Rulebase - "Connection terminated before detection" in log Reason
Note: If the matching seems incorrect, you can turn on a global flag (called "up_log_reason_for_incomplete_match") which will add this reason in the log (if indeed the problem is related to this issue).
How to identify match on implied rule?
You can see in the SUMMARY section in the debug:
up_rulebase_execute_match: [SUMMARY ffffc2003386e228] MATCH dir 1, 172.16.4.89:53042 -> 172.23.39.5:53, IPP 17;
up_rulebase_execute_match: FIRST Implied Rules match 57;
How do you know what rule 57 is?
On the gateway, open the file $FWDIR/state/local/FW1/local.implied_rule and look for rule 57 by searching for "rule_id (57)". You will get:
Each implied rule has this information block.
There are several implied rule layers. "First", "Before Last", "Last", "Before Drop"...
Unified Policy Debugging
Turn on basic debug (General section) and add more debug according to your policy and traffic.