Recently I implemented a content block on all web hosted proxy tunnels that I knew of. This caused some consternation with our software development team as they claimed they needed ngrok to be able to expose their dev environments to an external source for testing. After some back and forth, their explanation made sense and I relented and allowed ngrok specifically through under the condition that once a more secure alternative could be found and implemented, it would be blocked again.
After a weekend of research however I haven’t really found a more secure alternative. Everything else I have found just seems to be ngrok with more steps. So I come here with the hopes that there actually is a good way to allow a proxy tunnel for developers that doesn’t open us up massively to known abused services.
I know a lot of people that liked Cloudflare Tunnels or Tailscale, but I have moved away from Cloudflare after having to deal with the messes they refuse to clean up.
Here is a list of some available tunneling tools. ngrok is definitely loved by developers. If you wanted to go for a self-hosted option more in your control I have heard decent things about Pangolin and frp
I use a tailscale funnel for my arcade work, it was very easy to get running. Felt just as quick as ngrok did to me. Since the testing source is external I assume @MustardFacial can’t add it to mesh vpn? If he can I would second that might be the best way to do it
Ok so it looks like my initial research is matching up with some amount of consensus here in that the solution to this problem isn’t really a solution as much as it is “ngrok, but with more steps.”
Which is fine if that’s what I need to do. Having a locally hosted solution that I control and can keep an eye on is preferable to developers doing whatever the hell they want because security controls “affects their productivity”
But in an environment where you want to limit the number of options an attacker has, it seems to me that having a company-sanctioned reverse proxy to the open internet might be a bad idea.
The compensating control here is gating the access to the service with IAM. It can’t just be “Open a service and YOLO.” Netbird and other Wireguard reverse proxies do exactly this.
Oh absolutely, and that is the approach I am going to take on implementing the new solution. I was just complaining more about the fact that I have to allow a service with such huge security implications at all. I try as much as I can to approach these problems with an attacker mindset. Specifically in this case: “If I’m able to pop a developers machine/get their credentials, then no amount of IAM controls are going to stop me from using a built-in reverse proxy that the defenders are going to see as normal traffic.”
But then perhaps I’m focusing too deeply on the specifics. Their procedure right now is exactly as you describe “YOLO baby, ngrok free tier push to prod and crack a beer” so any amount of compensating controls I can put on top of that is going to be an improvement.
This is 100% correct, but I would contend that it’s a separate issue from the proxy service. If a dev’s identity or endpoint is compromised, the reverse proxy service wasn’t the attack surface. Access to such a service is a compounding risk, but that’s where things like MFA come into play.
I really need to get around to writing up my “Identity is the new edge” talk I give internally.
I would love to read that talk. I’m sure it’s far more convincing than the rants I go on to the C-Levels about how important defending identities are.
And yes while I fully agree with you that identity is the new edge, we live in a world where ClickFix attacks are extremely effective (thanks a lot for that one Google ), Entra Refresh Tokens have a rolling 90-day lifetime, and humans are creatures of habit and convenience. It only takes a single lapse in judgement to not think fully about the window you’re pumping your creds into, or why an application is prompting for Device Code Flow and now your identity belongs to the attacker*.
And yes, while there are many compensating controls for this (for the love of god please disable device code flow and have some kind of geolocation blocking on your IdP login page). Novel attacks are coming out all of them time, and some of the compensating controls simply can’t be implemented because the org relies on them.
But I digress, all of this is a completely separate conversation from the original topic. In any case, I’ve received the answer to my original question and I thank everyone for their insight and further discussion.
*At least long enough before the token can be revoked, or their credentials reset.
