Opendium_Steve

Just to chuck in my 2p's worth, I'm never convinced that "99.999%" service levels are worth the paper they're written on. Most outages that last more than a few minutes are of the "digger through fibre" variety, and they affect everyone to the same degree, no matter what your SLA says. Any compensation written into the SLA for breaching the service level is usually an absolute pittance and not worth worrying about.

Yes and no If some BGP peer announces a route to RFC1918 addresses to the internet, most ISPs will filter them out, so no harm done. On the other hand, if they are legitimate public IPs which you didn't want to be globally routable and some idiot accidentally announces the routes you'll suddenly find anyone on the internet can talk to them (assuming you didn't have sane firewall rules). Of course I agree that you need proper firewalling no matter what IP range you use internally, and there are enough ways to subvert NAT that it offers no appreciable security in itself. Anyway, my point really was that there are legitimate reasons for using public IPs in private settings if _you own_ them. But in the case Gibson335 described, someone obviously just didn't know what they were doing and picked a random bunch of IP addresses that they didn't own when RFC1918 addresses would have been fine. As an aside, I seem to remember that the RiscOS IP stack expected people to use 1.1.x.y internally, which is equally nuts

It was a "to-do" caused by people who didn't understand things. The government were using public IPs internally to connect disparate departments/external contractors/etc over VPNs. The "to-do" was people realising that the IPs weren't globally routable (i.e. although they are public IP addresses, their routes aren't actually announced publicly) and therefore claiming that the government should have been using RFC1918 (internal) addresses. The claim was that the government could then release their IP addresses to relieve the global IPv4 address shortage. What the government was doing was pretty sensible: they needed to link up a number of independently administered networks. Using RFC1918 addresses for this task isn't sensible - with no central authority allocating them, you can guarantee that all those network will have overlapping address ranges, so now you're talking about re-IPing a load of networks. And as you hire new external companies you're going to have to instruct them to renumber their entire networks too. Far better to use public IP addresses that you own, which you can therefore guarantee aren't already in use. The second misunderstanding was the naïve belief that releasing a few IP addresses would somehow "fix" (or even make much of a dent in) IPv4 address exhaustion - really it would have extended the exhaustion date by a few days or weeks, which really isn't worth the hassle (hell, given the amount of network renumbering that would have been involved to free up those addresses, they probably wouldn't have been able to release them before the exhaustion date anyway).

Seen this done before. I quite like people doing stuff like that because it is much easier to fire a company that makes it so obvious that they don't know what they are doing. Anyone on your internal network will easily be able to see what addresses you're using anyway. Anyone outside your network won't be able to contact your internal addresses, even if they know what they are. And besides, obfuscating your network doesn't get you any meaningful security, but it does make it harder to maintain (which in turn means you're more likely to leave a gaping security hole somewhere

I'm not sure there's a good solution. Even if Google prioritises the mainstream news channels, it will still be full of bare faced lies (e.g. the contents of the Daily Mail, which I'm sure would be considered a "radicalisation" or "hate speech" website if it weren't so mainstream). The only thing I can think is if Google were to fact-check everything in their search results and assign some kind of "truth score", which seems utterly impractical.

Geoblocking IPs is fraught with problems because people host their servers wherever is cheapest, which is frequently not their own country.

Does it work for non-HTTPS sites? There was a security problem discovered earlier this year relating to HTTPS and PAC files. I've not heard anything recently but maybe the browser vendors have broken things while trying to fix that? New attack that cripples HTTPS crypto works on Macs, Windows, and Linux | Ars Technica UK

For what it's worth, we've recently been in touch with MathsWatch about these problems after some of our customers asked us to investigate: our filter (Iceni) allows Vimeo and YouTube videos embedded in educational sites to be whitelisted (so in theory you can tell it to whitelist the Vimeo videos embedded in mathswatch.com), but this is unfortunately not compatible with MathsWatch because of the slightly unique way that they embed their videos. We've asked Mathswatch if they will make some fairly trivial changes to allow this to work and they've passed on our suggestions to their IT team. So now we're waiting to see if they can implement those changes any time soon but in the mean time they suggest manually whitelisting each video as above (which is obviously quite onerous for administrators).

Just to nitpick, but pretty much everything on the internet is copyrighted. The test is whether you are doing anything which infringes that copyright (i.e. if you are using the work in a way that is not allowed by either your agreement with the copyright holder, or by fair dealing laws). That aside, in my experience almost no one reads error pages, so I'm not convinced including all this blurb is actually of much use

I don't see why they would stop, but I imagine updates to the filtering criteria (URL lists, keywords, etc) have either ceased or will cease at some point soon, so the longer you stay with Bloxx, the more and more our of date your filtering will get. In particular, you're going to be failing your safeguarding obligations if you aren't getting updates to the IWF and Home Office block lists.

YT for Schools hasn't been accepting new signups for years and Google officially announced that it was dead a year ago. I've not seen anything to say that they are pulling the plug for schools that already had a code, but it doesn't surprise me. The new stuff is heavily integrated into Google Apps - it adds quite a few new capabilities but also requires you to buy into the whole Google Apps thing if you don't already.

Pretty easy on our system - add an educational website to the whitelist, tick "Apply to embedded Vimeo videos", job done - all vimeo vids embedded in that site will work. (There's also an option for Youtube).

Steer clear of StartSSL and WoSign - Mozilla have already struck both of them off, Apple has struck off WoSign and Google are planning on pulling the plug on them too. (Frankly, if StartSSL are still even selling certificates without telling you they won't work that's pretty criminal) https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ We've now started to recommend LetsEncrypt for free certificates. Only downside being that you need to run a client on your systems, which is a bit more effort.

I'm certainly not saying that everyone needs a backup line, but pros and cons do need to be weighed up realistically instead of just saying "we have an SLA" and pretending that this somehow magically means no one will put a digger through your fibre. SLAs spell out what level of service the provider _aims_ to give you, and how they will compensate you if they fail - there are situations where they fail and the compensation the SLA says you'll get pretty much never comes close to actually compensating for the level of disruption it causes. The "cloud services" era is causing a lot of folks to shift services out to the cloud because it's cheaper, and in my experience there's normally next to no consideration for what is going to happen if the internet connection dies - again, I'm not saying that moving stuff out to the cloud is wrong, but any cost savings made there do need to be weighed up realistically.

Yep, if someone puts a digger through your fibre, your internet is going down, SLA or no. Ideally a backup line should take a different physical route too (but that's not always possible)

Would the Safer Internet Centre's ticklist be a good starting point? Filtering Provider Responses | Safer Internet Centre

Looks good to me. You may get better prices if you get separate quotes for the web filter and internet connection, but that's obviously more faff for you. Maybe consider specifying any specific internal stuff that the web filter is expected to handle, such as BYOD, whether or not you require real time content inspection, HTTPS interception, etc. RIPE rules require that you justify the use of any IPv4 addresses, so you may want to include a list of external-facing services you want to run. Also consider requiring IPv6 support from both the internet connection and web filter - its certainly not impossible that you'll be wanting to support v6 within the contract period. I'm not terribly convinced by uptime predictions - no service provider can guarantee uptime, the most they can do is give you some (usually pitiful) compensation if they fail to meet an uptime target.

We've got customers on FTTC - seems fine for small schools.

For what its worth, we've got customers on the SWGFL who have completely opted out of the grid's filtering (I believe that the SWGFL filtering is now a separate item which the schools can choose to opt out of and save themselves a bit of cash if they have their own filter).

I must admit that the guidance doesn't specifically say that reports must be timely, but I think taking a week to generate ad-hoc reports would be difficult to defend when compared to other filtering systems which can do it in minutes. As well as the more urgent ad-hoc reports, it seems clear that schools also need to review activity on their networks regularly - we advise our customers to schedule standardised reports to automatically be generated on a weekly or daily basis, so that they can be reviewed to pick up anything concerning. And those kinds of reports aren't just about finding stuff people were/should have been blocked for, it also lets the schools catch children at risk of abuse or self harm, etc. The UKSIC's advice is very clear that the reports must be able to identify the users though, and that's something a lot of the LEA systems can't do yet. Surely schools should still be doing a risk assessment as part of their safeguarding responsibilities, so these things should still be considered even if the answer is "we trust the LEA to do it". I certainly have concerns that at schools that don't have an IT tech there is probably no one reviewing reports/logs and just trust that the filters will catch everything (hint: they won't ).

Yes, although you may need to separate different types of device onto different vlans (if they aren't already) to make things work smoothly.

All of this is possible - how easy and how transparent it is to the end-users is a bit dependent on how your network is already set up and the capabilities of the equipment. It wouldn't surprise me if you can do what you want without significant investment. You're going to want to figure out what you need to log or filter for each group of users, because there are pros and cons that have the be weighed. If you're going to log individual web searches, what specific youtube videos have been watched, etc. then you will need your web filter to do HTTPS interception. That allows it to decrypt the HTTPS traffic, examine it, filter it and log it, but it has the down side that you have to install a certificate on each user's device. If you can't install a certificate on each device, the best you can do is passive HTTPS inspection (different filtering systems use different names for this, such as "HTTPS snooping", etc.). If your filtering system can do this, you can log the host names of the web sites being visited, but nothing especially invasive. e.g. you'll be able to see that the user visited youtube, but you won't know what videos they watched, and you'll be able to see that a user visited google but not what they searched for, etc. Depending on your filtering system, you may be able to choose how invasive its being based on the user name or which network the user is on - i.e. you probably want to go to the trouble of installing certificates on students' devices, but not visitors' devices; so you'd want to have HTTPS interception turned on for the students and only passive HTTPS inspection for the visitors. There's information how HTTPS interception works here: http://www.opendium.com/sites/www.opendium.com/files/https_interception/https_interception.pdf (MODERATORS: if you think it is not appropriate to link this here, please consider just removing this link rather than the whole post Secondly, you need to decide how to identify the users - the nicest way is to use 802.1x authentication and have your wifi controller send RADIUS accounting data to your web filter. If you can't do that, you can probably set your web filter to produce a captive portal page that the user would have to log in to before gaining access to the internet. Again, this is something you may want to set differently for different networks - you might not want to bother identifying guest users.

I'd definitely reiterate what IrritableTech said - the Keeping Children Safe guidelines and UKSIC advice are both very specific about the minimum level of monitoring schools must do. Producing reports that identify users is absolutely required and if you can't do this in a timely manor then I'd say you're not complying with the safeguarding requirements. Plenty of filtering systems out there - shop around, ask for demos; at the very least it'll give you an idea of what's possible so you can compare them to the LEA's systems.

I imagine you'd set your Wifi controller to send RADIUS accounting updates to the SW box.

Your web filter should be able to produce those kinds of reports. e.g. something like: