Opendium_Steve

Are you doing https interception on your filter? The CTIRU block list contains a number of files hosted on https://videos.files.wordpress.com but it doesn't block the whole domain. These individual files can only be blocked if you do https interception. Our system would take the less restrictive approach of allowing access to the whole domain if HTTPS interception was turned off, but it's possible that other systems would opt to be more restrictive and block everything. It might be a problem to report to your filtering provider, especially if you are doing HTTPS interception.

iptables is far more powerful than anything with a friendly UI, so you're going to struggle to find a generic iptables -> something-else converter. You can probably put something together to handle the more restricted subset of iptables' functionality that you're actually using though. I wouldn't mind betting that going through the rules by hand would be better than automating it though - it'll give you chance to review and understand the rules you have in place, remove any that no longer make sense and generally tidy up. We usually migrate firewall rules for new customers by hand and it always turns up a few "WTF?!" moments when it turns up rules that really shouldn't be there!

I've got to agree with @Wave9_Lee - an on-site UTM is much more flexible than a hosted system, especially if you want to use it to control traffic between VLANs (e.g. isolate BYOD networks from your LAN, etc.) And having to change filters when you move ISPs is an almighty pain that you avoid with an on-site system.

I'd strongly recommend just terminating the PPPoE connection on the firewall itself instead of messing about with external routers (it seems very odd if you can't do this - anyone who's still selling firewalls that don't do IPv6 has no business selling network hardware at all). If you really can't get around using a separate router, you should be able to assign a private network between the router and the firewall. i.e.: The router is the PPPoE endpoint, but does not assume any address in the public /29. Instead it has a private address (lets say 10.0.0.254/24). The firewall has a private address in the same network (10.0.0.1/24) and the router has a static route that routes the whole public /29 via 10.0.0.1. The firewall would have its default gateway set to 10.0.0.254. The firewall would also need an address in the public /29 which it would need to be set up to use as the source address for all its outbound traffic. Whether or not you can actually configure this, depends on the router and the firewall though. If they were both linux machines which you could prod the config of directly then it's certainly possible to set it up, but whether a simplified web UI of a consumer grade device will let you is another question.

Your filtering really should be doing a reasonable job of blocking proxy/VPN apps - it it isn't, work with your filtering provider to get that fixed. BYOD at least gives the school some control and monitoring capabilities, even if it isn't as much a you'd like. By removing that you're just pushing the kids onto their mobile data connections so you've lost whatever safeguarding capabilities you had. I guess that pushing the kids off onto 4G reduces the school's liabilities to some extent since it can then be declared "somebody else's problem" but it surely isn't a great thing for safeguarding the kids... We've found that the best thing to do is give kids fairly permissive access to the internet whilst blocking VPNs as far as possible - that at least encourages them to use your network where you can monitor them.

I know I'm going to sound like a stuck record, but whilst systems like Securly may be ok for providing some superficial protection for school supplied hardware while it is off the school network, the UK Safer Internet Centre's guidelines specifically say you need a network based system for protecting people who are on the school's network itself - i.e. not a system that depends on a browser plugin or some kind of client to be installed on each workstation. So if you are relying entirely on a non-network-based system such as Securly to protect your school network, you're probably not meeting your safeguarding obligations.

The only outstanding problem we've got at the moment is one customer who has asked for firewall rules to be relaxed across their network (customer has their own firewall and filter and is using RM purely as an ISP, not for filtering), and RM support have said they wont do this. I can certainly put you in touch with my colleague that is dealing with the customer in question. However, as a more general criticism, our customers who are using RM connections seem to have significantly more ISP-side problems than those using other ISPs, and getting problems resolved seems to be much harder with RM, usually involving weeks of back-and-forth with RM support. I can't comment on the reliability of RM's filtering vs. the filtering offered by other ISPs, but for simple internet connectivity (with the school running their own filters) I'm afraid this has been our experience.

I can't recommend RM - they constantly seem to have reliability problems with their proxies and you end up talking to a foreign callcentre who have very little technical expertise. Some of our customers have unfortunately had to keep hassling them for months to get problems resolved and have had to make repeated change requests for things that RM have said have been done, but which quite obviously haven't.

