Hacker News Reader

Comment by sullivanmatt | Hacker News Reader

The control I listed, NIST 800-53 SC-7(7) [which is a part of the FedRAMP Moderate suite of controls], specifically requires you implement a technical control such that your users cannot split tunnel.

View on HN

> requires you implement a technical control such that your users cannot split tunnel

Is it actually possible to have a technical control like this?

Why can't I create a container or virtual machine that just runs a VPN client, and then use the virtual machine network controls to decide what host traffic gets routed to the VM and through the tunnel? How would the VPN client running inside the VM know about anything I'm doing one level up?

Or is this just another bullshit "you don't actually control the software running on your machine" technical control?

The common assumption is that the company-issued VPN client will only ever be installed on hardware owned and controlled by the company, and never inside a VM.

Realistically, the usual plan is to create controls that are impossible for most non-technical users to bypass, inconvenient for anyone else to bypass, and back them up with the threat of disciplinary action.

I think this is why VPNs have such a poor reputation among the tehnically literate. We're used to security where every aspect is goverened by strong cryptography that's difficult for state actors to break (e.g. SSH, TLS).

There may be real cryptography over the wire, but there's nothing "strong" about the assumption you mentioned, or the disceplenary threats. If the threat model assumes that I can't extract a key from a laptop, or clone the behavior of some garbage Cisco client, that seems pretty broken to me.

Commercial VPNs are mostly just shitty software for enforcing shitty corporate policy, disguised as a remote access tool.

Apologies... didn't read into the NIST requirement. Out of curiosity, what do you normally implement that meets that requirement? Forcing all traffic when there is no security benefit (what is the advantage of getting to https://news.ycombinator.com through the VPN?) seems ripe for a compensating control.

Most people in industry I have talked to just do VPN for all traffic, even though that seems crazy to me to route your Hacker News traffic through your prod servers' networks (gross). Normally a compensating control would be appropriate, but if you are pursuing FedRAMP Moderate ATO like we did, you can only get away with a pretty small number of alternative implementations, and only Low findings can be easily accepted by the Federal stakeholders. It's tough.

It could have to deal with monitoring what is coming and going from the VPN'ed machine. If malware can escape the VPN tunnel, it is less likely to be detected than if it is forced to go through a firewall that is already looking for suspicious traffic. Rather than let a user pick and choose what goes through the VPN and possibly letting the malware make the decision for them, don't let them choose at all. I've worked at places that force you to use the VPN if you aren't connected to the office network. Security of the VPN client aside, it's not a bad idea to force any remote machine to be totally protected from the raw internet.

If the malware (or the user) has root it can hairpin tunnel anything it wants out the default gateway by manipulating the routing tables. It may not even require root but I'd have to tinker with it which I'm too lazy to do.

Split tunnel vs not split tunnel means nothing if the client doesn't want it to mean something.

The rule of thumb is if you must vpn then you have a controlled system where root is limited. Think bank or government systems

If the business prioritizes security, getting to https://news.ycombinator.com would not be possible. If you want to get to https://news.ycombinator.com you use a separate PC.

The PC you use with the VPN is never to be directly connected to the internet. It connects to a piece of dedicated VPN hardware. (could be a Raspberry PI with special software or something far more expensive) That PC can use the VPN, and thus get to various computers within the company, but it can't go elsewhere. No other business is reachable.

The company can allocate IP addresses without NAT and without regard for the rest of the world. There just isn't any connection to the rest of the world, so conflicts can't happen.

If this is for complying with NIST 800-53 SC-7, then I'd be really curious how this actually works. Because SC-7 is all wrapped up in language around split tunneling I feel like this is focused on the wrong thing -- you'd still need to accommodate for controlling access of laptops etc. to external resources. Yes, in a VPN landscape that means not allowing for side-stepping the VPN, but that would be true of any other means of protection. It's clearly talking about having outbound connections controlled & secured at all times, not just your connections to internal trusted resources.

The risk of split tunneling is that the remote client has the ability to relay data in real time. Allowing it means the local printers or laptops on an open WiFi are effectively on your network.

Reply on news.ycombinator.com