Initializing the Repeater
This command initializes the Repeater mode: bright-cli repeater [options]
. When a scan is run in the Repeater mode, all the scan requests are pulled from the cloud through a Repeater (scan proxy) to the local target of the scan.
The Repeater mode enables you to run the Bright scans on a local compiled application, without exposing your ports externally. This means that you can scan an application without having to deploy it or to generate external reports.
The Repeater mode is based on the Bright CLI version. If you have already connected a Repeater, you cannot connect the same Repeater (with the same ID) with a different CLI version. In this case, you first need to install the latest version of the Bright CLI and then proceed to the connection.
For more details about the Repeater mode, see Repeater (Scan Proxy).
Additional Features:
- Enables multiple scans to run through a single Repeater.
- Option to add headers to requests locally (for example, authentication cookie), without exposing them to the cloud.
Important
The Repeater mode requires a working
AUTH_TOKEN
with the scoperepeaters:write
.
Options
Option | Description |
---|---|
| The ID of an existing Repeater that you want to use |
| Allows specifying the Bright project for a scan using the project ID. You can find the project ID in the Projects section in the Bright App. |
| Extra headers to be passed with each request. Also, it can be used to remove a header by providing a name without content. For example,
|
| JSON string that contains a header list, which is initially empty and consists of zero or more name and value pairs.
|
| Time to wait for a server to send response headers (and start the response body) before aborting the request.
|
| Initializes the Repeater as a local daemon service.
|
| Stops and deletes the running repeater service |
| Loads scripts to the Repeater from a JSON of
If you have loaded a local script to the Repeater using this CLI command, loading remote scripts from the Bright App is disabled automatically. See Repeater Scripts for more information about how the Repeater Scripts work. |
| You may require to authorize Bright to your network server by providing valid TLS/SSL certificates. This option allows you to load a file with multiple CA certificates to the Repeater that you use for the scan, for example: You can load certificates from the “Trusted Root Certification Authorities Certificate Store” (Windows only): The Bright CLI also supports autodiscovery from the following files:
https://github.com/drwetter/testssl.sh Neither of the tools requires installation or an internet connection. |
| You can load a certificate file per host. The file must contain a certificate in the PKCS or PFX format. This is obligatory for request authorization on a server-side when signed client certificates are requested. In case if the single Repeater needs to be able to load multiple mTLS certificates per set of domains & subdomains it's possible to specify wildcards (
The passphrase is optional. |
| Specifies the path to the configuration file. By default, the CLI tries to discover the config in the |
| Allows setting the level of logs to report. Any logs of a higher level than the one specified are shown. The options to select : 0, 1, 2, 3, 4, "silent", "error", "warn", "notice", and "verbose".
|
| Bright cluster (domain name).
|
| Allows the Bright CLI to proceed and operate even if the server connection is considered insecure |
| SOCKS URL to proxy all traffic. SOCKS4, SOCKS5, SOCKS4a, SOCKS5h are currently supported. By default, if you specify
|
| SOCKS URL to only proxy the traffic applied to the scan-related communication between the Repeater and the target. SOCKS4, SOCKS5, SOCKS4a, SOCKS5h are currently supported. By default, if you specify
|
| SOCKS URL to only proxy the traffic applied to the scan-related communication between the Repeater and the Bright engine. SOCKS4, SOCKS5, SOCKS4a, SOCKS5h are currently supported. By default, if you specify
|
|
|
Updated 19 days ago