Smoothwall - Youtube Search Filtering.. Sanity Check?

[Driftingashore]

Hi All,

 

I have a Smoothwall that I'm trying to ban particular search terms on, especially for Youtube. I've created the rules (as per this) and it works for Google, Amazon, eBay etc. However, the rule does not work correctly on Youtube. If I go to Youtube and type the term into the search bar, then hit enter, the page loads without being blocked, and the URL bar reads:

 

http://www.youtube.com/results?search_query=Blocked+Term

 

However, if I highlight the URL after the page has loaded and hit enter to reload the page, it is blocked. I'm very confused..

 

Anybody have any ideas what may going on?

 

Cheers!

[foofighterjim]

Is the policy blocking the search term placed above any other policies such as content modification impacting YouTube?

[Norphy]

Have you got SSL inspection enabled? You can't do keyword filtering if the Smoothwall can't decrypt the website.

[Driftingashore]

To respond to you both, I have the search-blocking policy dragged to the very top (and have saved it), and a decrypt & inspect policy should be being used. As I said, it works on Google, Amazon etc, so I assume the SSL inspection is working correctly (and it works in Youtube when a search url is entered manually - which is a https address - but not from the page's search box.) I've made an extra SSL Inspection policy just for the user/device I'm testing on and dragged it to the top, but don't see any difference.

 

It looks to me like Youtube's search does some funky background loading rather than refreshing the page so I suspect that has something to do with it, but if it's just me I'm rather stumped.

 

[Edit] Starting to wonder if QUIC is the culprit. Have a content modification rule in place to "Remove QUIC Header" but maybe that isn't working? Found a group policy to disable it in Chrome/Edge, so updating group policies to rule it out. [update..] Nope. QUIC disabled via group policy but nothing changes.

Edited February 23, 2021 by Driftingashore

[ibpalle]

If you can see the log entries for the searches then QUIC isn't the issue. That being said, it's a good idea to block outgoing UDP 80 and 443 traffic on the firewall to augment the QUIC header removal policy - if a browser is in QUIC mode, the filter can't remove the QUIC header. I'll ask the blocklist team about this and get back to you.

[ibpalle]

Good and bad news. Short version of the bad:

Searches on YouTube are POST requests and not GET requests, so we can't block based on the search-term (as we can't see it)

 

A potential fix, while we figure this out, is to remove any content modification policy enforcing restricted mode on Youtube. This will turn off the filtering Youtube does and lets guardian have the full content, where it can then filter based on content.

[Driftingashore]

Thanks, in a way I'm quite relieved as I think I've bashed just about every toggle I could find without making any headway - now I'm just waiting to find out how many things I've broken in the process..

 

To be clear - what you're suggesting about restricted mode, does that apply only to Restricted mode enforced by Smoothwall content modifications? If I remember correctly this can be set in Chrome as a GPO, so I could move that setting there unless that misses the point?

[ibpalle]

It applies to both settings - the idea is to not have Youtube pre-filter the results, allowing Guardian full visibility of all content returned, so the content filtering takes over instead the strict/moderate mode. We have used this before when the Youtube filtering cleans up the returned content just enough so Guardian doesn 't trigger but the customer want's stricter filtering on searches in particular.