Securly

[nathan]

Has anyone used Securly for website filtering and can offer any feedback? It's a DNS based system instead.

 

https://www.securly.com/

[nathan]

Bit worried about this bit;

 

We identify a small number of sites (Google, YouTube, Facebook among them) that need decryption to keep kids safe. All other sites go straight out.

 

So they don't decrypt all SSL traffic.

Edited March 6, 2019 by nathan

[rogerdnixon]

We use it - both for Chromebooks (so using the extension) and the DNS product for everything else. Works well and is easy to us. Authentication is via your G Suite account. Reporting is good. Parents like the parents app which allows them to control the offsite filtering (within limits we set) and see what their little darling have been doing. So pretty good for a 1:1 Chromebook setup. They offer a full SSL decryption version that we use. You also get Auditor and the Teacher Dashboard as well which nicely links to Google Classroom.

 

BYOD is a bit of a pain as users have to install the SSL certificate to get anywhere.

 

You need some sort of firewall as well - we use ClearOS which does the job fine.

[Opendium_Steve]

Has anyone used Securly for website filtering and can offer any feedback? It's a DNS based system instead.

I'm of the opinion that Securly doesn't meet the UKSIC guidelines, which say that filtering systems must be implemented at "network level". My interpretation of this is that the system should be topologically between the students and the internet, so that the settings on the user's device can't be intentionally changed or inadvertently misconfigured into an unfiltered state.

 

Its a bit open to interpretation, and Securly claim that a DNS based solution is "network level", but I think we're going to have to agree to disagree on that point - simply having incorrect DNS settings would leave students unfiltered, and that is not good.

[rogerdnixon]

I'd agree that guidelines are open to interpretation. Regarding incorrect DNS settings - they are set at the network level and if someone on an unmanaged device puts something else in (say Google DNS) they get no internet at all as we block external DNS at the Firewall level. On Chromebooks (our main device type), it does not matter what you put in as the DNS settings as filtering is done at the device level and assuming you have appropriate policies in place there is nothing a user can do about it and it works on any network.

 

All I'd say is that its much easier to use and seems way more effective than anything else I've seen used at other schools or used myself and parents love it and students hate it!

[mavhc]

Managed machines filter at the device level, then no problem with decryption. HTTP3 and encrypted SNI will make network level harder.

 

Unmanaged at network level.

[nathan]

Managed machines filter at the device level, then no problem with decryption. HTTP3 and encrypted SNI will make network level harder.

 

Unmanaged at network level.

 

What products are available that do filtering at the machine level as opposed to the network level?

 

especially for tablets (android, IOS). I don't understand how this could work

Edited March 7, 2019 by nathan

[Opendium_Steve]

What products are available that do filtering at the machine level as opposed to the network level?

especially for tablets (android, IOS). I don't understand how this could work

 

Securly has a device-level ChromeOS plugin, then there's stuff like Qustodio, which works on most platforms but is more of a "parental control system" rather than whole-school system (beware that the iOS version of Qustodio is fundamentally incompatible with most school filters since it VPNs the traffic back to their filtering servers - this is down to limitations in iOS I believe - the Android version works differently and doesn't send all the traffic over a VPN).

 

