CSmith

Hi all, The issue should now be resolved. On-prem users may need to manually pull down the latest blocklist (System > Licences, then hit Update under 'Blocklist subscription'). Cloud filter customers shouldn't need to do anything, the latest blocklist will be automatically pulled down and installed.

For any Smoothwall admins, blocking the AI Tools category will prevent users from accessing the AI mode search feature. Alternatively we provide a 'Google web search: Basic Mode' which will restrict users to basic web/image search only. For non-Smoothwall users, as suggested above by @sigma and @ShellfishClive, the following regular expression should block any requests to Google's AI mode (https?://)?(www\.)?google\.com?/search\?.*?udm=50(&|$)

@ittech2342323 I've made some changes to our categorisation rules so the safeguarding report should be a little less noisy now. Usually in cases such as this it's because the domain is categorised as something which feeds into the safeguarding ruleset and requests are being made for static content (images/css/js) from that domain. We do try to identify this content and prevent it from appearing in the safeguarding reports but there are always edge cases where this doesn't work. If you come across any other entries in your safeguarding reports which you think are erroneous I'd encourage you to submit some blocklist feedback - see https://kb.smoothwall.com/hc/en-us/requests/new?ticket_form_id=360000223410

I would advise having both in place, I'll speak to our support team and try to understand the reasoning behind disabling the content modification policy.

Out of interest @gybe78 - has that change made any difference to your ability to access the various gaming websites you've mentioned? There are two ways to prevent HTTP/3 (QUIC), but ideally both should be employed as they both serve slightly different purposes. The first - our 'Remove QUIC Header' content modification - is designed to prevent a server from ever being able to tell the browser that it supports HTTP/3. We do this by altering the contents of the 'Alt-Svc' header returned by the server. The client never realises that the server supports HTTP/3, and thus never tries to establish a connection using that protocol. The downside of this method is that any domain which is not inspected, or added to a 'do not filter' policy won't have this content modification applied to it. In this scenario it's possible that the browser might receive the un-altered 'Alt-Svc' header and start making use of HTTP/3 for future requests. Even if that domain is removed from the 'do not filter' or 'do not inspect' policy in the future, the browser may continue to use HTTP/3 until the cache is cleared within the browser. The second method is simply to block UDP port 80 and 443. This should in theory prevent all HTTP/3 requests, however - much like with standard HTTP/s - there is no requirement for an HTTP/3 connection to be established over port 443. The 'Alt-Svc' header described above could contain an alternative port number in which case the firewall policy alone wouldn't prevent the HTTP/3 connection from being established.

@gybe78 is there any chance you could DM me a copy of your Smoothwall's archive so I can load it up locally and take a look?

