Live data from Hacker News

Remote access to production infrastructure (death to the VPN)

mattslifebytes.com

41–50 of 120 posts

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

#41
Authenticating the source IP address on the fly (as detected from the browser) is definitely not the way to go for many reasons:

1. With NAT and metropolitan area networks, hundreds of thousands of devices could share the same public IP.

2. Large networks with many devices often connect to the public network through trunking (load balance the connections through multiple routers), so the HTTP connection between OKTA and my browser can VERY well originate from a different IP address than my SSH session, and I would never be able to connect.

3. Many devices are mobile, and they can change their IP address when they pass from WiFi to LTE for example. This would force an unnecessary re-auth.

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

#42

Authenticating the source IP address on the fly (as detected from the browser) is definitely not the way to go for many reasons: 1. With NAT and metropolitan area networks, hundreds of thousands of devices could share the same public IP. 2. Large networks with many devices often connect to the public network through trunking (load balance the connections through multiple routers), so the HTTP connection between OKTA…

I want to be clear about the use case that the enterprise port knocking solution is trying to solve: it's an additional control that would not normally even be in place. In most setups, you are exposing some sort of relay to the internet, through which your users can access the services after authentication - such as an SSH bastion host or a VPN. The IP based whitelisting mechanism is simply a layer to allow you to not have to compromise and expose anything to the world wide internet. The actual authentication and authorization mechanism is the certificate-based set of SSH connections.

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

#43

This doesn't make any sense. The people that make Okta ASA (formerly ScaleFT) -- Okta themselves -- must VPN into production. I wouldn't use ASA or the like without VPN if the people that make it won't even do that. Besides... it's an extra layer of security. Don't have the requisite certificate, username-password combo, and additional factor? Then you can't even get to port 22 to start with.

How do you know they don’t use it for production?

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

#44

Earlier quoted context omitted.

> 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. 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 stuff from outside the office all the time.

(FWIW, I don't think there's anything secret here. This stuff is very explicitly described in the whitepapers.)

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

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

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

#46

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.

I love Pritunl. Have been using it for 5 years. It's super easy to setup, maybe takes an hour the first time and like 15 minutes once you have done it.

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

#48
post #21

Earlier quoted context omitted.

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…

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

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

#49

Authenticating the source IP address on the fly (as detected from the browser) is definitely not the way to go for many reasons: 1. With NAT and metropolitan area networks, hundreds of thousands of devices could share the same public IP. 2. Large networks with many devices often connect to the public network through trunking (load balance the connections through multiple routers), so the HTTP connection between OKTA…

NAT and single IP adresses for multiple users are going away with IPv6 ?
Post reply on HN