Jump to content

Opendium_Steve

Members
  • Posts

    385
  • Joined

  • Last visited

Everything posted by Opendium_Steve

  1. Yep, that's what I found. We had a school being DDoSed, phoned up Virgin to ask if they could help and they basically said "a school wouldn't be able to afford our DDoS protection", and that was that.
  2. Depends on exactly what you're firewalling - if its just internet traffic then putting the firewall at the ISP might be fair enough. If you need to firewall your internal networks (e.g. controlling traffic between lesser-trusted networks and trusted stuff) then you really want it on-site. You don't want traffic between your local networks having to go up to your ISP and back down again. If its just DDoS protection you want, you don't need a full firewall at the ISP, just ask your ISP about their DDoS protection products in addition to running your own on-site firewall. Your mileage may vary though - I've seen a school DDoSed once (by a disgruntled ex-student!) and Virgin Media were pretty unhelpful when it happened, because they school weren't paying them enough. I'm a big believer in UTM products - as applications are increasingly mixing different types of traffic, keeping your firewall and web filter separate seems a bit of a nonsense to me. So then you're talking about whether you want to put the web filtering on the ISP's end of the connection too (which is exactly what folks like @SchoolsBroadband do, of course).
  3. We've always left the contract duration up to the school, and certainly different schools want to do things in different ways so I think flexibility is important. Multi-year contracts often come with some advantages such as spreading the cost of any hardware rather than paying for it all up-front. But at the same time, it's a big commitment, so some schools prefer to stump up for hardware up-front in exchange for a shorter commitment. One size definitely doesn't fit all.
  4. If you will be running an on-site filtering system rather than going for an all-in-one internet connection, my advice is to get the new filtering system set up on your old connection before switching the connection itself over. Nothing worse than changing too much all at once, in my experience!
  5. iOS can (currently) be man-in-the-middled without too many problems (some apps use cert pinning and can't be inspected, but at the OS level at least MITM works). However, Android devices are hostile to MITM - apps targetting Android API level 24 and above default to not trusting custom CA certificates, even for MDM managed devices. This isn't a default that the user or network administrator can change, it is a default that only the app developer can change, and of course the majority of apps will not change this default. This is Google's stated policy[1], and increasingly prevents Android devices from being filtered or monitored satisfactorily. This is not FUD, it is fact and backed up by what Google has said publicly. Yes, and as I said, these "very good HTTPS inspection solutions" do not work on an increasing number of apps and an increasing number of Android devices because of the stated policies of some of the big brands. Pretty much all the school online safety systems support HTTPS decryption of ChromeOS at the moment. However, Google's stated position on these things is that (a) apps running on Android devices will not be decryptable without each app developer opting into decryption, and (b) they indent to gradually move towards unifying ChromeOS and Android into a single operating system. There is significant concern in the online safety industry that this will lead to ChromeOS following the Android lead and becoming hostile to decryption in the future. [1] https://android-developers.googleblog.com/2016/07/changes-to-trusted-certificate.html
  6. Possibly, although it seems more likely to me that hybrid systems will start to become common (network based filtering which gets fed secondary information from on-device agents where possible). I'm sure the guidelines will continue to evolve to accommodate those kinds of changes. This came up for discussion at the recent CTIRU safeguarding conference, which was attended by many filtering providers, ISPs, and folks from the home office and police - I have drafted a report on the conference that CTIRU are looking over at the moment to make sure it doesn't say anything we're not supposed to say in public - probably be published in a week or two. The feeling I got at the conference is that this is a problem that everyone knows about but none of the filtering vendors want to talk about because, frankly, who wants to be the first vendor to stand up and say "we can't filter $thing" (the fact that nobody else can either is easily overlooked). I can probably see guidance or legislation being updated in the future to prohibit schools from purchasing devices / using apps that can't be adequately monitored - Android being entirely banned from schools could well make the likes of Google rethink their strategy. Obviously that probably doesn't help with BYOD though. There's also push-back from businesses on the same things, because obviously they often want to be able to do malware scanning at the network border, and also scan data to make sure that confidential business information isn't being leaked. It will be interesting to see where the future takes us, but it's sure to be a bumpy ride. One thing often overlooked is that the days of being able to do what you like with your own device are long gone - Apple is ultimately in control of what you can do on iOS, Google is ultimately in control of what you can do on Android, and if those vendors decide they don't want to allow an online safety agent to run on the devices, you're screwed. In that respect, an on-device agent isn't too different from HTTPS interception - it works until the device vendor decides it doesn't, and Apple/Google/Microsoft/Facebook/Twitter, etc are all way too big to be influenced by a couple of schools screaming at them. I was talking to someone at Impero the other day about exactly this - there are some types of device that they have extremely reduced functionality on because the OS simply doesn't let them monitor the things they need to. The same is also true with things like Chrome plugins - you're entirely reliant on the software vendor (Google in the case of Chrome) allowing you to do the monitoring you want to do. Schools certainly need better guidance on how to handle 4G devices within the school, and also how to handle apps that can't be filtered at all.
  7. And indeed, if you're handing over PII to another company, you need a data processing agreement with them that establishes exactly the things you mentioned.
  8. I don't think anyone said that. @SchoolsBroadband pointed out that installing extra software on BYOD devices may be problematic, and I pointed out that the Safer Internet Centre specifically say an on-device agent is not good enough. That's not my opinion, it's the opinion of the Safer Internet Centre . Now, Keeping Children Safe in Education doesn't actually set any hard and fast rules and basically says the school needs to do a risk assessment and make their own decisions; so you can ignore that advice and do your own thing. But in my opinion, if you are going against very specific guidance, you really need to have dotted the "i"s and crossed the "t"s to show that you have assessed the risk and stated the reasons why you think it is acceptable. As I said, it wasn't based on my opinion, it was based on the guidance published by the Safer Internet Centre. However, if you want my opinion (and I fully accept that I am biassed ), it is that on-device filtering inherently has a lower level of security than network level filtering - there's more scope for students tampering with on-device software, there's more scope for the software simply breaking and you ending up with a few devices not being filtered without noticing. But since there are no hard rules and you're expected to use a risk based approach, "less security" doesn't necessarily rule it out, it just means you better be damned sure you document why you're accepting less security.
  9. If you have 802.1x authenticated wifi, this needs to be backed by a RADIUS server. The RADIUS server needs to be backed by a directory server, and last time I checked, Gsuite couldn't be used for this purpose. So you may need to keep a local directory server for that. (Note, I think the passwords on your AD server can be synchronised up to Gsuite but not the other way around). And if you take your workstations off the domain, I would imagine that your web filter wouldn't be able to do single signon to identify the users.
  10. How does user identification work with that? For Windows workstations, most systems use Kerberos authentication, which can't be done with a transparent proxy. Obviously for BYOD and 1:1, transparent is fine since you just use 802.1x to log the device onto the network.
  11. You could pseudonymise peoples' names (i.e. replace each with a unique identifier and keep hold of a spreadsheet of IDs and the associated names). That way you would be in the loop and be able to make a decision if anything needed to be deanonymised. Depends how much effort you want to go to though
  12. Have a look through the "provider responses" on the safer internet centre website: https://www.saferinternet.org.uk/advice-centre/teachers-and-school-staff/appropriate-filtering-and-monitoring/provider-responses-0
  13. Sounds like "its definitely secure because I haven't seen any evidence to the contrary" rather than "its definitely secure because I tested it". If it isn't segregated onto a separate VLAN, it isn't going to be secure, sorry.
  14. I'm not familiar with Relay, but a quick look suggests that it requires some kind of agent on every device (similar to Securly, etc I guess?). As @SchoolsBroadband says, I can't imagine this working well for BYOD, but also the UK Safer Internet Centre's "Appropriate Filtering" guidelines specifically say "filtering should be applied at ‘network level’ ie, not reliant on any software on user devices".[1] As far as I can tell, this means that it is *not* ok to use the likes of Relay/Securly/etc. as the primary filtering system for your network. By all means, use these systems *in addition* to your normal filtering in order to provide some off-site protection for school owned devices, but not as a replacement to a network level filter. Obviously check with your filtering vendor to make sure that these additional systems are compatible before you make a purchase, of course. Another thing that springs to mind from my personal experience in developing online safety stuff is that separating web filtering and firewalling seems a backward step - the trend is more and more integration between web filtering and firewalling, since the world is no longer neatly divided into "the web" and "everything else" - applications frequently mix web traffic with other protocols and there is more and more pressure for online safety systems to stop putting a hard distinction between them. Hence the advent of UTM products from all the major vendors which try and bring these different aspects together. Lightspeed are a very US centric company, and often don't fully appreciate the UK guidelines / requirements. 1. https://www.saferinternet.org.uk/advice-centre/teachers-and-school-staff/appropriate-filtering-and-monitoring/appropriate-filtering
  15. Ubiquity is pretty good kit these days (there were a few features that were missing in the early days, such as Framed-IP-Address in the RADIUS accounting data, but that's long since been implemented and seems to work ok). Not heard of any serious problems. As MatthewL says they are restricted on the number of SSIDs they allow, but having lots of SSIDs kills your network bandwidth, so you should avoid it anyway - realistically you shouldn't need more than 2 or 3 SSIDs. Typically I do something like: * The main SSID - uses 802.1x authentication, backed by Radius - shoves people into the appropriate VLANs based on their authentication credentials (so staff go in a separate vlan to students, etc). * A WPA2 PSK authenticated VLAN for those few troublesome devices that don't support 802.1x. * Maybe a guest SSID... although this can be done through the main SSID instead if you prefer.
  16. Out of interest, what kind of hardware are they using for those devices? I was under the impression that Fortinet devices used dedicated hardware acceleration for deep packet inspection?
  17. Why do you need to transmit *all* traffic to a remote location? Surely a MAC filtered link (as you'd get out of a normal switch port) is what you want? In that case, just connect the switch at one site to the switch at the other site via something like a point-to-point Ubiquity wireless link (already mentioned). I think you're conflating terminologies - you'd use a VPN tunnel across the internet, not across a dedicated wireless link (except in a few specific circumstances). For the most part you can treat a point-to-point wireless in the same way as you'd treat a cable.
  18. Sounds reasonable - I'm assuming no BYOD (or at least, no child owned BYOD)? Coz IMHO you do need to intercept kids' traffic. Depends on the filtering system you're using (you don't specify what you've got). - The filtering system always knows what IP address a client is connecting to, but that isn't usually a lot of help. - If your filter supports a passive HTTPS inspection mode, it will know what host name they are connecting to by examining the server name indication sent by the client and can filter based on that (beware though: this is information sent by the client and can therefore be spoofed. You're probably not going to be able to stop people using VPNs.) No certificates required for this. It also won't know the path part of the URI, so forget being able to do stuff like block the BBC games site at the same time as allowing the rest of the BBC. - Full on active HTTPS interception lets the filter see the whole request and is obviously the best option if possible. Requires a certificate installed on each client though. And yes, as has already been pointed out, think carefully about how you identify users. Kerberos single signon is probably the best option for schools with AD, but for everyone else you're probably going to have a separate pop-up proxy authentication box each time a user logs on to a machine. (KCSIE says what is "appropriate" is down to a risk assessment, but the UKSIC guidelines specifically say you should identify users, so...)
  19. If you encourage parents to install "parental control" software on their childrens' devices, please please talk to your filtering provider first since they should be able to make some recommendations about what will/won't work. A lot of the parental control systems VPN all of the child's traffic back to a central server, even when connected to the school's wifi, which means the school can't monitor the traffic. We had the DSL at one school email all the parents with a list of parental control software he thought they should install without having even talked to the school's ICT folks - needless to say he very quickly had to apologise to parents as soon as it was pointed out that the software he had recommended would bypass the school's own filtering and monitoring. Some parental control software is ok though, and obviously any network based stuff at the mobile provider's end is fine since it won't be used when on the school's wifi.
  20. Hampshire were doing a lot to incite fear into schools making noises about leaving a couple of years back. Lots of "if you use another provider you will fail your Ofsted inspection" type of noises!
  21. A number of our schools have moved off LA connections and seem pretty happy. The main thing seems to be to make sure you keep all the suppliers in the loop about scheduling, etc. so that everything is ready to go on the right dates. Depending on whether you are going to get filtering from your new ISP or do it on-site, you may be able to move things over on a piecemeal basis, which can be a bit easier than switching everything at once (e.g. get the new filtering system in on your old connection and be happy with its configuration before swapping the connection itself).
  22. Yes, page 94 of the 2018 edition: So the DfE have definitely weaselled out of giving any useful advice there. Yes, I presume they are talking about policies and discipline rather than any technical means. e.g. A school could tell everyone that all phones must use the wifi, not 3G/4G while on the school's premises, but realistically how can you enforce that? Anyway, a lot of students aren't technical enough to ensure they comply with that kind of rule even if they wanted to. Banning mobile phones entirely for the whole school day sounds a bit unreasonable. Jamming phone signals is illegal, I think passively blocking them is legal (e.g. foil lined walls) but I'm not sure schools want to go down that route either. Don't worry - I was pretty incredulous the first time I read the guidance. The UK Safer Internet Centre's advice is that when choosing a filtering system you should "To what extent does the filter system block inappropriate content via mobile and app technologies". This is also pretty unhelpful since it doesn't address the fact for many apps, no filtering system can "block inappropriate content" without blocking the whole app. On the other hand, Ofsted inspectors have pulled up some schools for blocking too many social networking apps, because this left the kids unable to communicate with family and peers. So schools are getting very conflicted advice.
  23. Different schools have different, but equally reasonable, attitudes to this stuff: If you allow most apps, the kids will use your wifi. Some apps can't be monitored and the school incurs some liability if the kids get up to no good, but a lot of traffic can be monitored, allowing you to monitor the kids' online behaviour for safeguarding purposes. If you block an app that the kids decide they "need" to use, they are still going to use that app (and possibly get up to no good with it) - they will just use 4G instead of your wifi. Now none of their traffic is on your wifi, so you lose the ability to monitor the traffic that you otherwise would have been able to. On the other hand, if something bad happens, the school can disclaim all responsibility by pointing out that the children weren't using the school's wifi at the time. But this doesn't help safeguard the kids, of course. There isn't an easy answer and we've got customers in both camps. I think both positions are pretty understandable though (I do wish the DfE, Ofsted and the Safer Internet Centre would come up with some sensible guidance on this - the current Keeping Children Safe just says that schools "should carefully consider how [3G/4G] is managed on their premises" which doesn't really cut it does it?).
  24. WhatsApp used to publish a list of IP addresses, but many of the IP addresses changed some time ago and they no longer publish the IP address list. We now use a combination of deep packet inspection and our own IP list derived from Facebook's AS number to control WhatsApp. Voice/Video is peer-to-peer traffic though, so the only way to control that is with deep packet inspection. (The official IP address list is still available to the mobile phone network providers, but Facebook flatly refuse to give it to anyone else, even filtering providers like ourselves - no idea why!)
  25. Out of interest, will Symmantec refund you for certificates that are no longer trusted? It is, after all, their fault that everyone is distrusting them...
×
×
  • Create New...