Impero will do device level reporting (but I don't think filtering?), and I think it also doesn't work on iOS. I could be wrong - its not something I've paid close attention to.

 

Again, I'd be very hesitant with any of these systems on their own, because I don't think relying only on "device level" stuff is going to meet the UKSIC guidelines.

Edited March 7, 2019 by Opendium_Steve

[mavhc]

iOS is the main problem, can't get the low level access required. Impero, senso etc can filter based on url or content, using an extension or local interception.

 

If you can control it to be impossible for a user to disable then it's ok.

 

But they don't have massive automated lists of website categories like network level devices

[Opendium_Steve]

iOS is the main problem, can't get the low level access required. Impero, senso etc can filter based on url or content, using an extension or local interception.

If you can control it to be impossible for a user to disable then it's ok.

But they don't have massive automated lists of website categories like network level devices

I was talking to someone from Impero and was surprised when they said they only use the IWF keywords list, not the URL list - was a bit surprised because I assumed they would scan the screen for URLs too.

[Courtney_Impero]

I was talking to someone from Impero and was surprised when they said they only use the IWF keywords list, not the URL list - was a bit surprised because I assumed they would scan the screen for URLs too.

 

Hi @SteveHill,

 

At Impero, we follow the UKSIC guidelines for appropriate monitoring. For filtering systems, the UKSIC ask that they include the IWF CAIC list (URL based) in their systems, whereas they ask monitoring systems to be members of the IWF. Going beyond this, Impero have opted to use the keyword list provided by the IWF to detect this activity and work closely with them to develop this further.

 

Hope this helps.

 

Courtney @ Impero

[Opendium_Steve]

At Impero, we follow the UKSIC guidelines for appropriate monitoring. For filtering systems, the UKSIC ask that they include the IWF CAIC list (URL based) in their systems, whereas they ask monitoring systems to be members of the IWF. Going beyond this, Impero have opted to use the keyword list provided by the IWF to detect this activity and work closely with them to develop this further.

 

Thanks for the clarification!

[mavhc]

Hi @SteveHill,

 

At Impero, we follow the UKSIC guidelines for appropriate monitoring. For filtering systems, the UKSIC ask that they include the IWF CAIC list (URL based) in their systems, whereas they ask monitoring systems to be members of the IWF. Going beyond this, Impero have opted to use the keyword list provided by the IWF to detect this activity and work closely with them to develop this further.

 

Hope this helps.

 

Courtney @ Impero

 

Have you considered adding the url list too?

[Courtney_Impero]

Have you considered adding the url list too?

 

Hi @mavhc,

 

It would be great to hear from customers who would like us to add the URL list to our keyword libraries and what benefit they see from having this.

 

I welcome anyone who does to send me a PM to discuss this further

 

Many Thanks,

Courtney @ Impero

[Securly_Chris]

Hi,

 

I'm the tech manager for Securly UK, must have missed this post but thought I'd try to help with your questions.

 

While we’re founded in the US Securly's had customers in the UK for many years now (good to see some on this thread! Hi Roger! ). We are also now based in the UK with offices in Glasgow and London.

 

Securly is fully PREVENT compliant, as IWF members we implement the IWF CIAC blocklist, we also work with MET Police and the home office and implement their CTIRU counter-extremism blocklist. We follow UKSICs guidelines around filtering and monitoring, you can find us listed on their website under both Filtering and Monitoring providers.

 

Regards network-level filtering, UKSIC recommend: "Network level - filtering should be applied at ‘network level’ ie, not reliant on any software on user devices". Being cloud-based Securly is very much applied at network level. We don't require software to be installed or hardware for that matter! DNS and our SmartPAC are network settings that can be distributed and enforced on your network very easily and will cover all devices, in and out of school.

 

With over two thirds of the web being encrypted it’s also important that we support HTTPS interception. We provide managed HTTPS decryption or full decryption depending on your requirements. Either allow us to provide both dynamic content filtering and real-time monitoring of what your students are searching and posting online.

 

Hope that helps answer your questions, please get in touch if you want to test drive and check it out for yourself!

 

-Chris

[mavhc]

UKSIC fail to mention TLS, SNI encryption, HTTP3, etc though. "Network level" and also "Installing a CA on every device". Then you have WebRTC and WebSockets

[Opendium_Steve]

UKSIC fail to mention ... SNI encryption, HTTP3, etc though.

 

Probably because these are _currently_ largely non-issues for schools. They will become issues in the future, but not a big concern immediately.

 

"Network level"

 

My issue with "network level" is that it's a very ill defined term. I queried the rationale for this point with David Wright (SWGFL and UKSIC) and his explanation to me was:

 

"In terms of this particular aspect, we were keen to encourage schools to consider if their filtering solution was reliant on device based software (or device configuration). We were keen that any device (particularly third party devices) that are connected to a school network should receive a filtered internet stream by default and with no device client software required (or device configuration required); safety by design."

 

Make of that what you will

 

"Installing a CA on every device".

 

In my opinion, for student's, there's no way to avoid installing *something* on each device. Whether that be a certificate or some kind of filtering client. That is a fact of life brought about by most traffic now being TLS encrypted.

 

For other users, things are a bit more fuzzy - do you want to decrypt HTTPS for your staff's traffic? The majority of our schools say yes, but we have a few that don't want to do this. Maybe the UKSIC should give some guidance on this. Main things to consider:

- Decryption gives you a better audit trail.

- Decryption might give you better filtering (depending on the filtering product you're using).

- Need to protect against a teacher pulling up inappropriate content on an electronic whiteboard in front of a class of kids by accident.

- Need to consider what happens if a child gets a teacher's password.

- Need to consider what happens if a teacher turns out to be having an inappropriate relationship (may need to produce audit logs as evidence, etc).

 

For guests, you probably don't need to decrypt HTTPS, but you probably do want some basic filtering and auditing. That means you don't need to mess about installing certificates on guest devices.

 

Then you have WebRTC and WebSockets

 

These protocols rather blur the line between "web apps" and non-web protocols.

 

Would you want to treat WebRTC fundamentally differently to normal RTC? Similar question for WebSockets - would you want to treat this differently to anything just connecting over TCP?

 

Again, I think schools could use better guidance for stuff that traditional web filters don't filter. This includes how to handle apps that fundamentally can't be content filtered, such as whatsapp, which you just have to make a decision as to whether to allow or block the entire app. The "more guidance" comment came up repeatedly at last year's CTIRU filtering vendors conference!

[mavhc]

> Probably because these are _currently_ largely non-issues for schools. They will become issues in the future, but not a big concern immediately.

 

But when signing up for a product I want to know their plans are better than: err, can you just block all the new things?

 

> My issue with "network level" is that it's a very ill defined term. I queried the rationale for this point with David Wright (SWGFL and UKSIC) and his explanation to me was:

 

> "In terms of this particular aspect, we were keen to encourage schools to consider if their filtering solution was reliant on device based software (or device configuration). We were keen that any device (particularly third party devices) that are connected to a school network should receive a filtered internet stream by default and with no device client software required (or device configuration required); safety by design."

 

Really you need both, which is a problem when you have 5 OSes to support, and one of those is iOS where you can't do a lot, and depending on how you filter, multiple browsers.

 

> In my opinion, for student's, there's no way to avoid installing *something* on each device. Whether that be a certificate or some kind of filtering client. That is a fact of life brought about by most traffic now being TLS encrypted.

 

> For guests, you probably don't need to decrypt HTTPS, but you probably do want some basic filtering and auditing. That means you don't need to mess about installing certificates on guest devices.

 

Yeah, that's how I have it set up for BYOD.

 

> These protocols rather blur the line between "web apps" and non-web protocols.

 

Web filtering vs Internet filtering, everything is "Sort of web" now

 

> Would you want to treat WebRTC fundamentally differently to normal RTC? Similar question for WebSockets - would you want to treat this differently to anything just connecting over TCP?

 

It's more does the software also filter that, does it understand those protocols?

 

> Again, I think schools could use better guidance for stuff that traditional web filters don't filter. This includes how to handle apps that fundamentally can't be content filtered, such as whatsapp, which you just have to make a decision as to whether to allow or block the entire app. The "more guidance" comment came up repeatedly at last year's CTIRU filtering vendors conference!

 

Right, no need to use the CA system when you're distributing the app and running the server, just pin one cert, done. So you're back to needing device level filtering.

[nathan]

>

 

Really you need both, which is a problem when you have 5 OSes to support, and one of those is iOS where you can't do a lot, and depending on how you filter, multiple browsers.

 

I'm trialling Lightspeed Relay (just on my laptop) which is agent based, works pretty well other than that when i go to uninstall the agent from my laptop it BSODs. There's an option for changing the DNS settings to them for BYOD devices, you'll get less control using DNS but there isn't anything stopping you from using this as a default meaning if the agent isn't installed on a device in the school you'll still get a network level filtering.

[ADMaster]

I’ve been running Securly on chromebooks for a month or two now. It is great for those devices with the extension installed. The reports are very easy to read and get a users history when needed.

I’ve not implemented DNS filtering yet because I’d have to do it for my whole network and not just one OU, subnet or vlan.

The biggest issue I see with the DNS filtering is lack of granular control. Everything is based off of Google OU or public IP address.

With an onsite filtering solution I can add a single IP, subnet, user etc and give it a policy. Securly DNS would require me to reach out to my ISP and map a public IP to that internal IP or subnet.

I’d like to see Securly develop some sort of onsite / hybrid solution that would allow me to create policies for local IP addresses.

[mavhc]

I’ve been running Securly on chromebooks for a month or two now. It is great for those devices with the extension installed. The reports are very easy to read and get a users history when needed.

I’ve not implemented DNS filtering yet because I’d have to do it for my whole network and not just one OU, subnet or vlan.

The biggest issue I see with the DNS filtering is lack of granular control. Everything is based off of Google OU or public IP address.

With an onsite filtering solution I can add a single IP, subnet, user etc and give it a policy. Securly DNS would require me to reach out to my ISP and map a public IP to that internal IP or subnet.

I’d like to see Securly develop some sort of onsite / hybrid solution that would allow me to create policies for local IP addresses.

 

Do you only have 1 external IP?

[Opendium_Steve]

But when signing up for a product I want to know their plans are better than: err, can you just block all the new things?

Fair point. Although call me cynical, but are you going to trust the answer from a sales person, given that they have probably never been asked that question before and aren't expecting anyone to notice if it doesn't work?

I'm not convinced asking the answer you get is going to be worth much unless you're going to test it and send the product back if it turns out it doesn't do as promised.

Really you need both, which is a problem when you have 5 OSes to support, and one of those is iOS where you can't do a lot, and depending on how you filter, multiple browsers.

Actually, iOS seems to be much less of a problem for us than Android. Google seem to be much more opposed to HTTPS decryption than Apple are.

Web filtering vs Internet filtering, everything is "Sort of web" now

I'm not sure I agree with this

There are still plenty of apps that aren't accessed through a web browser and use non-web protocols. A big distinction between web and non-web stuff is that web uses well defined protocols that can be content-inspected, whereas the majority of non-web protocols are proprietary, or use end-to-end encryption, or carry types of media that can't be sensibly content-filtered.

It's more does the software also filter that, does it understand those protocols?

Taking websockets as an example, like HTTP/HTTPS you can obviously filter the URI that the client connects to, but beyond that I'm not convinced there's much filtering you can do. The protocol being transmitted over the websocket is basically undefined, so how you can inspect it is fairly limited.

Right, no need to use the CA system when you're distributing the app and running the server, just pin one cert, done. So you're back to needing device level filtering.

And schools simply don't know how to handle this situation - you have an app that you can't filter, so do you allow it and accept that it might be a risk and the school might catch hell for it. Or do you block it, everyone switches to 4G and uses that app anyway, and now you've lost the ability to safeguard the kids when they're using protocols you can filter/audit.

The fundamental problem here can't be resolved without the cooperation of all the app vendors. The likes of Facebook and Google are too big to be influenced by anything short of legislation, and there are way too many random app vendors to police them all. So the only thing to be done is give the schools well thought out guidance on the best thing to do, and the government is currently failing to do that. (Arguably the government is failing to do a lot of things at the moment

Edited March 22, 2019 by Opendium_Steve

[mavhc]

Pornography sites are banned by default on mobile phones, but general use sites that contain pornography aren't. Not much that's possible to do except inform parents of the risks.

 

Then there's free wifi everywhere. Probably with more stuff unblocked.

 

Google/Apple are really the only place decent filters could be implemented for phones. https://support.google.com/families/answer/7087030?hl=en is a decent start I guess

[nathan]

I'm trialling Lightspeed Relay (just on my laptop) which is agent based, works pretty well other than that when i go to uninstall the agent from my laptop it BSODs. There's an option for changing the DNS settings to them for BYOD devices, you'll get less control using DNS but there isn't anything stopping you from using this as a default meaning if the agent isn't installed on a device in the school you'll still get a network level filtering.

 

Further to this, it looks like you cant use the BYOD DNS changes as a base level of filtering as it would re-write any rules.

 

I'm trying to investigate if you from a firewall level you could block unfiltered requests. The relay uses the following ports;

 

• TCP/UDP-443

• TCP/UDP-3478

• TCP-5349

 

No port 80 is good, but most sites are 443 now - not sure how to distinguish the difference between traffic coming from the relay agent or direct from a unfiltered device.