Ngrok: Secure tunnels to localhost
ngrok.com
ngrok.com
For me, the killer feature for ngrok is testing/developing webhooks. You install ngrok in your dev environment, start it up, then point the stripe/slack/whatever webhook your working on at the generated URL.
ngrok will 1) proxy that request through to your dev environment 2) log the request 3) log the response 4) let you replay previous requests. It could not be more helpful for developing webhook handlers, and has literally saved me hours of work in the last couple of months alone.
Finally, the free tier is all you need for that; it gives you a unique ngrok subdomain which changes every time you start the tunnel and some (generous) usage caps, both of which are fine for this usage.
People pointing out the potential security issues are correct, but that's an argument to be careful and think about what you're doing. Besides, what's your proposed alternative? Because most of the obvious ones have equally troubling issues.
Setup a proper development environment that mirrors the production environment?
Some, if not most, services won't allow you to redirect cold to an IP address, they want some domain of sorts. There are alternatives, but I think "setup a proper dev environment" alone misses the point of what ngrok does.
The 'easiest' alternative I've tried before was to VPN into my Linux box to get a static internal IP, use a spare domain for the webhook then internally redirect the webhook traffic to my local machine. In the end I'm achieving what ngrok is doing (and none of it involves setting up a proper dev environment, cos I would already have one anyways), but I'd like to hear of better alternatives :)
of course you can portforward your ip via vpn or ssh tunnel. And that's would be the exact equivalent of ngrok, but with way more time and frustration to set it up.
> don't have a static IP that's internet-accessible
I am one of those people :) I don't pay my ISP extra for a "real" IP address, so I have literally no way to receive incoming connections from the internet into my home network, it's all behind their NAT.
it's a bit of setup, but works quite well once set. does _not_ provide the features ngrok does of replay, etc, but at least it's 100% your own infrastructure.
edit: to clarify: no reason why it should be a special subdomain, i just use beta.mywebsite.com, just something that belongs to you and is globally dns resolvable, could be mytestdomain.com for your use. you can skip nginx if you don't mind binding to port 80 directly (i.e: no webserver already exists on that machine)
Locally, I also mirror the LE keys and add a hosts file entry for the test domain to localhost.
This means I can test locally with proper ssl certs.
This is probably a good thing for security. But for the use case of development against third party services, it seems like an unnecessary constraint.
Stripe wants a URL to send the payloads too, and my proper development environment is (not surprisingly) running inside a vagrant on my dev machine inside our office LAN. I could open up a port on our firewall and forward it through to my laptop but:
1) ngrok is easier
2) ngrok provides additional features
3) This has every drawback ngrok has and more
4) None of this has anything to do with having a proper dev environment. :)
Can't reply so an edit: Yes, ngrok is actually easier than port forwarding. Plus it has logging and replay.
ngrok can not possibly be easier than port forwarding.
Run `ngrok http 3000` or whatever port your app is running on and you're done. Now you have both an HTTP and HTTPS endpoint that you can publicly access.
Some webhook providing services also require HTTPS. ngrok gives you that right off the bat. Setting up self signed certs and running nginx, or faking a FQDN and using xip so that you can register a real certificate seems like overkill if all you want to do is test a webhook.
ngrok is also perfect for live demo'ing apps to clients.
Oh come on, of course it can. I use port forwarding myself, but ngrok literally makes testing remote webhooks as simple as running "ngrok". That's it. It's definitely what I recommend coworkers who just want a quick solution to test out 3rd party service integrations.
For people without public IPs - why not just learn how to setup an SSH tunnel instead? Similar effort, save it as a script. Boom, you actually learned something useful too.
...really? You're trying very, very hard to dislike this tool and it's kind of funny. What is the objection to it, exactly? It makes a task easier. You don't have to use it, but others can.
If you're proposing SSH tunnels as an alternative, where am I SSHing to? I need a publicly accessible remote box. So I'll need to set that up, then set up an SSH tunnel. Or, install a CLI tool and learn one command.
I've used ngrok because it was something that I could generally count on other people being able to install. I can't always be sure they understand how to do some of the more advanced stuff being suggested in this thread (they may not have permissions, or time, or technical knowhow).
But... If the only reason you do this is because you haven't got a clue about what dynamic DNS is, as many here seems to do, or you feel that setting up a SSH tunnel is complicated then I'm going to assume that you have no clue about the security implications of using something such as ngrok (or an SSH tunnel) to your local machine - and should probably not under any circumstances be allowed to set one up at your office.
That assumption might be wrong, but the discussions here only reinforce my belief that the niche for this (perhaps excellent) tool should be extremely small even within the HN audience. And that it isn't (currently at the top of the front page) is quite concerning. It solves a very small problem that I can solve with tools I (and most people on HN) already have installed - without going through someone else's cloud. Without registering for yet another service (bad or good, doesn't matter).
I'm questioning that there is a need for this among the HN audience. And I'm questioning that most people that have a need for it should be allowed to use it. Whether the tool is awesome or not is besides the point.
Maybe don't keep sensitive data on your dev machine?
So it's not similar effort, especially given that I use it on my corporate network where doing port forwarding more assuredly would be difficult and problematic.
Not quite. If you are on the free tier, you also need to change your stripe/slack/whatever webhook URL to the new endpoint URL it gives you each time you run it.
Not a huge hassle, but it's worth mentioning.
Then all you need to do is a one time setup of nginx on your Vultr (or DO or whatever) box to accept incoming webhook requests from e.g. stripe and proxy them down the ssh tunnel to your dev machine.
With the above in place, you'd literally hit one button on your keyboard to establish the tunnel and spawn whatever local process you want to receive the webhooks and... voila. It's secure, gives you logging and works from anywhere without needing any external port forwarding.
Agree none of that may be worth it in your case. Personally, I don't think there's anything wrong with ngrok in certain circumstances. The above is just an alternative approach with different trade-offs/benefits.
It's not that I don't think that it's worth it, it's that I'm still not seeing the advantage.
"More secure", if I assume that throwing a VPS up on Vultr, and adding apt-get update/upgrade to a cron job is more secure. "Easier to audit", if I assume that I go to the trouble to somehow make it auditable. "Removes a hard dependency on ngrok", if I assume that my planned usage of ngrok was actually a hard dependency (it's not). "Gives me a static ip", if I assume I have the slightest use for such a thing when my planned use is "spend a couple hours hacking on a webhook handler". "Can share the same box among multiple devs", if I assume that would give me any benefits.
> The above is just an alternative approach with different trade-offs/benefits.
For my specific case, it seems more like an alternative approach which is almost as good, almost as easy, and almost as cheap.
The big question mark is really about security; but in principle you should be using both solutions as an ephemeral tunnel for sending sandbox data from a cloud service to a local dev environment. Even if I assume every single bit of data that I sent through ngrok was being read by an attacker (not a bad assumption!) I'm fine, because no production data, keys, credentials, etc., went through it.
You're quite right that ngrok is doing a very, very basic thing that you could duplicate, if you wanted to, very easily. But it's free (for the sort of use being discussed here), and easy, and the replay/logging is more useful than you might think.
Personally, I prefer a generic solution that doesn't rely on a specific third party for something as everyday as tunnelling internet requests back to my dev machine. I value that more than the replay and zero-maintenance benefits of ngrok.
Doesn't mean my approach is better than yours. Just means my approach suits me more :)
Edit: btw my earlier post should have read "easier to debug" rather than audit - sorry.
As a developer, ngrok makes it really easy to show-off your feature branch to customers/rest of the team, regardless of your location. And you're not dependent on having a CI deploying to per-branch environments.
Yes, there are alternatives, but I hate when people jump to dismiss service like this, without fully considering what issues the proposed alternatives have. Obviously it is ok to mention the alternative options, but that can be made in constructive way.
Let's celebrate the fact that somebody has built and released something and even seems to have a business model to support it. Instead of complaining about 5-20 bucks per month, try to figure out how you could channel some of your corporate multimillion IT budget to this fellow hacker. Wouldn't it be great if building and running this kind of small solutions would be actually a viable way of making living?
If your users are productive, chances are so is the company that pays both your salaries. If your users have to fight their infrastructure people to get their jobs done, you company will fail to effectively compete against those companies that don't.
It astounds me that so few security people understand what their purpose is: Your purpose is to assist the company you work for to keep on existing, and even make a profit. If you disempower those that are most effective in helping the company do what it does you're effectively destroying your own livelihood, and everyone else that is dependent on it.
Productivity means nothing in the face of data exfiltration. You only have to fail once at guarding a password in order to be completely compromised. If we seem tightly wound, it's because we have fully internalized and grok the stakes of our efforts and the entailment of failure.
"Our infrastructure sucked, so I used an insecure tool to leak our credentials to third parties, because I couldn't be productive otherwise!" is not really a valid excuse in this light, since there's no amount of productivity which offsets data exfiltration.
And you harm security if you're being sufficiently inflexible that staff see it as essential to circumvent your security measures to be able to do their job. Because they will almost certainly manage to do so.
As such, if you hurt productivity enough, you are also going to be failing at protecting company data by making people find alternative solutions, and you're not likely to get permission to go far enough to stop it unless you're working in a field where security clearance is the norm.
If the dev team needs something like ngrok, the security team has failed to provide proper tools.
If the dev team goes ahead and uses ngrok without consulting the security team, the dev team has likely committed an awful security breach.
The dev team and the security team need to think of each other as being on the same team, and talk to each every day about what they want and need.
just don't use your company's name in the domain name, make it something obscure.
If you're dismissing it as a security nightmare without considering why someone would want to use it and trying to figure out how to make it work or come up with alternatives, then you're failing your mission IMO. There's ways of securing ngrok... you can self host, put it behind a firewall, and whitelist services. It may still open a potential attack vector, but so does the mere existence of connecting to the internet. It's a balancing act, we should all be familiar with.
I don't see where this follows from. "private repos" and "testing" implies "local testing" for me. If that implication does not hold, the development workflow is seriously screwed. (Don't tell me there is no money for a local test setup when you have dedicated IT security.)
And in my experience, more often than not, it is screwed because someone decided to use some other flashy tool without realizing the security implications.
If you really, really need to poke holes into your firewall can easily that with ssh to a cheap vm hosted at your trustworthy hoster. If ssh ain't enough, nc and socat are your friends.
Wouldn't that still be the same, considering ngrok is just doing the tunneling. In this case, ngrok is your trusty hoster. You can park your trust into your own VM in Digital Ocean, or you can park it at ngrok.
your laptop is a very different environment from production: there are probably different protections, firewalls, monitoring, etc in place. additionally, while your laptop (hopefully) doesn't have direct access to production databases, you probably have stuff lying around that you wouldn't want an attacker to get their hands on: sensitive work documents, your Chrome cookies just sitting in a sqlite database somewhere, source code for all the repositories you have checked out locally (not just the one app that has the exploit).
I don't agree that "using ngrok is not a security risk".
if the only thing on the line is low-value things like whatever is on your personal laptop (or even whatever is on a spartan vanilla ubuntu VM that your app is running in), then maybe it's not a very big gamble.
if the laptop has corporate secrets on it or it can be used as by an attacker to pivot into company internal systems through the VPN you're also connected to, however, that's a completely different story.
Anyways my ISP has provided me with a fixed IP for about 17 years.
Good on you though , that apart it seems a great idea well implemented. Easy to throw stuff up for prospects/clients in an agile way without having to talk to devops.
Why not free as in bird? It is already free as in beer.
Seems free vs. paid is about reserving/custom domain vs. random one and a lot of security related feature. But the basic tunneling works for free am I correct in that?
Also what does the user really mean in terms of ngrok concurrent user or kind of named seat.
Can you speak to security? I love using ngrok to test stuff in dev that requires SSL without having to setup up SSL. Of course that means it's running through your cert. Obviously one shouldn't run anything protected through your system, but what is your visibility into that traffic?
That assumes this is my only use case for using ngrok :-)
The website says it is for exposing a local server behind nat or firewall to the internet.
1. local server is by definition supposed not to be exposed to the internet 2. to expose a server behind a NAT there's this thing called port forwarding 3. to expose a server behind a firewall there's this thing called a DMZ or correctly configuring the firewall
There's a lot of data collection happening, the privacy policy is leading on the weak side. Is there an option to opt out of all this data collection so when comes the time to disclose, sell, give or share data I can be guaranteed my data or any data generated by my use of ngrok will not (you can't share something you don't have)?
What makes ngrok better than a free software tunnel solution I can use by myself with no third party involved ?
What about IPv6 support ?
Think of a front end developer working on a mobile site. Now, in an ideal world everyone would know how to set up an SSH tunnel, but let's be real here, even you probably have to look up the exact flags you're supposed to use every time you want to set up one. Combine this with the need for a publicly accessible server somewhere, and it should become somewhat clear that many simply do not possess the skills, resources, and/or couldn't be bothered to go through the trouble. With ngrok, you just download a single binary, make it executable, and you're ready to go. It's easy enough for most, although I suspect a GUI would further increase its reach.
Corporate policies often prevent employees from connecting their private phones to the internal network, so simply accessing the internal IP isn't really doable. You might be able to apply to have your device whitelisted, but that may take days, perhaps weeks, and even if you're approved, it doesn't really help as you cannot show your work to others (e.g. your team lead) without having their devices whitelisted as well. You might argue that everyone should have a company-provided phone with access to the network, and that's certainly a solution. Realistic? At most companies, probably not. You might have shared phones but who wants to work like that? Plus, there are developers who feel more comfortable playing with their own phones anyway. Regardless of which and whose device they have, they'd still be limited to WiFi only. Sure, you can emulate slower networks, but that's one more thing to know about. With a tunnel, you can see how the thing you're working on feels over a real 4G connection with no additional configuration. All this while developing locally with no need to waste time deploying to a separate environment.
That's just one use case where ngrok shines. The fact that you do not need to "correctly configure a firewall" is a selling point. Does it circumvent the firewall and expose machines on the internal network? Yes it does, and that's certainly a concern. But since people are people, perhaps you should have a similar, easy to use service available for your developers so that they don't have to resort to third party services you have no control over.
For example, even though I use SSH tunnels quite often, and can in fact remember the flags, I sometimes don't remember if the local or remote port came first. A minor issue for me perhaps, but I'm sure you can imagine someone getting stuck at some point, and having to bother a team mate to check what's going on, which is an entirely avoidable waste of time. You also have minor ops overhead for making sure the tunnel servers stay up and running.
In the end, aren't nearly all tech businesses about improving the user experience in some way? For example, you could set up your own mail server (and deal with the issues that come with it) instead of using Mailgun/Sendgrid, or take a taxi (or drive) instead of using Uber/Lyft.
I tried ngrok (and localtunnel) two months ago to show a localhost WordPress site. Both failed because WordPress uses absolute links to reference css, js and img assets.
So the site was visible under whatever.ngrok.com but the assets where still linked to localhost. I read the FAQ at https://ngrok.com/faq#wordpress and tried all the mentioned plugins plus some other hacks. None did work. In the end I wasted almost one day.
I ended up renting a Simple PHP Hosting for 2 days to which I cloned the site. Which was also half a day but only cost me 2 € (site was online only for 2 days or so) and in the end, it did work.
Used to use your paid version until the new pricing model. I don't use it often enough to warrant paying, so I just setup the old version on my own VPS.
This is genius. It immediately simply told me exactly what your and service does. A few common, short examples beneath that would also be great. I would see this being great to show off an app on the development branch to a client in a meeting.
It's a service that, for us, is worth its weight in gold for all the configuration and maintenance we don't have to do. It's definitely one of the first tools in our toolbox we reach for. Thank you very much for ngrok!
Love it for developing anything using webhooks and also hybrid mobile apps (I have my app pull the JS from the Dev box I'm working on via ngrok without having to rebuild the app or deploy the code anywhere).
It significantly speeds up my workflow!
Anyway, happy customer here! Recommending this product whenever I go:) It has became an essential part of my workflow.
IRCCloud (4$) + ngrok (10$) + some free libre email provider (5$) + 1TB cloud storage (10-12$) + ...
The combined cost for me is enough that it’s cheaper to rent a dedicated octacore xeon with 16G ram, 250G SSD and 1TB HDD and unlimited traffic with a 1Gbps line[1], and run my own services. In fact, I pay less than 50% of what I’d pay for the services, I have far more performance, and can offer these services to 10 people at no cost, and still come in better.
These services might be worth it if you’re in SV, but 10$/mo is something different to a person earning 300k$/year in SV, and to a student earning 8k$/year somewhere else.
________________________
https://ngrok.com/docs#subdomain
edit: Just in case, I updated to 2.2.4 (newest) and it's still possible to use custom subdomains.
Tunnel session failed: Only paid plans may bind custom subdomains. Failed to bind the custom subdomain 'blahblahblah' for the account xxx
Setting up a VPS with frp on it would take 30 minutes tops (assuming that I don't already have one and that I'm in no hurry). Even if I was some big shot, doing $120 an hour, that's just 60 / (10 - 3) = 8.5 months of Ngrok. These $60 would be a good investment by my book.
But I'm not counting pennies here, I'm merely pointing out that the pricing is unreasonable. I can afford it, but its usefulness per dollar is disappointing.
For example, compose.com can host a Pg database for $17, one master and one slave, with automatic backups, a rich control panel, competent customer support, batteries included. It's maybe only twice as expensive as replicating the setup on your own (which would take literally weeks for a single person), and brings almost as much value as hiring a sysadmin. And then there's Ngrok, 3-4 times as expensive as DIY, while saving you a total of 30-60 minutes of one-time effort. And costs more than a half of a pretty great Pg server. Ridiculous.
Props to the people behind Ngrok, if they're in the black with this pricing. Good strategy/marketing.
I used the free plan for a while but having a reserved subdomain is pretty sweet. And the cost for a whole year of it is fairly small in my opinion.
On a machine on the LAN, install Tor and set up an authenticated onion service, and point it to the desired endpoint. In order to access the service, clients need a manually-loaded encryption key (and Tor, of course). Without this key, nobody will be able even to discover your endpoint, let alone actually connect to it.
[0]: https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt
To me it seems a lot cleaner, simply use SSH rather than download any app
This is a similar open source alternative: https://github.com/fatedier/frp
Both written in Go.
When you're editing HTML/CSS, you don't have to run a deploy script before checking how your markup renders. Ngrok gives people writing web services the same convenience when dealing with requests from a 3rd party on the Net.
It is the equivalent of saving your HTML/CSS source files and instantly seeing the changes when you reload your browser.
I just wrote a little proof-of-concept Alexa app that crawls HumbleBundle ('Bundled Goods', very much beta quality at the moment) and ngrok was invaluable for developing it quickly.
It's also super handy when building webhooks, you can use the unique URL to test out apis without having to deploy anything. I can't rave about it enough.
I think a better comparision is with DynDNS services: It sets up a public host connected to your own machine - but unlike DynDNS, the host doesn't point to your machine's IP directly. Instead, requests are routed through a proxy/tunnel, so your machine can be kept behind a firewall and is only available through the public host.
(I figure, the proxy allows for some more neat tricks, such as restricting ports/urls/etc or holding requests open while your machine changes IPs.)
It takes two seconds to deploy an application in the evening from my kitchen table, check it also on my mobile and the next day access it from work also and show it to co-workers.
Call it "usability" for Engineers!
With a DDNS + Port-forwarding you can easily have what Ngrok provides? or am I missing something?
I use it to prototype webhook entry points, and only need to receive a few call to have a quick confirmation I receive what I expected from the docs.
Once I have enough info I can start building a more solid project and jump through all the hoops to have it on a real server with a subdomain and a public facing interface and all the security needed etc. I'd just hate to go through the whole process first, only to discover the service is unusable for my purpose, or the data I receive doesn't make any sense.
1) My university blocks LogMeInHamachi which is the main tool i've tried to get around hosting behind a NAT. Will this likely be blocked too, or is it not possible to tell without trying
2) Is there any costs associated with this. Do i ever need to pay
3) Does the person connecting to my server also require a special client or does this appear to them as any standard connection would.
It's a professional tool with real use. That's worth money.
(On my phone now so I can't try it out.)
Free Plan
For quick demos and other simple tunneling needs.
* HTTP/TCP tunnels on random URLs/ports
* 1 online ngrok process
* 4 tunnels per ngrok process
* 40 connections / minuteThe infrastructure is sponsored by Enchant.com
People like me would like to buy 5-10 licenses and manage them centrally.
Define shared endpoints and individual endpoints,etc
Ok it is slower, but for many things like ssh it's great...
^ that expression will expose a local docker powered web server, assuming www.example.com is the local dns name on your docker network. Enjoy.
Well, yeah, of course, incompetent or malicious company IT can prevent you from being a productive developer and you may then feel the need to work around that, that is largely orthogonal to whether the world is using IPv6 or not.