Interesting read! A couple of days ago I setup a Cloudflare’s access with argotunnels and a CA. A very cool beyondcorp service which looks similar to okta.
Remote access to production infrastructure (death to the VPN)
11–20 of 120 posts
Re: Remote access to production infrastructure (death to the VPN)
#12This 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.
Re: Remote access to production infrastructure (death to the VPN)
#13> 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?
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.
Re: Remote access to production infrastructure (death to the VPN)
#14> 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?
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.
Re: Remote access to production infrastructure (death to the VPN)
#15Agree 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.
Re: Remote access to production infrastructure (death to the VPN)
#16Any 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.
Re: Remote access to production infrastructure (death to the VPN)
#17Earlier 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.
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.
Re: Remote access to production infrastructure (death to the VPN)
#18Earlier 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.
Most people in industry I have talked to just do VPN for all traffic, even though that seems crazy to me to route your Hacker News traffic through your prod servers' networks (gross). Normally a compensating control would be appropriate, but if you are pursuing FedRAMP Moderate ATO like we did, you can only get away with a pretty small number of alternative implementations, and only Low findings can be easily accepted by the Federal stakeholders. It's tough.
Re: Remote access to production infrastructure (death to the VPN)
#19Pure 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 knocking is a bad idea (TCP/UDP ports are sent in the clear and the "key" is never rotated)))
The best model is probably "block everything" by default, then allow access to the inner courtyard via a VPN, where then the Zero Trust model is deployed. You remove the ability for an attacker to have unlimited retries, but access to resources still requires individual authentication.
Re: Remote access to production infrastructure (death to the VPN)
#20Pure 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…
Why does pure zero trust give unlimited retries? If you use rate limiting, good password policy, and strong 2FA then most motivated attackers are going to seek a different entrance.