Bob Bent

Blocking the connection before final rule match: CPEarlyDrop

Discussion created by Bob Bent Expert on Oct 17, 2018
Latest reply on Oct 19, 2018 by Valeri Loukine

Somehow missed this in the discussion of the Unified Policy Column-based Rule Matching discussion, but encountered it recently when testing IPS. The drop log Access Rule Name is CPEarlyDrop and the log points to sk111643 Early drop of a connection before the final rule match which covers it well. The explanation pasted below is from the SK and this is also mentioned in ATRG: Unified Policy. Think it explains it pretty well. Check out the SK for more info.

 

The Unified Policy may contain filter criteria that cannot be resolved on a connection's first packet, such as Application or Data. Therefore, on some connections the final rule match decision is reached only on the following data packets.

 

However, the Rule Base may decide to block the connection at an early stage without a final rule decision, if all potential rules of the layer for a specific connection have a Drop or Reject action. This drop will issue a log with Rule Name "CPEarlyDrop" and hits will be counted for all the potential rules.

 

Layer potential rules are a list of rules that have matched the connection so far, according to filter criteria that were resolved for arrived packets (IP, port, VPN tunnel etc). Consider the following policy:

When the FTP connection is opened, the potential rules that match the first packet criteria are (4,6,7). The reason is because the Skype application is searched on any port, but the final conclusion for Skype matching can be determined only on data packets. Nevertheless, since all potential rules have a Drop action, the connection will be blocked on the first packet, even though the final decision of the rule-base was not made.

 

The Unified Policy is Smart (my comment).

Outcomes