Hacker News Reader

Comment by nurettin | Hacker News Reader

> One of my biggest pet peeves about VPNs is that they hijack all your network traffic. They can be configured not to, but our customers and security controls like NIST 800-53 SC-7(7) typically require that they do.

VPN is dead because some customers want you to route the internet interfaces of all machines through the VPN server.

How does this even make any sense?

View on HN

Hijacking all your network traffic is one of the reasons for corps to use a VPN in the first place. It allows any and all outgoing requests to be routed through corporate security policies while you have access to the VPN and cuts down on the possibly of cross site scripting attacks.

Split tunneling is the answer here. Many folks configure their VPN solutions that way. That's exactly what I do at my present employer... traffic meant for VPN goes over VPN, and everything else gets routed through the client's internet connection.

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.

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.

> 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.

As I alluded to in the post, it's a legacy viewpoint. These customers hand you a 300+ security questionnaire that hasn't been updated in 10 years. When you tick the 'VPN' boxes, alarms sound, but they are thinking about the term 'VPN' in a different context, like employees accessing a network file share. But what we really have is a Bastion host (aka jump box), which is fundamentally different. By not saying you run VPN software, the conversations shift significantly, especially when dealing with the F100 banks and the like that may not be as familiar with modern cloud architectures.

Because split tunnel is a pain in the ass.

More specifically it's a pain in the ass if you use AWS ALB load balancers and whitelisting. Those IPs aren't consistent and you typically can ONLY route on IP.

We do it because it's better than the alternatives, but our setup wouldn't scale past more than a few applications.

This is only the default. You can set up your VPN however you want including only routing certain subsets down the tunnel.

Reply on news.ycombinator.com