CPEarlyDrop Mechanism

[Matlu]

Hello, team.

Could someone enlighten me with the following question.

How does the "mechanism" of "CPEarlyDrop" work?

Sometimes it is really annoying, as I understand a little bit the SK, although not 100%.

I would like to know, what is the best way to avoid "running into" this mechanism, when creating a security rule, to allow or deny an access to certain origin(s) of your network.

I share with you an image of a log of my client's environment, where having created an explicit rule to allow the connection from an origin to a destination, the traffic does not MATCH with this rule, but it does MATCH with the CPEarlyDrop.

I will be attentive to your kind comments.

Regards.

[HeikoAnkenbrand · Accepted solution]

The mechanism is described here:
sk111643: Early drop of a connection before the final rule match

It is well explained in the SK video.

If that is not enough, please describe your question in more detail.

[Matlu]

Hello,

I understand that this mechanism "appears" when you have many "similar" rules, right?

Something like if you have 4 rules, that all work with "Source" and "Destination" as "any", "any", and you just "customize" the services, changing the actions, between "Allow" and "deny".

If you decide to put a 5th rule in the list that has almost the same criteria as the first 4, I understand that the "mechanism" of CPEarlyDrop appears, is this correct?

My question is, when this type of mechanism appears, at the moment of creating an explicit rule, what is the best solution method, to make the traffic match with the rule that I just created, and not with the CPEarlyDrop?

Thanks for your comments.

Thanks for your comments.

[PhoneBoy]

CPEarlyDrop kicks primarily when multiple rules kick in with similar source/destination, Services that aren't just simple TCP/UDP services, and the action is Drop.
The "services that aren't simple TCP/UDP services" are key because they require packets beyond the first SYN to make a rulebase match and is when CPEarlyDrop kicks in.
Rules that involve only simple TCP/UDP services with the action Accept won't be subject to CPEarlyDrop since they can be resolved on the first packet.

To clean up the problem, you should probably disable (temporarily) the mechanism as described in the SK and see what rules the traffic matches.
The offending rule(s) should be logged and you can adjust them accordingly. 

[Matlu]

Hello,

One doubt, when you talk about "Simple TCP/UDP services", you are referring to "known ports", for example the 179 which is, as far as I remember the port for BGP, or for example the port for RDP 3389.

Is it these services you are referring to, in your comment?

Is it a viable option to take the rule I created, and put it at the beginning of the rule base, just to "test" the traffic?

This way I avoid disabling perhaps the CPEarlyDrop mechanism.

Greetings.

[PhoneBoy]

You are correct on both accounts.