Lots of sites being categorized as anonymizers inc. Spotify and Bing?

[Jennifer_Wilson]

We block anonymizers and can see that at least open.spotify.com, www.bing.com teams web etc are being blocked as they are tagged as anonymizers by URL categorization.
Had reports this has been happening since last Friday.

online Checkpoint URL checker shows the spotify one as what you would expect (entertainmnet etc.) and the IP's on it as uncategorized.

But the URL & App DB on my management server says it's up to date with a version of 141202403031347 created 03/03/2023 13:47 and won't update past that one.

Anyone else seeing similar issues?

[Jennifer_Wilson]

Please find update from Checkpoint below :

'Currently, we have received multiple complaints about this issue and it was brought to the highest ranks in support and R&D departments, this issue is related to CP side and is being handled as we speak by our internal teams,

We appreciate your patience and cooperation in reporting this issue.
I will update you on the progress and possible steps to solve this issue once I get news from R&D'

[gmorrow205]

Any news on the fix?  I have a case open and got the same "known issue" response. 

[Jennifer_Wilson]

they have said a new application control db has been uploaded to the Gateways (but not the Management server), dated 05/03/2024 time 10:3x Update number 050324_3, which I've checked is now there. (cpview/Software-Blades/Overview-Updates Information:)
I am having a look now but Bing and open.spotify look good so far.

[Jennifer_Wilson]

My testing on a single test machine (that still has an app rule with anonymizer category blocked on it) indicates the updated app control db has fixed the issue.
Defender updates, Bing and open.spotify are not now showing as "anonymizer" category on a Checkpoint Gateway running R81.10 JHF 130 with HTTPS Categorization (not SSL inspection).

[gmorrow205]

Awesome. We pushed a global exception for anonymizer, but I will pull it off a cluster and test. 

So you didn't have to clear the URL cache? That procedure looked pretty intense!

[Jennifer_Wilson]

No, didn't have to clear the URL cache.
Was requested to do a policy install, but had already done some unrelated policy installs around the time so it was already applied in our case.

[the_rock]

Thanks for that. Did they say it applies to all versions or just R81.10?

Andy

[Jennifer_Wilson]

They didn't say, sorry.

[STEVE_ENS]

This is what we tried this morning...still testing.

Steps Taken: Logs show the traffic is being categorized by IP Initially (cat $FWDIR/database/ca_bundle.pem | grep BEGIN | wc -l) output showed only 286 CAs MGMT R81.20 Take 41 There was a discrepancy between the amount of CA's in smartboard vs the amount of CAs on the GW. Updated the Trusted CA's After updating the trusted CA's we now saw 147 CA's in ca_bundle.pem sk180507 - The Trusted CAs list is not updated in the R81.10/R81.20 Management Server database - Ran the MGMT CAs bundle script for R81.20 Take 41 - 200+ missing CAs were added - Installed database and policy - We were still only seeing 147 CAs in $FWDIR/database/ca_bundle.pem - We added the server cert to the trusted Cas to trigger a change to update the GW's - After installing the policy we could see the GW was updated with the CAs (371) Cleared the URLF cache - sk64280 Cleared the SNI cache - # fw tab -t cptls_host_name_cache -x -y