Live data from Hacker News

Remote access to production infrastructure (death to the VPN)

mattslifebytes.com

81–90 of 120 posts

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

#81

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…

Also just to note there is nothing to stop you from using a rotating port knock key, particularly if you are willing to assume the client's clock is reasonably accurate.

Yes, but not nearly as impossible as it should be. The amount of precision to pull of a timing attack is difficult, but the amount of computing power to refactor 4098bit RSA keys requires computers that don't exist [yet].

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

#82

Earlier quoted context omitted.

you can do that with mutual TLS (client side authentication)

Thanks for pointing that out. I definitely get that it's possible, but as far as I know in the open source world there isn't much in terms of infrastructure to implement these types of solutions in web applications. Happy to be proven wrong, I'm just unaware if any popular open source HTTPS servers offer this as an integrated solution. Or better yet, I'd like raw access to the certificate info FROM the application la…

You can use openresty and use lua to create a whitelist of certs. Example: https://gist.github.com/phamhongviet/71da4b02bb517000593cf49...

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

#83

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.

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

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

#84

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…

I used to think the same way as the author, i.e. if there is already a secured SSH bastion host and IAP-protected internal services, why do we still need VPN? The answer is of course defense in depth. I wonder why the author seems to reply to every comments other than this.

Not to be particularly combative to this top-level comment author, but I did not see a reason to reply because I did not feel they had read the post particularly closely.

Obviously defense in depth can go as deep or shallow as you see fit, given an organization's resources. We believe that the short-lived SSH certificates, IP whitelisting (via "enterprise port knocking"), endpoint authentication (device trust), password authentication, and multifactor authentication are enough to protect a single production deployment. Encompassing all of that with a VPN seemed unnecessary when other protection mechanisms like the above, and additional mechanisms that we won't speak to publicly, are taken into account.

Like with anything, it's a game of risk, and it is up to each organization to decide what risk level they will tolerate. I believe most organizations have deployed VPNs in a way that gives them a higher exposure, and simply wanted to share some of the things we have learned through the process :)

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

#85

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.

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.

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

#86

No, no, no. The whole point of a VPN or SSH jumpbox is to airgap critical infrastructure with unknown vulnerabilities behind a hardened point of access. Putting production infrastructure on the public internet is beyond idiotic and regressive, and an invitation to be hacked by an unlimited and unknown number of exploits. It took forever to get departmental firewalls at a big name university where I worked because sys…

Many of our customers use SSH jumpboxes - its a natively supported feature of Okta Advanced Server Access / ScaleFT.

From a post awhile back about using Bastions with ScaleFT:

> One of our values at ScaleFT is to do our best to support our users where they are, with the decisions and tools they’ve already selected. This means treating SSH bastions as an SSH feature, parameterizing and centralizing the associated configurations, and seamlessly integrating it into our users’ daily workflows.

https://www.scaleft.com/blog/bastion-hopping-with-ssh-and-sc...

So, if you want to layer on top VPNs, or SSH Jump Boxes, we try to let you. We also try to make parts of the chain better whenever we can.

(disclaimer, I'm ScaleFT co-founder)

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

#87
post #80

Earlier quoted context omitted.

I have no way to prove to you that I am not some paid shill :) , but I have no relationship with Okta outside of being a customer through my employer, and I was not compensated or gifted anything for the creation of my post. I blog about things that I encounter at work and find interesting. That happens to often be a cross-section of infrastructure and identity!

I can verify that he isn't an Okta shill but he also glosses over some of the problems and limitations that I've experienced with the ScaleFT product compared to our co-existing OpenVPN solution. We have used multiple OpenVPN servers with password protected cerificates and TOTP. Even if someone were to obtain access to my credentials and certs, they wouldn't be able to access the production services without also obta…

Yes, the RDP story is very painful.

To the best of my ability, my goal was to make the post more about the network architecture (esp around the concept of SSH bastions) and less about the actual OASA product itself. I think there are a number of fungible solutions which would be just as effective (though I think the integration with Okta is a key product feature). What I find interesting and novel is more what we can do to only open ports to authenticated IP addresses, and to address connections between a single source and a single destination. To me, that's where the real power lies.

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

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

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

#89

Any suggestions for a good inexpensive or open source zero trust auth solution that supports both HTTP and SSH? I considered Cloudflare Access, but you need to pay extra for Argo Tunnel if you want it to work with SSH. The main open source option I'm aware of now with support is Pritunl Zero. Was going to actually stand that up today before I read the article.

Not sure if you need SSO (it doesn't do it), but if you can bootstrap with a cert or key of some kind, I've been loving Zerotier.

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

#90
post #10

Agree on VPNs. They need to die. Let elect ZeroTier to be the president of remote, secure access :)

Nebula is very nice too, licensed MIT and has DNS support, something ZeroTier still hasn’t added outside of the ztdns server that someone wrote that I never did get to work properly... hopefully ZeroTier makes some strides in 2.0.

Oh my god, thank you for mentioning this project. I just deployed ZeroTier for some local infra, but in doing investigation, I was desparately trying to find the Nebula project name and GitHub. I was looking for "beacon", "lighthouse", "bastion", "ZeroTier compete" and everything in between. I even knew it created at some prominent tech company (kept thinking Netflix, of course it was Slack). I was starting to think that I'd concocted a false memory and it didn't really exist.

So now I gotta go decide if I want to rip out all my existing ZT infra or not.

Post reply on HN