[HN Gopher] Bore: A simple CLI tool for making tunnels to localhost
___________________________________________________________________
Bore: A simple CLI tool for making tunnels to localhost
Author : willmorrison
Score : 99 points
Date : 2022-04-09 18:38 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| lmc wrote:
| > 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?
| heinrichhartman wrote:
| 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_ wrote:
| 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 wrote:
| 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
| ekzhang wrote:
| 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.
| fny wrote:
| If these are your concerns, use ngrok.
| qbasic_forever wrote:
| 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.
| dspillett wrote:
| 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.
| ekzhang wrote:
| 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. :)
| dspillett wrote:
| 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.
| reflexe wrote:
| Great job! By the way, the term "bore" (bvr) in hebrew means
| 'pit' :)
| bnert wrote:
| This is super cool. Well done!
| polio wrote:
| What would this be used for?
| qbasic_forever wrote:
| 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.
| PeterWhittaker wrote:
| 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.
| ekzhang wrote:
| 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 wrote:
| The author has responded in their own top level comment.
| Currently the lowest comment on the page.
| hsbauauvhabzb wrote:
| 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?
___________________________________________________________________
(page generated 2022-04-09 23:00 UTC)