Anonymizer matches all traffic

[Benjamin_Hofst1]

I am a bit struggling with an Anonymizer drop Rule. A rule basically like this 

internal to external Anonymizer drop

This rule matches any traffic from inside to outside. This rule starts to create 'accept' logs. The accept logs are logs were Application Control was not able to finish Application classification because of insufficient data transmitted. This is also happening for traffic that should be dropped by the cleanup rule. 

Does Check Point really accept / forward packets until the Classification did finish or not finish, even the traffic should be dropped by another Rule below this "internal to external Anonymizer drop" Rule (like the clean up rule). 

The Anonymizer App Group matches TCP Port 1-65535 and UDP 1-65535. I think this is the reason it matches "almost" all my traffic from inside to external. But i don't like it when the Firewall Accepts Traffic until the classification is done for Traffic that should be dropped by the cleanup Rule. 

Can I do something against that?

Regards

[Tal_Ben_Avraham]

To match against an application layer (or content) GW needs application information.

There are cases where all application rules may be filtered out due to other columns or objects (source\destination\service) - on such cases the match can be done without the application information.

To gather application information GW needs to inspect connection data (i.e: TCP\UDP payload). If data does not exist (for optimization reasons browsers often opens empty TCP connection or empty SSL tunnels) GW will end in an "insufficient data" state.

Note that on cases where all potential rules (determined according to all none data dependent columns\objects) are drop rules connection will be dropped without inspecting the connection to determine application matched on the connection.

Regarding your specific problem. I do not have the full picture of your rulebase.

You can try changing anonymizer and cleanup rule to be with a drop rule without usercheck action (on such cases above drop logic should be applied).

Another option is to customize services of Anonymizer category to be more specific (e.g: web services).

[Benjamin_Hofst1 · Accepted solution]

Thank you for your answer.

I think i can solve this problem with a rule selecting http and https and then add an inline layer with the Anonymizer category. I think that way i can avoid that Anonymizer is matching all traffic from inside to outside (only 80 and 443 is affected by the Anonymizer Rule).

[PhoneBoy]

Yes, this is definitely an approach you can take and an excellent use case for inline layers.

[Tomer_Sole]

Benjamin, just to be clear, the Accept logs didn't happen on the drop rule, but on one of the accept rules below it, correct?

[Benjamin_Hofst1]

In the initial example without the inline layer. The rule "internal to external Anonymizer drop" starts creating 'accept' logs event it's a drop Rule. This is because the  Anonymizer category matches all TCP/UDP and the Firewall tries to match an Application against the Traffic. All the accept logs are because of unfinished Application mappings (e.g. insufficient data to match an Application). This happens no matter if the traffic should be dropped by another Rule below the "internal to external Anonymizer drop" Rule.

In the second example with an inline layer. I select the traffic and then i apply the Anonymizer drop Rule within the Layer. Like this i can avoid that ALL traffic is inspected for Anonymizer Applications.

I hope it's a bit more clear now. 

[Kosin_Usuwanthi]

I found this issue too.

need to filter logging without accept action.