Impossible to block access to Twitter.
It is impossible to block access to Twitter through the WebBlocker service or by adding it as a blocked site. This is probably because the registered FDQN is "www.twiter.com" (spelled without the double "t") but the common normal spelling of twitter.com has the double tt.
When you try to access "www.twiter.com" the Firebox WebBlocker will block access.
However, if you try to access "www.twitter.com" (the common spelling of the actual website) it is not blocked by the WebBlocker service and it loads every time.
Also, it is not possible to manually add "www.twitter.com" as a blocked site by FQDN because "twitter.com" is apparently not the actual FQDN.
0
Sign In to comment.
Comments
When I try to access "www.twitter.com", I get redirected to this:
https://twitter.com/
Are you trying to block this access on your HTTPS proxy ?
That's just plain evil!
Have you tried Application Control?
Social networks > Twitter > Authority, Transfer, Media, Access > Drop
Adrian from Australia
Hi @Montylaw
-Make sure that you're using the same webblocker action on both your HTTP and HTTPS proxies.
-The HTTPS proxy has the best chance of working if content inspection is enabled. Without it, the firewall can only see the SNI (the name information in the certificates) which isn't always correct.
-If you have users on the Chrome browser, ensure that you've made a policy to block ports 80 and 443 UDP. The proxy will not work with these ports, and chrome will use them to effectively bypass the proxy.
-James Carson
WatchGuard Customer Support
Hi James,
Based on your feedback above on the 80 + 443 UDP bypassing proxies, does that mean if we have a TCP-UDP Proxy rule to "capture all" Chrome is still bypassing it, meaning that there is still a chance for the users to visit a malicious site using these ports?
Is there any chance this will change? or is this a limitation with how the UDP protocol is handled and we should take the stance of blocking this type of traffic entirely to enforce security?
Does IDS still work on these ports?
Thanks,
(Sorry for hijacking the thread)
Hi @DaveDave
Using a TCP/UDP proxy won't change it because QUIC isn't something that the HTTP/HTTPS proxies in the TCP/UDP proxy can handle. It'll fall out the "other protocols" option, which is either a straight allow or deny option. It's much less CPU intensive on the firewall to simply just deny it by port.
If you'd like to proxy HTTP/S traffic, you'll need to disable QUIC in the browser or block the port it uses to keep it from accessing data that way.
-James Carson
WatchGuard Customer Support
twitter.com is a registered domain https://www.whois.com/whois/twitter.com
I recommend disabling QUIC in Chrome, not allowing outbound 80 UDP and 443 UDP, blocking DNS over HTTPS in browsers, and blocking DNS over HTTPS requests from all systems via denying "application/dns-message" and "application/dns-json" to your HTTP proxy > HTTP Response > Content Type section. That should take care of side doors to get out or to bypass DNS checks.
Gregg Hill
I block QUIC on the firewall as it is easier than finding every device which uses Chrome, including BYO devices, to disable QUIC on them.
The block is for UDP ports 80 & 443, outgoing to Any-external.
Bruce,
I block QUIC on the firewall as I noted, but I also do it on LAN devices so I don't get a bunch of denied messages in FSM traffic monitor. I use group policy to disable QUIC in Chrome. I also have a theory that it speeds up the browser because it doesn't have to bother trying QUIC, failing, then falling back to TCP 443, but that's just me being hopeful.
Gregg Hill
One can always not Log denied packets on a deny QUIC policy, and thus not see them in Traffic Monitor on in the log server.
Gregg:
How are you handing Chrome on Android or Apple devices?
And does your Group Policy apply to Edge too (the Chromium flavor of Edge)
The blocking of QUIC in the firewall via not allowing UDP 80 & 443 handles all devices. I just wanted to reduce logs of frivolous stuff on the LAN and potentially make a slight speed increase, so I added the GPO. Users' phones are all on an isolated employee wireless VLAN.
The GPO works for Chrome, Edge, and Firefox.
Gregg Hill
"The GPO works for Chrome, Edge, and Firefox" was meant for the disabling of DNS over HTTPS. However, for QUIC, the GPO works for Chrome and Edge.
Gregg Hill
For others reading this thread - DNS over HTTPS is currently blocked by the DNS proxy as Type 65 (DNS over HTTPS) is not in the allowed in the default Query Types list.
Thank you for adding this information - now all I need to do if figure out wny my DNS server (a Synology NAS) is generating the Type-65 rrquests.