My emby server has been flagged as a Deceptive site.

[trinected 7]

Somehow related?
https://github.com/jellyfin/jellyfin/pull/9820
https://github.com/jellyfin/jellyfin/security/advisories/GHSA-9p5f-5x8v-x65m

[lucian.pearce 0]

Argh WTF my site has been marked as deceptive again I have Version 4.7.13.0 of course all sites on the domain are now marked deceptive damn you google 

[scaldeddog79 0]

I got hit with this again today as well, third or fourth time overall I think. My entire domain is on Google's naughty list again and got put on my employer's blacklist as a result (will probably need a new domain if this ever gets fixed).

Currently running 4.8.0.39 beta

[lucian.pearce 0]

I moved the emby server to a different domain which got tagged as deceptive pretty much straight away, I clicked this it not a deceptive site option on the old domain about 3 days ago and it has mad no difference so far, they definitely suck, but I seem to be pretty powerless to do anything about it

Edited July 14, 2023 by lucian.pearce

[DarkZrobe 3]

Be curious to see if someone from the dev team chimes in.

I am on the beta and have not been flagged since moving to the Beta. I did create and register my website with google to put in my request to be reviewed. Not sure if that is the difference here. I have some friends on the 4.7.13 build who have the same reverse proxy setup with no flag either.

[rbjtech 4301]

I've never been flagged even before the changes, I have no idea why not - maybe luck, maybe because I geo-block to UK only (but have seen Google scanners from the UK).. who knows ..

I've also just registered my tld with google search (needs dns txt record verification) so hopefully that will help verify things should they eventually catch up and find me .. haha.

 

Edited July 14, 2023 by rbjtech

[sLIDez0rz 2]

Got flagged in March, then unflagged after about 5 days, then flagged again after 2 hours (whole domain).

Had Emby accessible through https://emby.domain.tld, https://domain.tld/emby and https://ip:8096 before. After 2nd flag left only https://emby.domain.tld No problems since then. Running through Nginx proxy manager with Let's encrypt certificate. The only other thing I did was to replace default 302 redirect to 301 redirect in Nginx Proxy Manager configuration (as Google doesn't really like 302 redirects that is there by default)

location = / {
    return 301 https://$host/web/index.html;
}

At the same time also got my instance of Picoshare flagged which was on separate subdomain. Changed nothing there, just submitted that it was a false positive on Google Search Console and everything is fine.

I suppose that only appeals through Google Search Console does anything and the ones through browser does nothing. So if you get flagged, check Google Search Console as it could be other services too that got you flagged.

[baikunz 1]

Hello, Installed a new instance yesterday on a new dedicated server. Freshly bought domain, accessible at emby.domain.tld. It's behind a traefik proxy, https with letsencryt, and cloudflare as my dns server (non proxied) and it got instantly flagged by Google. 

My first instance also accessible at emby.domain.tld has never been facing this issue. No idea what's going on. 

[sLIDez0rz 2]

One thing you should be aware of when generating Let's Encrypt certificates is their Transparency Log - other services can get newly issued certificates. Also while randomly checking access logs, spotted a weird referral link - www.netcraft.com . So probably they also monitor those transparency logs, sees that your site is a possible phishing site and reports to google automatically. You can avoid your new site showing up in those transparency logs by using wildcard certificate.

Of course this is just a wild theory.

[trinected 7]

29 minutes ago, sLIDez0rz said:

You can avoid your new site showing up in those transparency logs by using wildcard certificate.

This does not help  I always use wildcard certificates, not showing there but being scanned.

Edited July 15, 2023 by trinected

[Q-Droid 657]

35 minutes ago, sLIDez0rz said:

One thing you should be aware of when generating Let's Encrypt certificates is their Transparency Log - other services can get newly issued certificates. Also while randomly checking access logs, spotted a weird referral link - www.netcraft.com . So probably they also monitor those transparency logs, sees that your site is a possible phishing site and reports to google automatically. You can avoid your new site showing up in those transparency logs by using wildcard certificate.

Of course this is just a wild theory.

I don't think this is accurate. As far as I can tell all certs issued by participating CAs are included in CT and the CT log operator for LetsEncrypt certs is Google. At least it is for the ones I've checked, including mine which do use wildcards. There is no trick or workaround or choice.

CT is a good thing and it's not about the sites or domains but the CAs themselves logging their activities.

 

Edited July 15, 2023 by Q-Droid

[sLIDez0rz 2]

Well, when using wildcard cert, google only knows about domain.tld, not emby.domain.tld or whatever.domain.tld while without using wildcard cert they know exactly the domain for your new site.

[Q-Droid 657]

6 minutes ago, sLIDez0rz said:

Well, when using wildcard cert, google only knows about domain.tld, not emby.domain.tld or whatever.domain.tld while without using wildcard cert they know exactly the domain for your new site.

Wildcard or not a cert is issued for a domain or sub-domain after proof of control is given. So that would be enough information to establish ownership even if the sub-domains covered by the wildcard certs resolve to different addresses. It's up to the site operator to manage their keys.

