Blocking the connection before final rule match: CPEarlyDrop

[Bob_Bent]

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

[_Val_]

Nice one

[Ewald_Beekman]

So, is disabling optimization (as described in the SK) the only way to find out which rule is responsible for dropping the traffice?

[Timothy_Hall]

Depending on the size of your rulebase you may be able to eyeball it, but yes you must disable this optimization to see the drop rule number.  Essentially what happened is all rules with an Accept/Allow action were "thrown out" by Column-based Matching leaving only rules with drop actions; this "early drop" rulebase behavior was covered in my book:

Click to Expand

One interesting side effect of this new column-based policy evaluation technique is
the possibility for what is known as an “early drop” to occur. Suppose that candidate
traffic is being column-matched against a rulebase, and all rules with an Accept/Allow
action were excluded. In other words, the only surviving rules after the column-based
evaluation had Drop/Block as an action. In that case the traffic will of course be dropped
and logged, but no matching rule number will be present in the log entry.

While we generally don’t care about this situation since the packet was dropped
anyway, the lack of a logged rule number that caused the drop action can be a bit
confusing when attempting to troubleshoot. This “early drop” behavior can be disabled
if needed by toggling the up_early_drop_optimization kernel variable as
specified here: sk111643: Early Drop - dropping connection before final rule match

[Stealth]

I can see that I'm going to be disabling/enabling this multiple times a day, followed by unnecessary policy installs. Surely, there is a way of letting us know which of the rules are blocking it without jumping through all of these hoops?