Live data from Hacker News

Remote access to production infrastructure (death to the VPN)

mattslifebytes.com

91–100 of 120 posts

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

#91

Earlier quoted context omitted.

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

BeyondCorp is not just a proof of concept. Everything at Google is accessed through it, including production-production (through a proxy maybe? Not sure the details). You're right about the requirement to have a hardened device -- which acts sort of like a token (as described in the BeyondCorp whitepapers). But it can be Windows, Linux, Mac, Chromebook, Android or iPhone. I never use VPN and I work on production stuf…

As I understood the paper, their production version is called überproxy and has access to everything they host, as they moved their applications all on to it (notably, this means SSH now has to go through chrome).

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

#92
post #88
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…

Why wouldn't it be even more secure with a VPN in front of it? Is defense in depth no longer a good strategy?

Thos doesn't pan out in practice. One the VPN is there, people get lazu & complacent about implementing strong security inside.

Defense in depth is a concept that should be applied with some thought, it would be good if your additional layer did something different. For example good reactive security, endpoint attestation, etc.

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

#93

Earlier quoted context omitted.

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.

Correct, but his solution is a hair improvement at best over port knocking. A VPN means an individual connection is authorized into the interior courtyard. A Lambda with 2FA to whitelist an IP, then a cron job to cleanup means everyone at your local cafe wireless access point is also authorized into the inner courtyard.

No, the IP whitelist is only to allow access to the network entry point. So if you had a VPN, it would open the port to the VPN server. In our case, it opens the port to the cordoned-off SSH-based network entry point. It's not the replacement of an existing authorization layer; its an addition where one usually isn't found.

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

#94
post #69

I work in this space who has a commercial offering. Ill just leave this CSA spec here for reference. Please also look up SPA - newer than port knocking, but based on same premise. https://downloads.cloudsecurityalliance.org/initiatives/sdp/...

This talks about air-gapped networks?

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

#95
In 99.95% of cases, VPNs are set up to:

Bridge a network device – such as a laptop or even another server … into a larger network of servers – such as in the cloud or on-prem … across the Internet – protected with an additional layer of encryption

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

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

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

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

#97
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…

I want this, but with a twist. 1) I want the websites to do certificate verification on the certs I'm using on my desktop. 2) Then on top of that my website should use usb security key verification as well. Easy enough to do #2, but I want #1 to be ubiquitous as well. ... So basically my HTTPS server will use my public key as my identity, not my username/email and password.

The Duo Network Gateway can do this with Trusted Endpoint certificates.

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

#98
If you're in GCP, then you can use their Identity Aware Proxy to achieve most of this. (https://cloud.google.com/iap/docs)

IAP supports HTTP and TCP connections, so you can put it in front of your website (say an internal admin webapp), or use it to tunnel SSH onto a machine that doesn't have a public IP, using your IAM roles.

If you're running Kubernetes in GKE, you can also wire IAP up to an Ingress, to protect any TCP/HTTP services you have in your k8s cluster. This one is a bit tricky to configure, but is very nice once you have it up and running.

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

#99
post #54

Earlier quoted context omitted.

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

With BeyondCorp, the production network you access does host all of the critical jobs including search. But of course you only get to manipulate these jobs in an approved way, e.g. using an RPC to bring up or bring down a job. Interacting with jobs by sending them RPCs requires ACLs naturally. You don't get direct SSH access to production machines or any other lower level network access like packet sniffing on the pr…

A key reason why BeyondCorp actually works is hardly anybody needs to SSH to prod, and people who do need it, need it rarely. Everything at Google has rich RPC control surfaces and the tools are installed on users' workstations to invoke the RPCs. Status of everything is available via HTTP, in your browser. No need to SSH to a server to read logs or restart a process. Need to collect hardware PMU counters in prod? There's an RPC service for that. Not only do these rich interfaces enable BeyondCorp, they also cut down on insider risk because it's no longer considered "normal" to get an interactive shell session in production.

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

#100

TLDR: Use a complicated SSH proxy instead of a VPN. This has some serious downsides for non-SSH applications. For example, to connect to a production database cluster, one would need to ssh through the proxy to a bastion host, and then set up port forwarding from the bastion host to the database. Setting up a simple database connection now requires shell access to a production server. This is less secure and more com…

A great point. It does depend on your use case, and your dependence on manual operations. For our organization, almost all database interactions and maintenance are performed in code; if somebody is connecting manually, something pretty bad has happened. So for us, we are not really impacted by having to perform port forwarding like this on rare occasion. I completely agree that it could be much more impactful to oth…

Good VPNs are mutually authenticated. Intentionality is good, but in your example it comes at a cost of complexity. Simplicity is paramount for security.

If intentionality is desired, one can use per-server VPNs.

Post reply on HN