Kali Linux

Bore : Simple CLI Tool For Making Tunnels To Localhost

Bore, a modern simple TCP tunnel in Rust that exposes local ports to a remote server, bypassing standard NAT connection firewalls. That’s all it does: no more, and no less.

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

Similar to local tunnel and ngrok, except bore is intended to be a highly efficient, unopinionated tool for forwarding TCP traffic that is simple to install and easy to self-host, with no frills attached.

(bore totals less than 400 lines of safe, async Rust code and is trivial to set up — just run a single binary for the client and server.)

Installation

The easiest way to install bore is from prebuilt binaries. These are available on the releases page for macOS, Windows, and Linux. Just unzip the appropriate file for your platform and move the bore executable into a folder on your PATH.

You also can build bore from source using Cargo, the Rust package manager. This command installs the bore binary at a user-accessible path.

cargo install bore-cli

We also publish versioned Docker images for each release. Each image is built for AMD 64-bit and Arm 64-bit architectures. They’re tagged with the specific version and allow you to run the statically-linked bore binary from a minimal “scratch” container.

docker run -it –init –rm –network host ekzhang/bore

Detailed Usage

This section describes detailed usage for the bore CLI command.

Local Forwarding

You can forward a port on your local machine by using the bore local command. This takes a positional argument, the local port to forward, as well as a mandatory --to option, which specifies the address of the remote server.

bore local 5000 –to bore.pub

You can optionally pass in a --port option to pick a specific port on the remote to expose, although the command will fail if this port is not available. Also, passing --local-host allows you to expose a different host on your local area network besides the loopback address localhost.

The full options are shown below.

bore-local 0.4.0
Starts a local proxy to the remote server
USAGE:
bore local [OPTIONS] –to
ARGS:
The local port to expose
OPTIONS:
-h, –help Print help information
-l, –local-host The local host to expose [default: localhost]
-p, –port Optional port on the remote server to select [default: 0]
-s, –secret Optional secret for authentication [env: BORE_SECRET]
-t, –to Address of the remote server to expose local ports to
-V, –version Print version information

Self-Hosting

As mentioned in the startup instructions, there is a public instance of the bore server running at bore.pub. However, if you want to self-host bore on your own network, you can do so with the following command:

bore server

That’s all it takes! After the server starts running at a given address, you can then update the bore local command with option --to <ADDRESS> to forward a local port to this remote server.

The full options for the bore server command are shown below.

bore-server 0.4.0
Runs the remote proxy server
USAGE:
bore server [OPTIONS]
OPTIONS:
-h, –help Print help information
–min-port Minimum TCP port number to accept [default: 1024]
-s, –secret Optional secret for authentication [env: BORE_SECRET]
-V, –version Print version information

Protocol

There is an implicit control port at 7835, used for creating new connections on demand. At initialization, the client sends a “Hello” message to the server on the TCP control port, asking to proxy a selected remote port. The server then responds with an acknowledgement and begins listening for external TCP connections.

Whenever the server obtains a connection on the remote port, it generates a secure UUID for that connection and sends it back to the client. The client then opens a separate TCP stream to the server and sends an “Accept” message containing the UUID on that stream. The server then proxies the two connections between each other.

For correctness reasons and to avoid memory leaks, incoming connections are only stored by the server for up to 10 seconds before being discarded if the client does not accept them.

Authentication

On a custom deployment of bore server, you can optionally require a secret to prevent the server from being used by others. The protocol requires clients to verify possession of the secret on each TCP connection by answering random challenges in the form of HMAC codes. (This secret is only used for the initial handshake, and no further traffic is encrypted by default.) If a secret is not present in the arguments, bore will also attempt to read from the BORE_SECRET environment variable.

R K

Recent Posts

How to Install Docker on Ubuntu (Step-by-Step Guide)

Docker is a powerful open-source containerization platform that allows developers to build, test, and deploy…

1 day ago

Uninstall Docker on Ubuntu

Docker is one of the most widely used containerization platforms. But there may come a…

1 day ago

Admin Panel Dorks : A Complete List of Google Dorks

Introduction Google Dorking is a technique where advanced search operators are used to uncover information…

2 days ago

Log Analysis Fundamentals

Introduction In cybersecurity and IT operations, logging fundamentals form the backbone of monitoring, forensics, and…

3 days ago

Networking Devices 101: Understanding Routers, Switches, Hubs, and More

What is Networking? Networking brings together devices like computers, servers, routers, and switches so they…

4 days ago

Sock Puppets in OSINT: How to Build and Use Research Accounts

Introduction In the world of Open Source Intelligence (OSINT), anonymity and operational security (OPSEC) are…

4 days ago