Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Jennifer_Wilson
Contributor
Jump to solution

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

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?


1 Solution

Accepted Solutions
the_rock
Legend
Legend

I agree 100%, best to oppen TAC case and see what they come back with.

Andy

View solution in original post

0 Kudos
38 Replies
the_rock
Legend
Legend

Have not noticed it in my lab, shows up fine. When in doubt, I always check below, its correct 100% of the time

Best,

Andy

 

https://url-classification.io/?utm_source=g&utm_medium=a&utm_campaign=g2&gad_source=1&gclid=CjwKCAiA...

0 Kudos
STEVE_ENS
Contributor

I've been putting all the sites that the Anonymyzer rule has been catching into that classification site and they are all coming back green...so there are definitely issues. 

0 Kudos
the_rock
Legend
Legend

This is the log I see when going to bing.com

Andy

 

Screenshot_1.png

0 Kudos
Morten_O
Contributor
Contributor

Yes, I have heard this from multiple customers within the last week or so. Heard that they needed to whitelist Bing, Teams, Office, WebEX and more - all categorized as Anonymizers.

the_rock
Legend
Legend

What version? We have many customers on R81.20 and no one reported this.

Best,

Andy

0 Kudos
Morten_O
Contributor
Contributor

I think the majority of those with the problem are running R81.10

0 Kudos
the_rock
Legend
Legend

That could be why...I will try later in R81.10 lab as well.

Andy

0 Kudos
Jennifer_Wilson
Contributor

Thanks for the info Morten, yes we are on R81.10 as well.

 

0 Kudos
the_rock
Legend
Legend

Just tried, yes, seems like it is an issue in R81.10. Btw @Jennifer_Wilson , https categorization is NOT replacement for ssl inspection, but regardless of the fact you dont have inspection turned on, even if you did, you would most likely have the same problem.

I would consider upgrading to R81.20, if you can.

Best,

Andy

0 Kudos
Jennifer_Wilson
Contributor

Don't suppose you know if that would work if we upgraded just the management server? (leaving the gateways on R81.10)

 

0 Kudos
the_rock
Legend
Legend

I do know...it would NOT work, Im 100% positive. You need to upgrade the gateways, because upgrading the mgmt server only would not do much to change this behavior.

Best,

Andy

Jennifer_Wilson
Contributor

cheers, thanks for the confirmation it would not work.

0 Kudos
the_rock
Legend
Legend

No worries.

Andy

0 Kudos
Morten_O
Contributor
Contributor

Is this test a new installation of R81.10 or an old one? Which Jumbo? I know it's much to ask, but does it help to clear the URLF-cache (sk64280)?

0 Kudos
the_rock
Legend
Legend

All good mate, questions are FREE ; - ). Its not new install, had it for some time.

Btw, tried that first actually and its latest jumbo.

Best,

Andy

STEVE_ENS
Contributor

We are seeing this on R81.20...  I've disabled my anonymyzer rule for the time being until we see a solution.

0 Kudos
the_rock
Legend
Legend

I had not heard of any customers we have reporting this or had seen it in my lab and I do lots of ssl inspection testing in my eve-ng and also Azure lab.

Best,

Andy

0 Kudos
Morten_O
Contributor
Contributor

As I see it, this is not related to HTTPS-inspection - I don't think that any of my customers that are seeing this issue uses HTTPS-inspection.

I think normal URLF/APCL is causing this.

0 Kudos
the_rock
Legend
Legend

You wont see this issue if you were using uhttps inspection. As I said to @Jennifer_Wilson , http categorization is sadly NOT a replacement for inspection feature. 

Best,

Andy

0 Kudos
Jennifer_Wilson
Contributor

Don't suppose you have the full list?
It's hard to figure out from our logs (lots of IP's rather than app names and we don't do SSL Decryption (do HTTPS Categprization))

0 Kudos
Morten_O
Contributor
Contributor

I don't think there is a full list - I just heard that lenovo.com is now also an Anonymizer....

Best solution would be to open an Service Request. Not everyone can just upgrade to R81.20 overnight 

(1)
the_rock
Legend
Legend

I agree 100%, best to oppen TAC case and see what they come back with.

Andy

0 Kudos
Jennifer_Wilson
Contributor

Just need to add that we've discovered that (AV sig/Defender etc.) updates to microsoft windows PCs are also being blocked because of this (ie Windows Updates, Windows 11 Updates) etc.

0 Kudos
the_rock
Legend
Legend

I hate to say this, but in your case, without even having inspection enabled, it would be totally pointless to add anything as bypass rules in the inspection policy, as that would only take effect if the feature is turned on.

Best,

Andy

0 Kudos
STEVE_ENS
Contributor

I'm seeing this behaviour on my R81.20 appliance as well...so not just 81.10

0 Kudos
D_W
Advisor

Can you share some Log Details of these false positives?

0 Kudos
STEVE_ENS
Contributor

Response from TAC is that it is a known issue, they are working on it.  I've had apps that have worked for years suddenly being blocked...going out to internet and coming in from internet. 

D_W
Advisor

Is the anomyzer before the allow rule? I need to think ahead. Hope it will not hit us 🤪

0 Kudos
the_rock
Legend
Legend

Let us know what they provide you as a solution.

Best,

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events