Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote access to production infrastructure (death to the VPN)

mattslifebytes.com

Post reply on HN
Print view View original

71–80 of 120 posts

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

#71

Post by sullivanmatt »

bb611 wrote: post #67
cordite wrote: post #62

I'm surprised to see no mention of Mutual TLS (MTLS), PIV cards, or the like

I believe in this case he's talking about MTLS: > OASA also protects these hops by issuing client certificates with 10-minute expirations after first verifying your identity through our single sign-on provider, and then also verifying you are on a pre-enrolled (and approved) trusted company device.

Basically. Since we are focusing on SSH in this post (and keep in mind that SSH is its own protocol, separate from TLS), it's conceptually the same: client has a certificate and a key, signed by a trusted certificate authority, and the client is also in possession of the server certificate authority. So then you have a bi-directional trust established. The certificates are short-lived, and issued after a successful authentication + dial request to the OASA service.

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

#72

Post by sullivanmatt »

BlueTemplar wrote: post #50

Hmm, static IP suffixes are a thing of the past anyway with IPv6 ? "Tens of millions" ? More like quintillions, and that's for a single IP prefix more typical of a home connection !

Sorry, the tens of millions of IP addresses is referencing the IP space of AWS (one of which these network access points occupies at any given point in time).

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

#73

Post by AYBABTME »

unexaminedlife wrote: post #68
bob1029 wrote: 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.

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

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

#74

Post by sk5t »

jschwartzi wrote: post #37
fulafel wrote: post #5

The critique against VPNs is exactly right, they're such garbage compared to the standard we otherwise hold SSH, TLS etc to, and the access granularity is too wide, and there's no transparency on how wide the access is configured from VPNs. And they're very often on the wrong side of the it dept vs devops responsibility split so often misconfigured.

The biggest issue I have with replacing VPNs is in server management, but not the way the author is talking. My job entails doing software development for over 1000 devices that are all fielded behind enterprise firewalls, and the PCI compliance requirements dictate that no unnecessary access be provided into those firewalls. What this means in practice is that no connections may be established which originate from a…

Does a VPN afford your customers belief in the fiction that the source device is no longer on the internet?

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

#75

Post by unexaminedlife »

AYBABTME wrote: post #73
unexaminedlife wrote: post #68

Earlier quoted context omitted.

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.

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 layer on server-side so I can manage that as needed.

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

#76

Post by icedchai »

forkexec wrote: post #56
jjoonathan wrote: post #55

Earlier quoted context omitted.

So, they have drawn their lines of defense in a position you are not used to, and therefore they are beyond idiotic and regressive? Really?

Yeap. There is a night and day difference in attack surfaces between isolating access to a single (or HA pair) jumpbox and N boxes on the internet with no real DMZ or private admin network. Feelings and fashions don't make stupid configurations better. If you have a problem with honest opinions from someone with 25 years of experience, I think you need thicker skin or I can choose to simply not comment and let stupid…

Yep. Putting everything directly on the public Internet is 90's style. I remember it well. Whole offices with public IP addresses. No firewall. It's amazing anyone ever considered this sane, but it was a different time.

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

#77

Post by throwdbaaway »

exabrial wrote: post #19

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.

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

#78

Post by ViViDboarder »

unexaminedlife wrote: post #75
AYBABTME wrote: post #73

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 don’t implement it at the Application level. You implement mutual TLS on your proxy and then each application can keep its own auth.

Disclaimer: I haven’t don’t this myself (yet), but have read about it a bit.

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

#79

Post by the8472 »

unexaminedlife wrote: post #75
AYBABTME wrote: post #73

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…

nginx can do the client cert verification for you and pass the results as http headers to the application. so all you have to do in the application is to add some request authentication interceptor that inspects the headers.

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

#80

Post by breput »

sullivanmatt wrote: post #60
johnmarcus wrote: post #45

Meh, this sounds like it's paid for by okta. It also doesn't cover the real use case scenario of vpns - non-technical folks need to access internal services. What's presented is a reasonable approach for ssh control. Oh, and I'm pretty sure Cloud Passage has a port-knocking based solution in the real world which also gives 2fa access for ssh.

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 obtaining access to the authenticator device. Once your machine is enrolled in ScaleFT and while you're authenticated with your identity provider, malware or just a malicious coworker could access the production services with a single command line.

There are upsides to ScaleFT as well, though. As long as you're all in on Okta or can federate with it, user management is a no brainer. And having the IdP integration is much more user (and malware) friendly and is likely more reliable for server to server use compared to OpenVPN. Limiting access to particular services is likely easier, too.

Downsides with this product include having all sorts of reoccuring configuration problems where a server just disappears from the list of available services, which requires ops involement to restore access. If you're using macOS and RDP (I just outed myself to Matt...) you have to use the sub-par FreeRDP client. And ultimately you're tunnelling TCP over TCP, which works ok in the office but which might not always work as well in mobile or higher latency network situations.

Post reply on HN