A teacher reported that students were using a website called onworks.net, which allows running operating systems like Ubuntu, Fedora, and Windows directly in the browser for free.
Since it’s hosted outside our network, it bypasses filters like Linewize, giving students unrestricted access, including potentially harmful content. How do browser-based virtual machines work, and what strategies exist to control or block such access?
I dealt with students using sites like this before and the fastest wins are:
Block the domain(s)
Add onworks.net (and any mirrors) to your web filter / blocklist. This usually stops casual usage immediately.
Block by category and CDN/IP if needed
If the site uses a CDN or lots of hosts, block the CDN domain or the problematic IP ranges in your firewall. Check dns/whois if you need the ranges.
Disable WebSockets and non-standard ports for student VLANs
Many browser VMs use WebSockets (wss://) or non-HTTP ports for remote display. Blocking or restricting WebSockets on student networks prevents many of these apps from working.
Use an allow‑list for web apps in classrooms
Instead of trying to block every bad site, allow only approved educational sites for student devices during class hours.
Why this order? Domain block + WebSocket restriction usually gives you quick relief before you escalate to heavier measures like SSL inspection (which can be disruptive).
If you strong text want to understand how they bypass filters and how to harden your network:
How browser VMs work
Many browser-based VMs are actually remote desktops in the browser: server runs an OS (VM or container) and streams the display to the browser via WebSockets, WebRTC or an HTML5 VNC client.
The client is pure HTML/JS so it looks like normal HTTPS traffic and often uses wss:// or https:// on port 443 , that’s why superficial filters fail.
Why filters get bypassed
Traffic is encrypted (HTTPS/WSS), so URL paths and payloads are hidden.
They are hosted off‑site (cloud/CDN), so local category filters might not have the site categorized properly.
Some use nested resources and CDNs, dispersing traffic across many domains/IPs.
Stronger technical controls
SSL/TLS Inspection (proxy/NGFW)
Break-and-inspect HTTPS traffic, then block the site based on URL or certificate. Caveat: Requires legal/policy buy-in and client trust of your proxy CA.
Block WebSocket / WebRTC for student networks
Many browser VMs rely on WebSocket/WebRTC. Blocking or selectively allowing these protocols stops them without full TLS inspection.
Block by TLS SNI or certificate attributes
If you can’t inspect full TLS, SNI (server name in TLS handshake) filtering still reveals hostname in many cases (unless ESNI/ECH used).
IP / ASN blocking and rate-limiting
Block known provider ASNs or suspicious IPs; watch for collateral blocking of legitimate content.
CASB / Cloud app control
Use a Cloud Access Security Broker that identifies and blocks risky SaaS/apps even in HTTPS.
I found the most sustainable approach combines tech controls with policy and education:
Enforce device policies (MDM/Endpoint controls)
Use Mobile Device Management on school devices to prevent installation of alternative browsers or to disable developer tools and proxy bypasses.
Strict school policy + communication
Make rules clear: running external VMs or bypass tools is prohibited. Couple policy with consequences and repeat reminders to students and staff.
Teacher controls & classroom mode
Use classroom management tools (Chromebook/Apple/Windows classroom features) so teachers can limit web access during class.
Monitoring & alerting
Set alerts for unusual HTTPS connections, long-lived WebSocket sessions, or spikes in traffic to unknown domains — this catches new services quickly.
Educate students
Teach why filters exist (safety, copyright, bandwidth). Sometimes students stop using these tools once they understand the risks and consequences.