Bore: A simple CLI tool for making tunnels to localhost

https://github.com/ekzhang/bore

by willmorrison • 4 years ago

272 76 4 years ago

github.com

bnert• 4 years ago

This is super cool. Well done!

ekzhang16• 4 years ago

Thanks!

heinrichhartman• 4 years ago

This is a very slick tool that allows you to forward ports from your local machine to a public server at `bore.pub`.

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?

imachine1980_• 4 years ago

im not the author,but

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

antoniomika• 4 years ago

I used to provide a public instance of sish (a similar app) [0] and can say abuse is most definitely a problem. People were using sish for command-and-control servers, especially because it used only SSH for establishing tunnels. It was specifically chosen because nothing else needed to be installed. Really only worth it if a service provider (DO, AWS, etc) provides free compute and acknowledges the risk involved.

[0] https://github.com/antoniomika/sish

ekzhang16• 4 years ago

Interesting! Thanks for sharing your story. I'll keep an eye out for abuse of the kind you mention. Maybe if that seems to be an issue, I'd turn off the explicit `--port` option on the public server, which would only allow randomly assigned ports.

dspillett2• 4 years ago

Not the author, but:

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

ekzhang16• 4 years ago

See my comment below about differences in goals from remote SSH port forwarding (which I also use regularly).

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

fny• 4 years ago

If these are your concerns, use ngrok.

qbasic_forever3• 4 years ago

It's not really a user concern. It's highlighting that open relays like this are infamously abused and the people that run them can face pretty serious investigations or worse. It would not be fun to be woken up by interpol or the FBI yanking you out of bed with guns drawn because someone was using your public bore.pub service to host or send malicious or criminal content, control a botnet, etc.

pmoriarty• 4 years ago

Could you explain how using this service would spread illegal content?

hsbauauvhabzb5• 4 years ago

It can be used as an anonymous reverse proxy, meaning it could be used to host malicious or illegal files on a malicious users computer, while making it more difficult to trace back to them. Any complaints will have the service IP address rather than the malicious users, meaning the server host is the first person the feds will be questioning during an investigation. And when I say questioning, I mean potentially publicly arresting the host for child porn or similar, destroying their life (despite being innocent), or holing the hosts computer equipment as evidence for months / years as part of the crime, even with irrefutable proof of innocence on behalf of the host.

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.

PeterWhittaker• 4 years ago

While this may be very simple to use, why would I use this in preference to SSH, given that SSH has figured out authentication, session security, etc?

Yes, setting this up with SSH is (mildly) more complex, but given the inherent security, one wonders why one would opt for simplicity.

ekzhang16• 4 years ago

There are different goals here and a different protocol. I use SSH remote port forwarding regularly for my work. It's ubiquitous, encrypted, and works in production. Bore has different goals; it strives for simplicity, ergonomics, efficiency, and correctness. Adding encryption to the tunnel is explicitly out of scope; bore only proxies raw TCP. If you want to add encryption, you would need to run it on top of bore, by setting up TLS termination on your own local web server (TLS runs on top of TCP) or using some other encrypted protocol.

skoskie• 4 years ago

The author has responded in their own top level comment. Currently the lowest comment on the page.

remram2• 4 years ago

They have responded multiple times "see the FAQ" and "different goals" but haven't actually provided an example advantage of this over ssh -R. Unless the lack of security is a benefit somehow? Speed maybe?

svnpenn4• 4 years ago

Is SSH even available for Windows? I see people point to SSH a lot with this topic, but it seems like they assume that everyone has SSH already installed.

mcpherrinm• 4 years ago

OpenSSH has been included with windows 10 by default for a number of years now

ekzhang16• 4 years ago

Hey, author of bore here! I've been summoned by my friend who saw this on the front page of HN. Thanks for posting.

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

dspillett2• 4 years ago

Are there planned advantages to this over what can be done with “ssh -g -R”?

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.

ekzhang16• 4 years ago

Thanks for the words of warning! I’ll keep a lookout for malicious uses, especially now that it’s gotten a bit of attention on HN, which was not planned. Feel free to let me know if you see something suspicious, as well.

reflexe• 4 years ago

Great job! By the way, the term "bore" (בור) in hebrew means 'pit' :)

ekzhang16• 4 years ago

Thanks! That’s great. I was inspired by other commands like “dig” :)

encryptluks2• 4 years ago

I'm running the public server (bore.pub) on a $6/mo DigitalOcean droplet right now, the smallest size on shared vCPU.

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.

ekzhang16• 4 years ago

It tunnels traffic. The egress allowance for DigitalOcean droplets is quite high. If you’re concerned about the effect the cost would have on my personal well-being though, you’re welcome to support me in other ways. :)

mbreese• 4 years ago

If you wanted to do that, you could just set up port forwarding on your router and have people connect directly.

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.

ekzhang16• 4 years ago

The server does have fairly good logging of each connection, including source IPs — feel free to contribute if you see anything that could be improved on this end though.

svnpenn4• 4 years ago

This is a great tool, thank you. I would ignore the haters, plenty of people want something simple like this. Also, you should approach the Rust Foundation to see if they will fund the public site.

