Support Center > Search Results > SecureKnowledge Details
ATRG: Unified Policy
Solution

Table of Contents

  • Introduction
  • Process Flow Diagrams and Description
  • Unified Policy Troubleshooting
  • Unified Policy Debugging
  • Related Solutions

 

Introduction

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


Classifiers

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

Connection/Transaction

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.

Observers

CLOBS are distributed to a Publisher-Observer system (via the Manager)

  • The Transaction is a Publisher.
  • The Observer is a unit collecting CLOBs for classification refinement (e.g: CLOB dependency).

    For example:

    Application Observer – collects APPs and URLF Categorization (Application CLOBs)

    Content Observer – collects File types and content CLOBs

  • Observers are registered to CLOB types (one-to-many).

Manager

Mediator between other components

Responsible for the whole rule base execution process.

Creates connection/transactions, as required.

Sends logs.

Rulebase

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.

Matching Output:

  • 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 -> 52.94.237.74:80, IPP 6;
up_rulebase_execute_match: [0] '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:

CLOB_TYPE_APPLICATION 1
CLOB_TYPE_SOURCE_NETWORK 2
CLOB_TYPE_DESTINATION_NETWORK 3
CLOB_TYPE_SERVICE 4
CLOB_TYPE_SOURCE_ACCESS_ROLE 7
CLOB_TYPE_DESTINATION_ACCESS_ROLE 8
CLOB_TYPE_RESOURCES_ID 9
CLOB_TYPE_SOURCE_SECURITY_ZONE 10
CLOB_TYPE_DESTINATION_SECURITY_ZONE 11
CLOB_TYPE_SOURCE_VPN 12
CLOB_TYPE_DESTINATION_VPN 13
CLOB_TYPE_CLIENT_AUTH_ID 14
CLOB_TYPE_LOGICAL_SERVER 15
CLOB_TYPE_XFF_SOURCE_ACCESS_ROLE 16
CLOB_TYPE_SOURCE_DYNOBJ 17
CLOB_TYPE_DESTINATION_DYNOBJ 18
CLOB_TYPE_SOURCE_DOMAIN 19
CLOB_TYPE_DESTINATION_DOMAIN 20
CLOB_TYPE_SOURCE_USER_AT_LOCATION 21
CLOB_TYPE_DESTINATION_USER_AT_LOCATION 22
CLOB_TYPE_SOURCE_USER_LIMITATION 23
CLOB_TYPE_DESTINATION_USER_LIMITATION 24
CLOB_TYPE_PROTOCOL 26
CLOB_TYPE_SERVICE_APPLICATION 27
CLOB_TYPE_MAB_PROTECTION_LEVEL 28
CLOB_TYPE_MAB_APPLICATION 29
CLOB_TYPE_SCADA_APPLICATION 30
CLOB_TYPE_SIP_MGCP_HIDE_NAT 31
CLOB_TYPE_CONTENT_FILE 40
CLOB_TYPE_FILE 41
CLOB_TYPE_CONTENT 42
CLOB_TYPE_DIRECTION 43
CLOB_TYPE_LAST 44

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 -> 52.94.237.74:80, IPP 6;
up_rulebase_execute_match: [0] '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):

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 -> 52.94.237.74: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).

Implied Rules

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:

:accept_outgoing (
          :name (accept_outgoing)
          :src (
                : (GW)
          )
          :dst (
                : (Any)
          )
          :service (
                : (97aeb369-9aea-11d5-bd16-0090272ccb30)
          )
          :inspect_func_name (implied_rule_func_57)
          :action (accept)
          :install (Any)
          :rule_id (57)
          :optimize_drops_support_rule (false)
          :position (first)
          :src6 (
                : (GW)
          )
          :dst6 (
                : (Any)
          )
    )

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.

Description Commands

GENERAL

Light Mode

Turn ON for any rulebase matching process

fw ctl debug 0
fw ctl debug -m UP + info module rulebase connection manager clob log sec_rb vpn address mab
fw ctl debug -m UPIS + info clob
fw ctl debug + drop conn
fw ctl debug -buf 32000
fw ctl kdebug -p time -f > <Output file name>

GENERAL

Full Mode

Turn ON for detailed rulebase matching process

heavy debugging

fw ctl debug 0
fw ctl debug -m UP + all
fw ctl debug -m UPIS + info clob
fw ctl debug + drop log chain conn vm
fw ctl debug -buf 32000
fw ctl kdebug -f > <Output file name>

Rules with Application Add below command lines to GENERAL

fw ctl debug -m APPI + all
fw ctl debug -m cmi_loader + all
fw ctl debug + cmi
fw ctl set int cmi_dump_buffer 1

Rules with Data
Add below command lines to GENERAL

fw ctl debug -m dlpda + all
fw ctl debug -m FILEAPP + all
fw ctl debug -m cmi_loader + all
fw ctl debug + cmi
fw ctl set int cmi_dump_buffer 1

Rules with Access Role
Add below command line to GENERAL

fw ctl debug -m IDAPI + all

UserCheck actions (including Drop with Block message)

User Check has code in both usermode and driver. Usermode debug is saved to $FWDIR/log/usrchkd.elg

Do not forget to run usrchk debug off when done.

Add below command line to GENERAL

fw ctl debug -m UC + all

Turn on usermode debug:
usrchk debug set all all

HTTP traffic - deep packet inspection
Add below command line to GENERAL

fw ctl debug -m WS + info pkt_dump module connection session policy spii address

TCP level debug - deep packet inspection

very heavy debugging

Add below command line to GENERAL

fw ctl debug + tcpstr

Failure of Install Policy

Do not forget to unset all TDERROR when done.

Turn on usermode debugging:
export TDERROR_ALL_ALL=0
export TDERROR_ALL_fwapp=5
export TDERROR_ALL_upapp=5
export TDERROR_ALL_db=5
export TDERROR_ALL_mgr=5
export TDERROR_ALL_sna=5
export TDERROR_ALL_load=5

Turn on kernel debugging:
fw ctl debug 0
fw ctl debug -m UP + info rulebase policy module manager
fw ctl debug -m UPIS + all
fw ctl debug + filter cmi
fw ctl debug -buf 32000

fw -d fetchlocal -d $FWDIR/state/__tmp/FW1/ >& $output_filename
fw ctl kdebug -f >> $output_filename

 

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment