https://github.com/anderspitman/awesome-tunneling
It's interesting to me how many times this particular wheel has been reinvented. That said, it's a great exercise and one I highly recommend if you want to learn a bit more about networking.
I like the minimalism of this implementation.
I am curious about the reason: is it just easier for them to manage such configuration?
sudo apt install miniupnpc
upnpc -r 22 57922 TCP # forward 57922 on public address to this client's port 22
curl "https://ipv4.dynv6.com/api/update?ipv4=auto&token=$TOKEN&zone=$ZONE.dynv6.net"
curl "https://ipv6.dynv6.com/api/update?ipv6=auto&token=$TOKEN&zone=$ZONE.dynv6.net"Yes, setting this up with SSH is (mildly) more complex, but given the inherent security, one wonders why one would opt for simplicity.
Happy to answer any questions, though the README has most of the technical details already. Quick FAQ:
--
Q: What inspired this?
A: I wanted to make a really simple CLI tool for forwarding local TCP ports. No TLS termination or any other features. Localtunnel is unmaintained, slow, and requires Node.js. Ngrok v2 is proprietary, while Ngrok v1 is unmaintained, leaks memory, and is complicated to set up (requires wildcard certificates...). Why can't we just write a simple, minimal binary that does this? And focus on user experience (good error messages, clean code, systems correctness). That's the goal.
--
Q: Why Rust?
A: Because Rust gives you a lot of things: tracking lifetimes of variables statically, very fast code execution, data-race freedom guaranteed by the compiler, documentation, unit testing, simple binary distribution in the form of `cargo install`, and a strong focus on correctness. Tokio is also a _really_ great asynchronous runtime for writing network services.
--
Q: Why release a public server?
A: Mostly because I want it to be as easy as possible to try and access Bore, even if you don't have access or the technical means to run an instance in the cloud yourself. That said, "bore.pub" is not hard-coded anywhere inside the source code. The CLI usage examples explicitly pass in a mandatory `--to bore.pub` option to make sure that this software is not tied to any particular server instance. And an explicit goal of bore is to be easy to self-host, just run a single command (it's `bore server`) and you're all set.
--
Q: How much does this cost you?
A: I'm running the public server (bore.pub) on a $6/mo DigitalOcean droplet right now, the smallest size on shared vCPU. I just checked my dashboard, and it's only using 2% CPU at the moment. Will upgrade if I need to, but I don't expect the public server to incur significant fees unless bore gets _really_ popular.
--
Q: Is there potential for abuse?
A: I don't believe there's much potential for abuse here, in terms of distributing illegal content. If you wanted to do that, you could just set up port forwarding on your router and have people connect directly. Also, bore.pub doesn't guarantee you a stable TCP port to share with people; it's intended as a developer tool. So the risk seems fairly low.
--
Q: How can I help with this?
A: You can star the repository, share it with your friends, try using bore, and give any feedback on the issues page. Any help with packaging in software repositories or CI/CD binary builds would always be appreciated as well! Right now the only installation option is from source, using `cargo install bore-cli`. Finally, feel free to follow me on Twitter (https://twitter.com/ekzhang1) where I've been posting some updates on this work.
--
Q: How can I learn more?
A: Read the source code — it's literally 400 lines of Rust, super short if you have an hour or so this afternoon. :)
But that would expose their IP address. It’s easier to just use your bore.pub server and hide their IP address. If you don’t want to add authentication to the bore.pub server, I hope you have really good logging.
Does this not tunnel traffic. What is your plan once you go over the bandwidth allowance? It seems like you are probably in for some unexpected surprises very soon.
ngrok for instance can be used record and replay (potentially modified) API calls.
> I don't believe there's much potential for abuse here, in terms of distributing illegal content.
I think you are quite wrong there. Any public resource can and will be abused.
> If you wanted to do that, you could just set up port forwarding on your router
That will be easily traced back to the the distributor of the content. By using you as a relay the authorities will hit you first. If you keep accurate logs then you can send them onto the next step (which may well be another open proxy) but you'll have some explaining to do.
Also, if it causes any trouble for your service provider they may kick your account first and ask questions later, especially if the content is something insidious like CP. In any case check your service provider's ToS - they may explicitly disallow running open proxy services.
I hope this service will continue to be available, however it looks to me as if this service is very easily abused (e.g. by spreading illegal content). But even if it just gets popular there are bandwidth costs which may run high quickly, if you have a few 100 heavy users.
If the author is here:
- How much of a concern is this for you?
- Do you have plans to offset the bandwidth fees?
- The backend is a single host, right? When would you need to scale this?
- Yes, this will be quickly abused now it has been made more public, unless the service at bore.pub has the shared secret set (have you tried to connect?).
- The service may currently be running on a host that has “unlimited” bandwidth as a limited speed, so there may be no extra bandwidth feeds to offset (though the bandwidth will be increasingly saturated and so progressively much slower for each active connection).
- I don't think scaling was intended, more than people would run their own version on their own service. Scaling could be achieved to an extent with a fatter bandwidth allowance (a faster rate cap, if I'm right about that being the limit not a fixed bandwidth cap). Unless the service is running on a very fast link on a very slow (or congested) CPU, bandwidth will likely be the limiting factor not anything else. If the process is large and forks for each connection then memory could be a limitation, but that could be increased easily or you could have multiple servers on the same name using a load-balancer or simple round-robin DNS.
Though I'm not sure what this offers beyond using a reverse SSH tunnel, if you have your own server/VM to host it on. Of course if you do not have your own external server but an account on someone else's which does not allow tunnels like that then this tool could be useful, but you could also get your own VM with full access for not much more than $1/month.
Scaling issues are not a problem for me, but thank you for your concern. The nice thing about scaling is that you only have to worry about it if your service is used a lot, and bore is just a small hobby project. I mention in the FAQ where I’m currently at with CPU/memory usage and network egress; it’s very cheap and not even close to hitting limits. (thanks Rust!)
On the things not to host, a public variant of this would be at the top of my list, right next to tor exit nodes.
don't do that, since crypto mining exist let people access to your machine means they gonna make you mine monero, that's what happens to kill public Unix systems, tradition who start in the early 80s.
but i probably use this to test mobile-web, sometime web APIs, like cameras doesn't work consistently between chrome pc and chrome android for example, let you test this solution in real hardware Without need to deploy.
other option is cloudflare tunnels
Also, seems like it'd be trivial to add TLS termination. I've used ngrok for it's TLS termination when developing GH Webhook listeners.
Bore has an explicit design goal of being easy to deploy yourself. Unfortunately adding TLS termination would necessitate setup steps like creating a wildcard certificate and uploading it. It also requires additional configuration options, since TLS termination is on top of HTTP, but bore only proxies TCP directly and is unaware of HTTP. This is by design.
I guess I was meant from a firewall perspective. I understand the ports won't be listening but any potential firewall will not be able to block the port unless you have some integration to dynamically get the firewall to open and close ports on demand.
Legitimately, what benefits does this have?
This sounds more like ssh -R.
Port numbers are limited to 65535. Isn't this un-scalable and a massive security risk?
Please do not spread fear, uncertainty, and doubt about security without precise details. It’s not conducive to a healthy conversation.
I read the FAQ several times before posting, and it still didn't answer the security question. Elaborating my concerns...
You suggest developers use this. That means, users will most likely be running dev servers. Dev servers, especially in the NodeJS world offer the ability to connect a debugger.
What happens when someone spams requests to connect a debugger to bore.pub:<PORT>?