Hi All, @tom_newton has asked me to take a look at this thread and provide any support I'm able to. I'll try to answer any questions I can but it seems like there might be a few different issues here so you'll have to bear with me. First off, we should address the Safeguarding Exclusions category so there's no confusion. This is a Smoothwall owned category that is (mostly) hidden from view. It contains a whole bunch of rules designed to prevent over-reporting in the safeguarding reports and you'll see this crop up in the logs from time to time. It's mostly used to prevent .css, .txt, .json, (...etc) files from raising safeguarding alerts but rest assured that these URLs are still filtered just like any other, and certainly aren't allowed out by default. The gamepluto.com domain is currently categorised as Video Games by both domain/URL and content analysis, so there shouldn't be any need to add this domain to any custom categories providing you have Video Games in a block policy. @gybe78 you've mentioned that you get a blockpage when you access the domain directly but when you search via Google you're able to follow the link and access the site. That certainly shouldn't be the case. I've done a bit of testing and I can confirm that a search in Google for "gamepluto" (or "game pluto") should be caught on content for Video Games, which suggests to me that you either don't have an HTTPs inspection in place and/or - and I suspect this is more likely - you're allowing either google.com or some other google related domains. Would you be able to confirm if you have an HTTPs inspection policy in place or not and then check any custom categories you're currently allowing out to ensure they don't contain anything... Googly... @TechMonkey with regards to Bullet Force on crazygames.com - where students accessing the game directly on crazygames.com or where they accessing the game via other sites? I've checked that domain and can confirm its categorised as Video Games by both URL and content analysis. I've also looked through the list @sigma supplied and all of those are also categorised by content analysis, although we didn't have all those URLs in our database (they will of course be in our categorisation rules from tonight's blocklist update). If students are (or were) able to access Bullet Force on some of those domains then that would suggest to me that an HTTPs inspection policy isn't in place, would you be able to confirm for me? For your information @sigma (and anyone else who might be unawares) there's no need to block all the various subdomain (api. builds. files., etc..) when you add a domain to a custom category. We match greedily so an entry for crazygames.com is effectively matching *.craxygames.com/*

To make life easier for everyone, there will be a new 'WeChat' category for Smoothwall customers in tonight's blocklist update

Hi all, Just to hopefully put everyone's mind at ease I have done some testing this afternoon with Edge 109 and it appears that everything will continue to work as before, in other words any locally installed CA's should continue to be trusted. A picture is worth a thousand words so here's a screenshot with as much information as I can possibly cram in Apologies for the single screenshot but Edugeek complained when I tried to submit my post with several individual screenshots! Hopefully it's clear from the above that I'm testing on Edge 109, and that when the `Microsoft root store` flag is enabled I can still intercept secure sites using the Smoothwall CA I installed into the operating systems certificate store. Here's the relevant quote from the Microsoft site regarding the MicrosoftRootStoreEnabled flag In 109 this flag will be available but disabled by default. In 110 the flag will be enabled by default. In 111 the flag will be removed and the default behaviour will have switched.

Hi @DeGrimmy - it looks like the YouTube content is coming from gstatic.com/_/mss/boq-edu-youtube/ - if you add that URL to your custom blocked content category it should stop YouTube results from showing up via Google Classroom.

Hey @BlueDargon, You can give this a go, it searches through the content of the page for a pattern that includes both a video ID and a playlist ID; $url = "https://www.youtube.com/watch?v=WSUFzC6_fp8&list=RDQMOI78oB-40zU&start_radio=1" $playlist = (Invoke-WebRequest "$url") $matches = ($playlist.Content | Select-String -Pattern '"videoId":"([^"]+)","playlistId"' -AllMatches).Matches ForEach ($match in $matches | Sort-Object | Get-Unique) { Write-Output ("https://www.youtube.com/watch?v=" + $match.groups[1].value) } PS C:\Users\Chris\Desktop> C:\Users\Chris\Desktop\youtube.ps1 https://www.youtube.com/watch?v=30TkClWvT5k https://www.youtube.com/watch?v=3MKP3SkzkIA https://www.youtube.com/watch?v=3ZT9_H4-hbM https://www.youtube.com/watch?v=4KiFSKLTj0U https://www.youtube.com/watch?v=5Vwu-t7QRaE https://www.youtube.com/watch?v=aAkMkVFwAoo https://www.youtube.com/watch?v=bjQzJAKxTrE https://www.youtube.com/watch?v=Dkq3LD-4pmM https://www.youtube.com/watch?v=E8gmARGvPlI https://www.youtube.com/watch?v=EGOz9f78IjI https://www.youtube.com/watch?v=emXbfEzXn6A https://www.youtube.com/watch?v=GjtYtBGrP6Y https://www.youtube.com/watch?v=IJPc7esgvsA https://www.youtube.com/watch?v=ku7ohU1IGls https://www.youtube.com/watch?v=KYiUSalSjS0 https://www.youtube.com/watch?v=L1nQpoAvTSg https://www.youtube.com/watch?v=LRP8d7hhpoQ https://www.youtube.com/watch?v=LUjn3RpkcKY https://www.youtube.com/watch?v=Mj7Pr42rliI https://www.youtube.com/watch?v=Mk_GmhD053E https://www.youtube.com/watch?v=mN7LW0Y00kE https://www.youtube.com/watch?v=nlR0MkrRklg https://www.youtube.com/watch?v=Nx-DvH41Tjo https://www.youtube.com/watch?v=pFjdfjrtf1Q https://www.youtube.com/watch?v=Q8ugJnIG_Lk https://www.youtube.com/watch?v=qJ_MGWio-vc https://www.youtube.com/watch?v=QJ5DOWPGxwg https://www.youtube.com/watch?v=UqItlHUSN-4 https://www.youtube.com/watch?v=VAMzAIH12yc https://www.youtube.com/watch?v=WSUFzC6_fp8

Hi @sigma, a safeguarding alert should be generated any time a user accesses a webpage which is categorised as one of 'Child Abuse', 'Drugs', 'Intolerance', 'Pornography', 'Alcohol', 'Self Harm', 'Terrorism Violence', 'Sexuality Sites', 'Personal Weapons', 'Criminal Activity', or 'Adult sites'. These are all categories which we provide, and these fit into different rulesets (e.g. the 'Intolerance' and 'Terrorism' categories go into the 'Radicalisation' ruleset etc...) - there's a more indepth description on our knowledge base To exclude a domain, URL, or searchterm from the safeguarding reports you need to first find the item in the reports and then select the 'Exclude' button which appears on the right-hand side when you hover over an item. Any item that you exclude from the reports will be sent back to the categorisation team at Smoothwall so we can fix the issue.

Hi @sigma - we've got a blocklist feedback form where you can submit any categorisation issues you come across, or you can send me a message on here and I'll try to resolve any categorisation issues you encounter. Could you expand on the problem above? I've tested a variety of cucumber related search terms but haven't been able to replicate the issue described where the results were blocked. This one should now be resolved We provide a list of search terms and one of them was overzealously blocking the phrase potatoes because it contained the word pot. We're usually very careful to make sure this kind of thing doesn't happen, but sometimes problematic search terms slip through the net. Hi @TomHD - As above, any issues you encounter can be submitted via the blocklist feedback form or by sending me a PM on Edugeek. I've tested the search term but haven't been able to replicate the problem, is this still being blocked on your network? If it is, can you let me know for what reason it's being blocked (I assume it's blocked on content). When I performed some tests, variations on the word "twinkl" did return results that were pornographic and/or inappropriate for young audiences, and these were correctly identified and blocked by Guardian as 'Pornography'.

Keyword blocking - no, because your web filter won't be able to see the contents of the page without SSL Interception. Enforcing safe search - yes, Smoothwall provide a content mod that will do this for you ('Enable Google SafeSearch') but if you're not behind a Smoothwall you can follow the instructions under 'Advanced > Turn on SafeSearch VIP' on this Google KB article - https://support.google.com/websearch/answer/186669?hl=en which will force SafeSearch for your entire network. Chris

Hi @gsk, answered your questions below - if you've any follow up questions let me know Yes, SSL interception will work for domains which implement HSTS. Similarly, domains which implement HPKP (HTTP Public Key Pinning) will not be adversely affected as any certificate authorities installed by the user will be trusted by the browser. Absolutely, new Smoothwall customers who choose to use HTTPS Decrypt and Inspect will have the 'Online Banking' category in a 'Do Not Inspect' rule by default - this is recommended by Smoothwall. Probably not the best person to answer this one but ultimately it will depend on where you are in the world. In the UK the vast majority of schools use HTTPS Decrypt and Inspect to ensure students are protected at all times, in the United States I believe that HTTPS Decrypt and Inspect is not as widely used. Realistically - no. To best protect your users you should employ a HTTPS Decrypt and Inspect policy if possible, however if your just want to test it out then I recomend taking a look at this article on our knowledge base which goes through the best categories to set up a HTTPS Decrypt and Inspect policy against as a bare minimum for safeguarding. Chris Edit - Only just realised that this wasn't posted on the Smoothwall forum - but the above should be correct regardless of who is providing your web filtering.

Hi @AlanD - Usually when you first set up your Smoothwall you're presented with the option to chose your default web filter policies - selecting Education from this list will create three allow policies, for 'Education and Reference', 'Academic Institutions', and 'Government' - these should cover the "official" sites you're referring to. If you didn't/haven't seen that page then I'd recomend allowing those three categories which should reduce any overblocking issues. We usually (almost always) categorise exam related sites (such as exam boards) as 'Education and Reference' but it's possible we've missed some - if you (or anyone else) is experiancing any issues with exam related sites then please PM me so we can work to resolve these issues Chris

Mobile applications are proving to be quite a pain at the moment - more and more of them are using certificate pinning which means any attempt to decrypt the traffic by the Smoothwall results in the application throwing a bit of a fit. Would you be able to PM me details of any specific apps you've had problems with? We're currently investigating a few different methods of resolving this problem so any input you could provide would be much appreciated.

Haha excellent stuff! QUIC is a bit of a nuisance unfortunately - glad to see you've got it working

Hi @ridleyrumpus - Sounds like it might be related to QUIC - Ensure your firewall is blocking UDP port 443 or you have the 'Remove QUIC Header' content modification applied to 'Everything' (You'll need a HTTPD D&I policy set up if you go for this option!). Chris

Hey @AlanD - Are you making use of HTTPS Decrypt and Inspect? If not I would encourage you to set up a HTTPS D&I policy which should greatly improve our filtering. Just to clear up a few points you've raised Its basic web filtering is not great - and probably uses little more than the "free" guardian stuff. We actually have an inhouse categorisation team of four (of which I'm a member) who are responsible for ensuring our blocklist is up to date with the latest threats - if you ever come across something that's incorrectly categorised then you can let us know through our feedback service (https://uk.smoothwall.com/provide-blocklist-feedback/) I had to add several URLS to get it to handle facebook and instagram correctly We have a 'Facebook' category which should contain all the domains and URLs used by Facebook - simply allowing or blocking this category as nescessary should have you covered. We don't have one for Instagram at the moment but we are looking to increase the number of services we have categories for in the future. Of course it has no real time web content analysis to speak of For any requested URL which we do not categorise by domain or URL we will run against our dynamic content analysis rules to try and identify what type of content it is. For best results you should ensure that you have a HTTPS Decrypt & Inspect policy set up - without it we can only scan standard HTTP traffic. If you have any questions then feel free to leave a comment here or PM me directly Chris

Hey guys, thanks for pointing this out to us (Smoothwall) - it's been categorised and the changes will roll out tonight.

Hi guys, We're spending a bit of time using the Kerboodle service; trying to figure out which domains need to be allowed for it to work correctly, as well as what (if anything) needs to be whitelisted or added to the Authentication Exceptions list. We've already built up a list of URL's and domains which we think is fairly accurate but I notice that both @MYK-IT and @mikecain have experienced some problems with Internet Explorer which we've been unable to replicate. Could you let us know what type of Authentication method you are using and whether or not you are using a transparent or non transparent proxy - this should help us to to identify any problems when accessing Kerboodle through Smoothwall and allow us to solve them.