Live data from Hacker News

Remote access to production infrastructure (death to the VPN)

mattslifebytes.com

21–30 of 120 posts

Re: Remote access to production infrastructure (death to the VPN)

#21

Earlier quoted context omitted.

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.

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.

Re: Remote access to production infrastructure (death to the VPN)

#22

Earlier quoted context omitted.

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.

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.

Re: Remote access to production infrastructure (death to the VPN)

#23
In my experience, the best way to eliminate the VPN is to expose your various internal business services as websites w/ TLS1.2 & multi-factor authentication.

Obviously, this isn't practical for everything. But, if the thing you were using VPN for is already a web application, you are basically halfway there. Ideally, you just directly expose a secure web application to clients, but in some cases (i.e. very old legacy systems) you probably want to put an nginx box in front and then put the authentication at that level.

Web access has a huge range of benefits. Users are scoped directly to the system of concern rather than an entire network of hosts. You can take security to the next level with server-side rendering of web content in order to avoid additional required channels of communication or revealing of implementation secrets to the client (e.g. SPA client source).

We are at a point of placing our actual application servers directly on the public internet (with TLS1.2/MFA/ACLs/etc). Hiding behind VPNs or layers of reverse proxies seems to cause more harm than good.

Re: Remote access to production infrastructure (death to the VPN)

#24
This is an apples to orange comparison. Most network admins are lazy and just provide full L3 access so they don't have deal with any access issues. Most users use VPNs as an access mechanism rather than to secure anything. Most vendors you mentioned in the article can also control access at application level like ssh.

Re: Remote access to production infrastructure (death to the VPN)

#25

Pure Zero Trust is just as ridiculous as using Pure-VPN-around-a-garden. The first gives an attacker unlimited retries, and the second gives an attacker full system access once they breach the outer wall. The correct solution is somewhere in the middle: block everything by default to get you to an inner courtyard, where the zero trust model is deployed... (which ironically he suggests by deploying port knocking (port…

He doesn't ACTUALLY suggest port knocking, just the concept ("do something in order to open a firewall hole"). The proposed solution using Lambda w/ 2FA is actually pretty cool.

Re: Remote access to production infrastructure (death to the VPN)

#26
post #6

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

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.

Re: Remote access to production infrastructure (death to the VPN)

#27
post #23

In my experience, the best way to eliminate the VPN is to expose your various internal business services as websites w/ TLS1.2 & multi-factor authentication. Obviously, this isn't practical for everything. But, if the thing you were using VPN for is already a web application, you are basically halfway there. Ideally, you just directly expose a secure web application to clients, but in some cases (i.e. very old legacy…

> Obviously, this isn't practical for everything

If you have the engineering resources to back it up, it definitely can be. Internal services at Google usually trust the office network the same as any other -- well documented in the BeyondCorp paper if you're interested.

Re: Remote access to production infrastructure (death to the VPN)

#28
Pardon my ignorance, so this updates a security group (or multiple) which presumably have access to several internal things? One wonders if you can take it a step further and for web-based services (i.e. doesn't apply to SSH access), at the conclusion of the authentication, it updates the security group for just that webapp. With how e.g. oauth2 SSO automatically auths via redirects, if the update to the security group is atomic/fast, access can be given one webapp a time.

Also, are there any concerns about IP timeout vs explicit VPN disconnect? Obviously the latter works better in shared environments (e.g. shared terminals, wifi's that reuse IPs frequently, large NATs that have many devices behind a single IP).

Re: Remote access to production infrastructure (death to the VPN)

#29
post #23

In my experience, the best way to eliminate the VPN is to expose your various internal business services as websites w/ TLS1.2 & multi-factor authentication. Obviously, this isn't practical for everything. But, if the thing you were using VPN for is already a web application, you are basically halfway there. Ideally, you just directly expose a secure web application to clients, but in some cases (i.e. very old legacy…

> Obviously, this isn't practical for everything If you have the engineering resources to back it up, it definitely can be. Internal services at Google usually trust the office network the same as any other -- well documented in the BeyondCorp paper if you're interested.

My understanding based on the folks I know at Google is that BeyondCorp paper was a PoC that was implemented in part of their corp network, that is called Production, not to be confused with the production network that hosts their search site. That network still requires a VPN and a hardened Linux laptop to access. Not every service has been modified to implement the RPC calls / authenticated protobuf code changes.

Someone at Google please feel free to correct me on this.

Re: Remote access to production infrastructure (death to the VPN)

#30
post #6

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

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.

Post reply on HN