Inline IPS to block students from using VPN in educational subnet

[swmspam]

I have a group of middle-schoolers using a subnet for educational purposes. These kids use VPN or Virtual LAN software (Logmein Hamachi, GameRanger, Windscribe, ZeroTier) to play games, discord, reddit, and other tomfoolery during class. Some bring their own laptops so the software tools are already installed. They are obviously not supposed to circumvent the school's firewall but they do. Electronic prevention is a more realistic solution than manually policing of each laptop or just letting it go. I would like to put up at least a marginal firewall in good faith.

I setup a transparent bridge pfsense with Snort and pfblockerNG and started looking for blocklists or rulesets that specifically target VPN. In my estimation, VPNs can be stopped three ways:

1. Block specific ports used by orthodox protocols: 500, 1701, 4500, 1723, etc.
2. Blocking the IP address of the Hamachi management service that coordinates the tunnels, or
3. DPI rules to identify the protocol fingerprint and trigger an alert/block

For number (2) and (3) does there exist IPS rules or IP blocklists that achieve either of these goals? FireHol Anonymizer and FireHol Proxy don't work. I have both running on pfblockerNG . Several VPNs that I've tried works without triggering an alert so they obviously don't target established services like Hamachi.

[swmspam]

Under Snort OPENAPPI Rules, there is ruleset openappid-vpn_tunneling.rules. Under the Snort/LAN Preprocs, enable the Application ID Detection. There are several VPN protocols in the ruleset. This takes care of number (3) in the strategy list in the OP thread.

Looking at the OP list:

1. Block specific ports used by orthodox protocols: 500, 1701, 4500, 1723, etc. DONE
2. IP blocklist of the management services that coordinate Virtual LAN tunnels and VPN service providers
3. DPI rules to identify the protocol fingerprint and trigger an alert/block DONE

Last thing remains: pfblockerNG IP blocklist of VPN entry or exit points and tunneling servers for Virtual LAN providers.

[swmspam]

Furthermore, VPN services like Windscribe tunnel through port 443 to masquerade as HTTPS traffic. Therefore, the proper way to firewall services like Windscribe are numbers (2) blocklist the Windscribe service IP addresses or (3) DPI rules to distinguish VPN traffic from normal HTTPS traffic. The Snort VPN rules, although they contain Hamachi Virtual LAN, do not contain whatever protocol that Windscribe (and others) use.

[bmeeks]

You can obtain packet captures of the VPN traffic and then write your own OpenAppID rules to detect it. You should be able to learn what you need to do via Google searches and by using some of the existing VPN detection rules as a starting point.

And no, I don't know the exact rule you need to detect this or if it is possible given they use ports such as 443. This means the VPN client creators purposefully created a client that is difficult/hard to detect.

Why not install some of the same client software on a machine you own and use packet captures to see what IP addresses it favors and what the protocols look like? That would give you insight to write your own detection rules.

[swmspam]

bmeeks, I agree that writing some new rules for purposefully sneaky VPN clients would be useful to the community at large, especially for administrators struggling with middle schoolers and educational subnets. I'm starting by reading up on forum posts of detecting OpenVPN using Snort (including posts on this forum). It doesn't look very promising because OpenVPN can wrap itself in HTTPS or other legitimate protocols.

[bmeeks]

@swmspam said in Inline IPS to block students from using VPN in educational subnet:

bmeeks, I agree that writing some new rules for purposefully sneaky VPN clients would be useful to the community at large, especially for administrators struggling with middle schoolers and educational subnets. I'm starting by reading up on forum posts of detecting OpenVPN using Snort (including posts on this forum). It doesn't look very promising because OpenVPN can wrap itself in HTTPS or other legitimate protocols.

This is why I seldom favor or recommend using technical solutions to police what is fundamentally a problem of discipline and personal responsibility when it comes to Internet usage policy. As you see with this VPN client, the technical challenges are tough if you depend solely on technically preventing the software from functioning. On the disciplinary side, though, you generally only have to cut off one person's head in order to get the full attention of the rest of the crowd --- LOL. Okay, just a little bit of hyperbole there, and I'm certainly not suggesting cutting off the head of a middle schooler; but some strong disciplinary action on a few can many times convince the remainder that it's not worth taking a chance participating with the banned activity.