Classifying Traffic to Match Unified Policy Column Objects

[DeletedUser]

In a previous post we looked at a simple example of Unified Policy Column-based Rule Matching for the initial SYN packet in the TCP three way handshake from a client connecting to an SMTP service where only the firewall was enabled. Lets look at a more complex example where we need multiple packets to identify the traffic against a Unified Policy with Application Control and Content Awareness enabled in the policy layer.

In R80.10 the unified policy classifies subsequent packets against the column definitions until enough information is known to identify the traffic. Like column-based rule matching as more is known about the connection, then rules are eliminated, optimizing the rule base matching process. Example classification objects are application, access role source, access role destination, content and file.

Consider the example rule base below that is similar to the R80.10 online help rule base matching example 3 for a connection from the InternalZone to the Internet to download an EXE file from a business web site.

Classification starts with the SYN packet in the TCP three-way handshake to a Web services port. Rules 1, 2 and 3 are possible matches. The connection is allowed on rule 3 and allowed to continue.

The CoreXL dispatcher notices the  SYN packet is a first packet and forwards the packet to the fw_worker Context Management Infrastructure (CMI). Unified policy processing begins to classify the packet by creating a list of Classifier Apps that are registered for first packets. Each Classifier App executes on the packet and creates a Classifier Object to be used to match the column definition in the security policy.

Because Application Control is enabled and more packets need to be analyzed in subsequent packets, streaming is needed. Once the TCP three-way handshake completes, then the client sends an HTTP GET to download the file. Consider the following HTTP Headers from the subsequent client request and the server response.

C: GET /download/example.exe HTTP/1.1

C: Host: www.example.com

S: HTTP/1.1 200 OK

S: Content-Type: application/octet-stream

S: Content-Length: 1136132

When checked against the security policy it is determined that application and file classification objects are needed and more packets are needed to complete the policy match. Subsequent packets are handled by the streaming engine. The streaming engine notifies the Classifier to perform the classification. The unified processing waits for information from the CMI.

Streaming, CoreXL and SecureXL technologies have not changed. The streaming engine passes the stream to the Protocol Parser. The Protocol Parser verifies if the protocol is correct or not and provides the result to the CMI. If the protocol is correct the Parser extracts the Context. If the protocol is not correct the CMI may instruct the Parser to extract Context even then. This Context is then executed in the Pattern Matcher to identify the application. The Pattern Matcher tells the result to the CMI. For more information about these NGTP components see Check Point Security Gateway Architecture and Packet Flow (advanced access).

The CMI sends the information describing the result of the Protocol Parser and the Pattern Matcher to the Classifier. The Classification Object is checked against the rule base.

The result of the rule base check is provided to the CMI which then decides to allow or to drop the connection. The CMI generates a log message and instructs the streaming engine to forward the packets to the outbound interface.

This is the process. In our example 3, the rule base determines from the client request HTTP Header that www.example.com is not a gambling site so rule 2 can be eliminated and the client request is allowed.

Rule 1 and 3 are still a possible match. The file is extracted from the HTTP body in the server response. The Pattern Matcher determines that the file type is an EXE file. The result is sent to the classifier and checked against the rule base. Rule 1 matches and the packet is dropped.

I hope you have found this example helpful to understand how the Unified Policy classifies subsequent packets against the column definitions in the R80.10 Unified Policy until enough information is known to identify the traffic and complete the matching process.