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

31–40 of 120 posts

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

#31

Post by sullivanmatt »

kodablah wrote: post #28

Pardon my ignorance, so this updates a security group (or multiple) which presumably have access to several internal things? One wonders if you can take it a step further and for web-based services (i.e. doesn't apply to SSH access), at the conclusion of the authentication, it updates the security group for just that webapp. With how e.g. oauth2 SSO automatically auths via redirects, if the update to the security gro…

There is one network entry point per deployment of our app infrastructure (eg. US and EU deploys), so the lambda does go and update both security groups simultaneously to allow the requestor's IP to hit either if they would like. If you wanted to, you could certainly make it more fine-grained than that, but the goal was simply to cut off the majority of the Internet from these mechanisms as an extra protection layer. There are all the other protection mechanisms (e.g. the mutual certs) to actually protect and authenticate the connection itself.

For web apps, we simply front using an OAuth2-aware proxy. Back in the day, we used this: https://mattslifebytes.com/2018/08/07/protecting-internal-ap... Now, we utilize Kubernetes for hosting most production internal apps, so we run the oauth2-proxy Helm chart (https://github.com/helm/charts/tree/master/stable/oauth2-pro...) to handle verification of identity before sending traffic back to its destination service. Conceptually similar, as auth has to be completed before the request is sent to the back-end.

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

#32

Post by whatsmyusername »

moftz wrote: post #21
whatthesmack wrote: post #17

Earlier quoted context omitted.

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.

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.

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

#34

Post by whatsmyusername »

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…

We do this with a whitelist pattern to the building for 'sensitive' services. Setting up VPNs to AWS is prohibitively expensive if you're not going to build and manage hosts yourself. I don't have the time or patience to deal with it.

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

#35

Post by nitrogen »

bronco21016 wrote: post #20
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…

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.

The vulnerability in your stack may be before your limits/policies are checked.

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

#36

Post by exabrial »

bronco21016 wrote: post #20
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…

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.

Rate limiting across distributed systems is a notoriously hard problem to solve.

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

#37

Post by jschwartzi »

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 device on the internet to a device behind the firewall. We don't control the firewall as it is under the control of our customers.

What we used VPN for is allowing us to establish SSH connections to the equipment. I would really, really like a low-resource mechanism to replace this but everyone wants to deploy their solution in a 90+ megabyte Docker container, or a Snap, which is about 1.5 times as large as the entire Linux system image for our oldest equipment. So these are great solutions for when you control the entire network path from the server(or when you are using a server!) to the Internet including the firewall, but they suck terribly for eliminating VPN in cases where you can't just open an inbound port on the firewall.

As it is I'm trying to figure out how to configure an OpenSSH client to punch out through the firewall to an OpenSSH server, then immediately turn around and provide a shell to the server. This seems to be entirely contradictory to how OpenSSH is designed, but I'm hopeful I can hack something together.

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

#40

Post by xorcist »

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…

Are you just looking for "ssh -fNT -R 10022:127.0.0.1:22 remote"?

If so, then that's not as much a hack as a pretty standard reverse ssh.

Post reply on HN