I don't know what criteria Google is using to determine and flag sites as deceptive. Does anyone? I doubt the certs themselves are part of the equation.

 

[sLIDez0rz 2]

I am not saying certs affect if site gets flagged or not. Certs (Transparency logs) are the way for any 3rd party to see that there is a new site and to check/report it as phishing.

We had issues with this at work where deployed sites were instantly hit with vulnerability scanner as soon as it went live. Switched to wildcard cert and no more, as they no longer see that there is a new possible target for scan, because wildcard cert appears only in transparency logs once - when issued and then you use it for as many sites as you wish.

As I speculated above, based on my servers access logs, the only outlier was referral netcraft.com and guess what is one of the things they do - scan and report phishing sites and transparency logs is one way for them to get sites to scan.

[Q-Droid 657]

I see what you're saying. It's possible that 3rd parties could be using the CT logs to scan those sites. The purpose of CT is a CA audit trail and since they're open then the logs can be used for other stuff. A wildcard cert without other SANs would not reveal the many possible endpoints covered by the cert so in effect they could be "hidden" from scanners that are using CT logs exclusively. But would any of them do this? The same endpoints would not be hidden from the many other possible ways 3rd parties discover and scan the same endpoints including address probing, DNS, crawlers, browser extensions, browser and app telemetry to name a few.

 

[darkassassin07 432]

For the record; I've been running my server for around 7 years on the same domain 'emby.domain.tld' with that specified in the certificate from letsencrypt (no wildcard) and haven't had any issues being flagged.

I do have nginx infront, setup to only answer to that domain while '444'ing everything else (drop connection with no response), as well as a robots.txt file rejecting all crawlers. I haven't done anything else to hide from or block google or any others really.

 

I'm not sure finding 'emby' in the domain in the CA logs is what's causing issue, but I'm not sure what's causing you guys to be flagged either...

[baikunz 1]

My first instance is running for a few months on an emby subdomain with a named certificate.

My new instance got flagged instantly with a wildcard certificate. I don't think having a wildcard certificate is helping in any way.

[plupien79 2]

Still a problem.

Running behind HAProxy on port 443 with a let's encrypt cert with CAA configured.

http to https processes as a 302 redirect.

A± on ssllabs

4.7.13 on windows.

 

 

[rbjtech 4301]

15 hours ago, plupien79 said:

Still a problem.

Running behind HAProxy on port 443 with a let's encrypt cert with CAA configured.

http to https processes as a 302 redirect.

A± on ssllabs

4.7.13 on windows.

 

 

Does anybody know if 4.7.13 has the 'header' changes that removed all the generic 'Emby' details that the Beta removed a while back in an effort to combat this ? 

Beta was updated in April 22 ... Did the release follow ?

 

 

Edited July 17, 2023 by rbjtech

[cypher0117 4]

2 hours ago, rbjtech said:

Does anybody know if 4.7.13 has the 'header' changes that removed all the generic 'Emby' details that the Beta removed a while back in an effort to combat this ? 

Beta was updated in April 22 ... Did the release follow ?

 

I thought the beta header changes were in the latest release updates.

You've tested through ssllabs, but have you also looked at https://securityheaders.com/

[rbjtech 4301]

4 minutes ago, cypher0117 said:

I thought the beta header changes were in the latest release updates.

You've tested through ssllabs, but have you also looked at https://securityheaders.com/

I'm referring to the reason for Google flagging the site (the word - 'emby' being used which Google is flagging as 'impersonating' emby.com (ie Phishing)  - I don't believe this has anything to do with the security headers ?

Edited July 17, 2023 by rbjtech

[plupien79 2]

Yeah, that's not good I suspect.

[rbjtech 4301]

1 minute ago, plupien79 said:

Yeah, that's not good I suspect.

I don't believe the security headers have anything to do with this.

People with A+ on ssllabs/securityheaders etc are still being flagged - so I think this is unrelated.

 

[cypher0117 4]

14 minutes ago, rbjtech said:

I'm referring to the reason for Google flagging the site (the word - 'emby' being used which Google is flagging as 'impersonating' emby.com (ie Phishing)  - I don't believe this has anything to do with the security headers ?

I have a nearly identical setup as you.  HAproxy, acme certs, CAA, A+ ssl labs, etc.  I have so far - knock on wood - not been flagged.  I've added extra configurations to the security headers in my HAproxy that have given my site an A grade on https://securityheaders.com.  I can't say that it's the reason for sure, but my site is has been used close to daily for the last few years without being flagged.

 - edited for spelling

Edited July 17, 2023 by cypher0117

[rbjtech 4301]

2 minutes ago, cypher0117 said:

I have a nearly identical setup as you.  HAproxy, acme certs, CAA, A+ ssl labs, etc.  I have so far - knock on wood - not been flagged.  I'd added extra configurations to the security headers in my HAproxy that have given my site a A grade on https://securityheaders.com.  I can't say that it's the reason for sure, but my site is has been used close to daily for the last few years.

Sure - I'm on A+ for them all - but I don't think it's related - as other people with A+ rating have been flagged.

Until Google indicate exactly WHY they have flagged a site - then it's a cat and mouse game.