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

101–110 of 120 posts

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

#101

Post by burfog »

whatthesmack wrote: post #17
sullivanmatt wrote: post #14

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

If the business prioritizes security, getting to https://news.ycombinator.com would not be possible. If you want to get to https://news.ycombinator.com you use a separate PC.

The PC you use with the VPN is never to be directly connected to the internet. It connects to a piece of dedicated VPN hardware. (could be a Raspberry PI with special software or something far more expensive) That PC can use the VPN, and thus get to various computers within the company, but it can't go elsewhere. No other business is reachable.

The company can allocate IP addresses without NAT and without regard for the rest of the world. There just isn't any connection to the rest of the world, so conflicts can't happen.

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

#102

Post by wtracy »

ohazi wrote: post #83
sullivanmatt wrote: post #14

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

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

The common assumption is that the company-issued VPN client will only ever be installed on hardware owned and controlled by the company, and never inside a VM.

Realistically, the usual plan is to create controls that are impossible for most non-technical users to bypass, inconvenient for anyone else to bypass, and back them up with the threat of disciplinary action.

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

#103

Post by znpy »

I've recently started using socks proxies via ssh and I was surprised about how far you can go with such solution.

Unless you want permanent connection with routing and everything, ssh socks proxy work awesomely.

Point a firefox profile to use it and you can really act as if you were in a different subnet: it can proxy dns resolution too.

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

#104

Post by jeroenhd »

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…

As for handling the TLS part, both Apache and NGINX have the capability to do verification of certificates. The application only needs to parse the headers they pass on to determine the user connecting to the application.

If you don't care about the user (TLS client certs + standard username/password) you can get away with proxying the application through nginx and calling it a day.

Basically you turn on client verification and you're done. If you want to show an error to unauthenticated users, you can make verification optional and add something along the lines of: if ($ssl_client_verify != SUCCESS) { return 403; }

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

#105

Post by jeroenhd »

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…

Why limit yourself to TLS 1.2? What's wrong with TLS 1.3?

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

#106

Post by SturgeonsLaw »

icedchai wrote: post #76
forkexec wrote: post #56

Earlier quoted context omitted.

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.

Better bust out the JNCO jeans and Offspring CDs because IPv6 is on it's way and you can bet some deployments will have everything accessible to everything.

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

#107

Post by ohazi »

wtracy wrote: post #102
ohazi wrote: post #83

Earlier quoted context omitted.

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

The common assumption is that the company-issued VPN client will only ever be installed on hardware owned and controlled by the company, and never inside a VM. Realistically, the usual plan is to create controls that are impossible for most non-technical users to bypass, inconvenient for anyone else to bypass, and back them up with the threat of disciplinary action.

I think this is why VPNs have such a poor reputation among the tehnically literate. We're used to security where every aspect is goverened by strong cryptography that's difficult for state actors to break (e.g. SSH, TLS).

There may be real cryptography over the wire, but there's nothing "strong" about the assumption you mentioned, or the disceplenary threats. If the threat model assumes that I can't extract a key from a laptop, or clone the behavior of some garbage Cisco client, that seems pretty broken to me.

Commercial VPNs are mostly just shitty software for enforcing shitty corporate policy, disguised as a remote access tool.

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

#108

Post by bluecmd »

jedieaston wrote: post #91
asdfasgasdgasdg wrote: post #44

Earlier quoted context omitted.

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

BeyondCorp is the effort/program name, ÜP is one of the software that enables it to be implemented. ÜP is just a fancy Envoy/nginx reverse proxy.

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

#109

Post by bluecmd »

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…

There are a few. https://github.com/tink-ab/login-service is one I wrote and open sourced when I worked at the associated company. Adding something like https://github.com/dhtech/authservice + https://github.com/dhtech/prodaccess would give you client certificate provisioning and handling.

In the end you'd easily get e.g. daily U2F with monthly cert rotation. Or whatever you end up wanting.

Open source have had this convered for years, but you'll have to look for it.

Disclosure: I'm the main author of all those three projects.

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

#110

Post by peterwwillis »

Mainly this is a poor idea because of the whole allowing-an-IP-thing. Do not rely on IPs or ports for security, ever. Ever. Evereverevereverever. They are not secure. They do not contribute to security. Do not make your security dependent on them. Ever. Ok? Thanks.

AWS already has a vastly superior solution for this, called AWS Systems Manager Session Manager (it's quite a mouthful). You create a session with AWS using a federated login service (SAML-based SSO) and then craft IAM policies to allow a single user to ssh into a single server, over the AWS API. Not only will this be more secure, you don't have to maintain a wacky custom solution.

Logging into servers is an anti-pattern, and wherever possible you should be running away from it. Get metrics out of the server and analyze them, run commands remotely using some kind of persistent system agent, stop storing state on your servers. I know this is not the point of the article, but I want to remind people of it so they can can avoid the ssh trap early.

Post reply on HN