I read that excellent piece last summer and it was good to reread, so thanks for pointing at it. The guidance isn't terribly prescriptive about the technologies that schools should use for filtering and monitoring, so it's more or less a case that almost anything goes if the school can justify it. However, there have been enough third party interpretations published, such as the one you pointed at and the Safer Internet Centre's that really a school is going to struggle to justify deviating significantly from those interpretations. Certainly, I think that in the event that a serious incident did happen, things wouldn't go well for the school if someone was able to point at a widely accepted "best practice" interpretation of the guidance and ask why they were falling way short of it.

The DfE's "Keeping children Safe In Education" statutory guidance certainly does require both filtering and monitoring. The guidance itself is fairly wishy-washy, but the UK Safer Internet Centre have published a good interpretation of it. In particular, you *have* to block websites that are on the IWF and CTIRU lists. A lot of schools have realised they aren't meeting the requirements that were introduced last summer. A not-insignificant number of those schools were running free filters and had come to the conclusion that none of the free filters could meet the new requirements, which is why they had started shopping around for commercial ones.

Search term blocking on a school filter isn't terribly worthwhile - Google/Bing/etc can do a much better job with their safe search settings than a school's web filter can ever do because they have a lot more data to work with. Safe search is fairly language-agnostic, but you're right that not all search engines support it. Maybe it's worth blocking access to search engines that can't have safe-search enforced by the web filter (not sure how easy that is in Smoothwall. We have been considering a category for that ourselves though).

Tumblr now provides a way for content creators to tag stuff as porn, but almost no one does and Tumblr don't seem to do anything to enforce it. So without a good way of filtering that porn out, allowing it sounds like a bad idea.

I'm not sure that any of the free filters meet the current legal requirements, and adding an additional filter will probably restrict some of the capabilities of the LEA filter (e.g. you may not be able to do age-appropriate differentiated filtering). So be a bit careful that you're still meeting your requirements. We have installed our (non-free) filters in front of LEA filters in the past. Its not always clear which filter needs to be adjusted when things don't work though, so we usually advise against it.

We don't generally do "cloud based" stuff (I'm not really convinced its a great idea for filtering in most situations), but we've installed a few shared systems for schools which are associated with each other, whereby they have a filtering server hosted at one of the schools and all connect into that,either with line-of-sight links between the schools, or with VPNs (or more usually a combination of the two). Where the geography is right, it can be very cost effective to have a single fast internet connection going to one school and shared with others that connect to each other over relatively cheap microwave links. There's no reason why that kind of set up can't be hosted in the cloud instead of at one of the schools.