userbinator• 4 years ago

Have you looked at the SOCKS proxy protocol? It has a BIND (i.e. "listen remotely") command that seems to essentially do the same thing as this, if I'm not mistaken.

chmaynard• 4 years ago

When I use CTL-C to exit the client, the return code is 130. Is there a way to terminate the client normally?

ptman• 4 years ago

Time is probably more expensive for you than the droplet. But you can run stuff for free as well https://paul.totterman.name/posts/free-clouds/ . Or, even better, let the users of your software know how to run it for free themselves.

polio• 4 years ago

What would this be used for?

qbasic_forever3• 4 years ago

Testing and developing a web service. Run the service on your localhost, like straight from your IDE with a debugger attached, and get a public internet facing bore.pub address for it. You can then point anything at it--your staging/integration or even production service, or maybe just a friend or coworker who wants to see in development work.

quickthrower2• 4 years ago

For me to use it it would need to support https and 443 on bore.pub

ekzhang16• 4 years ago

Yep, those are all good use cases where TCP tunneling comes in handy — basically, how can I get someone to connect to me?

notuger• 4 years ago

I really like to test postback integrations with services like that

hsbauauvhabzb5• 4 years ago

Why not just use ssh with local or remote port forwarding? You get free auth, stream encryption, and battle tested code.

Legitimately, what benefits does this have?

ekzhang16• 4 years ago

Please see the FAQ. I use SSH with remote port forwarding regularly. This has a different purpose. You’re free to use it or not as you wish.

hsbauauvhabzb5• 4 years ago

Your faq doesn’t answer my question

lmc2• 4 years ago

This will expose your local port at localhost:8000 to the public internet at bore.pub:<PORT>, where the port number is assigned randomly.

Port numbers are limited to 65535. Isn't this un-scalable and a massive security risk?

ekzhang16• 4 years ago

This is a small service for developers. Please see the FAQ comment. There are not currently 40,000 proxy connections to the public server (more like 10). If there are then the server will gracefully give an error and terminate the connection.

Please do not spread fear, uncertainty, and doubt about security without precise details. It’s not conducive to a healthy conversation.

hsbauauvhabzb5• 4 years ago

Forwarding ports from localhost is a benign activity unless the port is vulnerable in the first place, I wouldn’t be advocating to blindly forward localhost ports to the internet without a second look.

lmc2• 4 years ago

"Please do not spread fear, uncertainty, and doubt about security without precise details."

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

apitman• 4 years ago

I maintain a list of ngrok/Cloudflare Tunnel alternatives here:

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.

ekzhang16• 4 years ago

Thanks for the feedback! I’ve actually seen your list before developing bore, and it was definitely an inspiration for me. Super helpful resource :)

simulate-me• 4 years ago

I only found out about ngrok from following a guide for the Twilio API. The local tunnel problem is one I’ve had multiple times, but it’s never seemed worth the effort to find a solution. It’s also simple to solve, so I can see how many people end up implementing it without Googling for an existing solution first.

dcow2• 4 years ago

This problem disappears entirely on IPv6. Even more minimal (:

svnpenn4• 4 years ago

Can you elaborate? Someone else said that, but they refused more details when asked. Then someone else said you still need port forwarding with ipv6

duxet• 4 years ago

Most major ISPs in Poland provide only a single IPv6 address to their customers, so unfortunately you still have to deal with NAT.

I am curious about the reason: is it just easier for them to manage such configuration?

lapser2• 4 years ago

I'm assuming the bore server would have to be listening on all ports right? Doesn't that cause risk as all ports (or lots of them anyway) are open?

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.

ekzhang16• 4 years ago

Good question. No, the bore server only listens on ports dynamically when it gets a new connection. It cleans up connections as well. This is managed by Rust’s ownership system. Could you also clarify what the specific risk is of opening ports?

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.

lapser2• 4 years ago

Could you also clarify what the specific risk is of opening ports?

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.

remram2• 4 years ago

The number of open ports doesn't matter, if they all point to the same service.

anonu• 4 years ago

Isn't this socat?

Too• 4 years ago

Socat only forwards ports within the machine it’s running.

This sounds more like ssh -R.

pabs3• 4 years ago

I think I would just use Tor onion services for this.

scns• 4 years ago

Have nearly finished Domain Driven made functional by Scott Wlaschin, highly recommend it. Have to disagree with the conclusion of refactoring legacy system to an event driven one. Subscribing to events makes it implicit and thus hard to follow what is happening. Being explicit pays off.

Klasiaster• 4 years ago

How about UPNPC when your local gateway supports it?

    sudo apt install miniupnpc
    upnpc -r 22 57922 TCP # forward 57922 on public address to this client's port 22

Together with something like https://dynv6.com/ you even get a subdomain that you can point to the public address:

    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"

joshbaptiste• 4 years ago

Binary musl self contained release would be great for adoption..

skanga• 4 years ago

Can we get binaries for Linux, Mac & Windows

Bore: A simple CLI tool for making tunnels to localhost

Related Stories