topic Re: CPEarlyDrop Mechanism in General Topics

CPEarlyDrop Mechanism

Matlu — Wed, 01 Feb 2023 18:48:26 GMT

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.

Re: CPEarlyDrop Mechanism

HeikoAnkenbrand — Wed, 01 Feb 2023 22:37:38 GMT

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.

Re: CPEarlyDrop Mechanism

Matlu — Wed, 01 Feb 2023 23:34:53 GMT

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.

Re: CPEarlyDrop Mechanism

PhoneBoy — Thu, 02 Feb 2023 00:13:39 GMT

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.

Re: CPEarlyDrop Mechanism

Matlu — Thu, 02 Feb 2023 00:29:13 GMT

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.

Re: CPEarlyDrop Mechanism

PhoneBoy — Thu, 02 Feb 2023 01:46:48 GMT

You are correct on both accounts.