The BYOD Filter is a feature of Lightspeed Systems filtering solutions. The purpose of the BYOD Filter is to provide schools with a CIPA compliant way to filter BYOD/Guest devices or unique devices that cannot support one of Lightspeed’s filtering agents.
You can access the BYOD Filter by logging into Launch with your Google, Office 365, or Lightspeed Systems credentials and clicking the appropriate tile from your Launch dashboard.
From the BYOD Filter menu, you will be able to obtain setup information, configure settings, and view reports.
Note: Any change you make to BYOD Filter settings, categories, or reports will take approximately 15 minutes to take effect on your clients.
1. At the top you will see the snapshot report. This report identifies how many categories and how many websites have been blocked or allowed in the past 7 days.
Hovering your mouse over any of the categories will open up a tooltip that will compare the current 7 day period to the previous 7 day period.
Clicking on the More button in between the two categories will bring up the BYOD Reports menu.
The BYOD Reports menu allows you to run detailed reports on your BYOD filtered devices.
You can run four distinct reports: Blocked Categories, Allowed Categories, Blocked Websites, and Allowed Websites. Simply click the corresponding tile to navigate to that report.
You can adjust the report date range by clicking the dropdown menu. The menu defaults to Today, but also allows you to select Yesterday, Last 7 Days, and Last 30 Days as options.
You can search for specific categories or websites by utilizing the Search box in the top left.
The BYOD Setup menu can be found right under the Snapshot Reports. From here, you can setup your DNS servers and assign IP ranges to filter. The DNS Servers field identifies the IP addresses of our DNS Servers. These addresses will be automatically set by Lightspeed Systems. The DNS addresses assigned will vary by region.
The IP Ranges to Filter field allows you to identify which IPs to filter.
Enter a name in the IP Ranges Name field, the start IP in the IP Start field, and the end IP in the IP End field. Click Add to add the IP Range. This should be the external IP of your school. Once an IP Range has been added, you will see it added at the bottom. To delete an IP Range, simply click the “x” to the right.
Normally Blocked/Allowed Categories
You will find a list of Normally Blocked Categories under the Setup menu. These categories determine which kinds of websites are automatically blocked by the BYOD filter. The categories are divided by topics, such as “adult”, “forums, chat, email”, “security”, and “violence.” These categories are normally blocked by Lightspeed Systems due to their inappropriate content.
Below the Normally Blocked Categories, you will find a list of Normally Allowed Categories. These include normally allowed and safe topics, such as “Advertising”, “Business and work”, “Education”, and “Family Life.”
It will be up to you to determine which categories you want to block or allow for your students. You can manually block or allow a category by clicking the button to the right. Red, left-aligned buttons () indicate a blocked category. Green, right-aligned buttons () indicate an unblocked category.
You can easily block or unblock all categories within each Normally Blocked Category and Normally Allowed Category section. Simply click Allow All or Block All next to the section title and all categories within that section will automatically be allowed or blocked.
Customers need to configure their BYOD devices and guest networks with this DNS. Customers should use a separate DNS for users that have user agents installed.
You can learn more about Lightspeed’s database categories in this Web Filter article.
SSL Filtering vs SSL Decryption
SSL Filtering is the ability to see, make allow/block decisions, and report on https domains. (E.g., seeing that a user is attempting to visit https://www.google.com.)
SSL Decryption is the ability to see the full details of the activity on those secure sites. (E.g., seeing the specific google search terms entered.)
As more of the Web moves to https, decrypting SSL traffic becomes more important to our customers who want visibility into student activity. However, as more providers limit or restrict decryption with their services and devices, this also becomes increasingly challenging. We do and will continue to provide the most powerful filtering solutions across all platforms and offer SSL decryption across platforms, as well as solutions to the issues that can come with it.
The best choice for filtering iOS devices is our Web Filter for iOS app. This uses the latest Apple Filter Provider extensions to examine, filter, and report on network traffic from an iOS device. This requires iOS 9.3 or greater.
The Web Filter for iOS:
- -Filters all TCP traffic for all browsers
- -Offers seamless user identification
- -Works on-site or off-site
- -Works with our Rocket Web Filter or Cloud Filter
iOS Filtering & SSL Decryption
The Web Filter for iOS app provides SSL filtering but does not decrypt SSL traffic. This is a restriction from Apple, not a limitation of our Web Filter for iOS.
If your reason for wanting to decrypt SSL is visibility into search terms, you could redirect google.com to http://www.bing.com or another non-https search site (Google and Yahoo have moved to entirely secure search; at this time, bing still offers unsecure search at http://www.bing.com). This is certainly a temporary fix, as bing is also moving toward encrypted search as well.
iOS Filtering & SSL Decryption with a Proxy
If full decryption SSL traffic for iOS devices is a requirement, that can be accomplished with a trusted man-in-the-middle proxy solution, which Lightspeed Systems provides. It’s a great solution that combines full visibility and reporting with speed and access and it is available across mobile platforms and with either our Rocket Web Filter or Cloud Filter solution. (Learn more about the man-in-the-middle proxy in our SSL, Explained white paper.)
Many customers are able to use an authenticated man-in-the-middle proxy for their iOS and other devices without issue. But some customers encounter authentication issues with iOS devices.
- a. If you’re using GAFE as an authentication source – Google has publicly stated that they do not support GAFE accounts for authenticated proxy.
- b. For other authentication sources, an Apple bug sometimes manifests. This most often manifests as multiple requests to enter credentials (in some cases, every few seconds) – regardless of how or where they are hard-coded in the device; regardless of the MDM in use; and regardless of the filter being used. This issue is an Apple limitation and has been observed on a variety of iOS versions (from iOS 5 through iOS 9.x) and is highly discussed in Apple forums. Sometimes it appears to be fixed with an Apple release, but it manifests in the next iOS release or in the next batch of devices.
At this time, our solution for customers who require SSL decryption and either use GAFE as an authentication source or experience this Apple proxy authentication bug is to create an open proxy (that does not require authentication). This solves the authentication issue, but creates some new ones:
This obviously creates a security weakness on your network, as you’ll have an open proxy running which can be accessed and used maliciously. If you accept these risks as a trade-off of decrypting the iOS SSL traffic, we recommend setting Proxy Security to “Restrict access to iOS and ChromeOS” or “Authenticate external users” rather than “Open Proxy.”
If you choose “Restrict access to iOS and ChromeOS” – this will limit unauthorized access to the proxy, mitigating but not eliminating security issues. In addition, it will not allow you to use that proxy for any Windows devices you have running on your network.
If you choose “Authenticate external users” – this will allow open access to network users, but require external users to authenticate. This will mitigate security issues, but will not eliminate the repeated requests to authenticate, but will limit that to when the device is off the school network.
2. Lack of username in reporting
Allowing access to your Proxy server without authentication gets around GAFE directory restrictions and the Apple bug of repeated requests to authenticate, but obviously it leaves you with unauthenticated users. Whether those are just iOS and Chrome devices or just on-network devices, unauthenticated users by definition do not have a user name tied to them. Therefore, you’ll be able to see specific Google search terms (since it is using the proxy to decrypt that SSL traffic) but you will not be able to see a username associated with that activity on your Web Filter report.
If you’re in a one-to-one environment, you’ll be able to use the reported IP in your Web Filter reports to identify the user based on other district records. If you’re using shared devices, you’d have to combine that information with time/class schedules. And if the devices are off-campus and not authenticated, you’ll see the IP of the home (or other location) where the user is connecting and may not be able to tie that to a specific user.
For enhanced security and visibility, you could couple your open/partially-open proxy with Captive Portal/Web Authentication. The limitation of this is that if you have multiple users in one place, all activity on that external IP will be tied to the first user who web authenticates.
MacOS Mobile Filtering
Mac OS filtering is provided via our Mac mobile filtering agent. Coupled with our Mac User Agent, this provides user identification, filter policy enforcement, and robust reporting whether the device is on or off-network.
MacOS Mobile Filtering & SSL Decryption with a Proxy
If you are using the Mac Filter agent and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL traffic.
Windows Mobile Filtering
Windows device filtering is provided by our Windows Mobile Filter agent.
On Windows devices, you can combine our Windows Mobile Filter agent and our LMA (for user identification) for user identification, filter policy enforcement, and robust reporting whether the device is on or off the network.
Windows Mobile Filtering & SSL Decryption with a Proxy
If you’re using the Windows Mobile Filter and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL.
Chromebook Mobile Filter
Mobile filtering on Chromebook is provided by our Chrome filtering extensions and our chrome user extension for user identification. These extensions are easily deployed through the Google Admin Console, like any other extensions.
We have two filtering extension and which one you use depends on if and how you use SSL certificates:
No SSL certificates → Chrome Mobile Filter Extension
Self-Signed certificates → Chrome Mobile Filter Extension
Certificate Authority (CA) Signed certificates → Chrome S-Mobile Filter Extension
Chromebook Mobile Filtering & SSL Decryption
Both Chrome mobile filter extensions offer SSL decryption without the need for a man-in-the-middle proxy.
Android Mobile Filtering
Android filtering is provided via our Android browser replacement mobile filtering agent. This provides user identification, filter policy enforcement, and robust reporting whether the device is on or off-network.
Android Mobile Filtering & SSL Decryption with a Proxy
If you are using the Android Filter agent and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL traffic.
Linux Mobile Filtering
Linux filtering is provided via our Linux mobile filtering agent. This provides user identification, filter policy enforcement, and robust reporting whether the device is on or off-network.
Linux Mobile Filtering & SSL Decryption with a Proxy
If you are using the Linux Filter agent and require SSL decryption, you can utilize a man-in-the-middle proxy to decrypt SSL traffic.
Where is the Cloud hosted?
Our Cloud Filter is hosted in our datacenter.
Will the Cloud Filter count for my CIPA compliance needs?
Yes, the Cloud Filter will ensure CIPA compliance for all devices on your network (even BYOD/guest devices) and for school-owned devices when they leave your network.
Who can access the Cloud Filter?
Each district is provided a unique URL for their Cloud Filter tier, and only designated district administrators are able to log in to access the filtering controls and reporting data.
Is my data stored separately?
Is the Cloud secure?
Can I use the Cloud for trusted man in the middle proxy and SSL decryption?
Yes. See details below.
So the Cloud Filter is a DNS redirect?
No. DNS filtering is just a part of our Cloud Filter, provided to ensure safety, appropriate use of network resources, and CIPA compliance on guest networks, BYOD devices, or devices that can’t have an agent installed. For most devices, an installed mobile filtering agent will provide more comprehensive and granular policies and reporting than our cloud DNS feature.