The UK Safer Internet Centre's interpretation of the DfE's "appropriate filtering" guidance specifically says that filtering must be "Network level - filtering should be applied at ‘network level’ ie, not reliant on any software on user devices". That means something that actually sits between your network and the internet - Iceni, Smoothwall, Lightspeed, Safetynet, etc. all fit into that category, Securly does not. So whilst something like Securly may be worthwhile for filtering school owned devices when they are off-site, I think you might struggle to claim compliance with the guidance if that's all you're using. Also, for what its worth, we spotted a fairly major security flaw in Securly earlier this year, we informed them and they took over 3 months to fix it. Under the new GDPR legislation which comes into force next year, a school could certainly be held liable and fined for that kind of breach. (It was the sort of security flaw that leads to peoples' electronic banking login credentials being sent ununcrypted over the internet, so pretty serious). In response to the original question: You could replicate the existing setup, with the filtering system in a datacentre and replace the school<->council lines with VPNs running over the public internet.

VLANs don't prevent devices from talking to each other, they just prevent them talking _directly_ to each other - i.e. the traffic has to go via a router. Assuming both VLANs use the same internet connection, you'll already have a router between the two networks since that's required to give them internet access. My guess is that the internet router is set up not to forward traffic between the wifi and wired VLANs, so this is where you should be looking. To be honest, it sounds to me like you're going about things the wrong way: - NAT should be avoided wherever possible. Its basically a bodge to deal with the shortage of public IPv4 addresses, and it breaks stuff while offering almost no security. NAT has no place within a LAN - it should only be used when connecting a LAN to the internet. - Since you almost certainly already have a router between the two VLANs, that's where you should be looking. Figure out why that router isn't passing the traffic between the two VLANs - you probably just need to adjust the ACLs. - Adding a second router between the two VLANs is going to overcomplicate the network and provides a second place where ACLs can be misconfigured to inadvertently create security problems. - Depending on your network design, it's probably not actually possible to add a second router without either manually adding static routes to all of the client devices (unmaintainable, and not possible on many devices), using ICMP redirects (an unreliable bodge that requires you to reconfigure the main router anyway) or using some horrendous mix of NAT and possibly proxy-arp (an unreliable bodge that will be an almighty headache in the long run).

There's no reason why 192.168.0.1 address can't talk to 10.132.116.1 so long as they are both on the same LAN (i.e. no hops over the public internet), your routers all know about both subnets and there are no firewall/acl rules blocking the traffic. Start by looking at the default gateway of the machine connected to wifi - that will be something on the same network (192.168.something - lets say 192.168.0.254 for the sake of this example). Figure out what device has the 192.168.0.254 address and check its routing table. Do the same for the web server - it should have a default gateway on its network (lets assume 10.132.116.254). Figure out which device has the 10.132.116.254 address and check its routing table. You should be able to find a route in both directions by tracing through all the routing tables of intermediate devices. In a well set up network I would expect only one or two routers: - Either you'll have a single layer 3 switch on both the 192.168.0.254 and 10.132.116.254 addresses - in this case your problem is almost certainly ACLs on that switch or on your wifi system. - Or you'll have a layer 3 switch handling your wired network and a separate router (the wifi controller, or a separate firewall) handling the wifi traffic. In this case you need to make sure that the layer 3 switch and the separate router have routing for each other. If you've got more than two routers, probably best to start running away from the mess. Be careful to avoid opening up any massive security holes - it goes without saying that the kids on wifi should probably not have free access to everything on the wired network!

Wow, those release notes are proper buzzword bingo aren't they?

Its worth noting that the UK Safer Internet Centre guidelines (which the DfE's "Keeping Children Safe in Education" statutory guidance references) specifically say that filtering must be "network level" - i.e. it has to be a thing that sits between your LAN and the internet, as Iceni, Smoothwall, Lightspeed, etc. do, rather than software that sits on the end-user device (Policy Central, Securly, etc.). That's not to say that you can't use the "client programs" to provide some level of filtering for school owned devices when they aren't on the school's network, but the Safer Internet Centre don't consider them robust enough to be the only line of defence for a whole school. That's especially true for BYOD type setups, where you can't reasonably prevent kids from uninstalling such software from their own devices. So as mats says, these days you're really expected to be able to inspect HTTPS traffic for both filtering and reporting, and you should be able to do automated reports of stuff like concerning search phrases, etc. irrespective of what type of device was used - school workstation, school tablet, user's phone (in the case of a BYOD network), etc. Inspecting HTTPS traffic means you're handling sensitive data, so you need to be sure that whatever solution you choose keeps that data secure - that might sound obvious, but I've recently reported a serious security problem to a popular filtering vendor as it turned out they weren't handling HTTPS data securely at all! The UK Safer Internet Centre filtering guidelines are well worth a read for anyone who hasn't already done so: https://www.saferinternet.org.uk/advice-centre/teachers-and-professionals/appropriate-filtering-and-monitoring/appropriate-filtering

Well that's true, but once you've tried it for a year you might opt for a longer renewal term if you're happy.

Doesn't that rather stuff any schools with BYOD? Surely if you don't do user based filtering on BYOD networks you're not fulfilling your safeguarding responsibilities?

Can I ask for opinions on how folks budget for multi-year filtering contracts? if you take out multi-year contract, do you pay a year at a time, or the pay whole thing up front? And why do you do it that way (e.g. because that's just the way the supplier expects you to pay, because you get a discount, a preference for budgeting one way or the other within the school, or something else)?

Someone may correct me if I'm wrong, but I think Securly requires client-side software on the user's device, and the UK Safer Internet Centre is of the opinion that client-side software isn't robust enough as a school's primary filter. I'll agree with diladele as well that installing a third party's root CA certificate is a really bad idea for security (many filters provide each school with a unique certificate instead of having a single one for everyone). (Note: I'm not particularly familiar with Securly)

Thanks for this. We've now categorised this as Dating and everyone will get the update within the next hour.

Who's doing ADSL with an SLA guaranteeing 100% uptime? Openreach don't do a 100% uptime product...