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 scope repeaters:write.

Options

Option	Description
`--id=repeaterId`, `--agent=repeaterId` (Deprecated)	The ID of an existing Repeater that you want to use
`--token=apiKey`, `-t=apiKey`	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. Global Repeaters are available for every project. You can also connect a Repeater created for the specified project. But if you try to use a Repeater created specifically for some other Bright project, you will get an error message.
`--header=headerName:headerValue`, `-H=headerName:headerValue`	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, `-H "Host:"`. Warning: Headers set with this option override the original headers and are set in all requests.
`--headers=json`	JSON string that contains a header list, which is initially empty and consists of zero or more name and value pairs. Warning: Headers set with this option override the original headers and are set in all requests.
`--timeout=milliseconds`	Time to wait for a server to send response headers (and start the response body) before aborting the request. Default: 30000 ms
`--daemon`, `-d`	Initializes the Repeater as a local daemon service. Note: If you run this command while a service is already running, it will first stop and delete the running service, and then restart it with the new repeater settings. Note: Currently supported operating systems include windows (wscm) and Linux (systemd).
`--remove-daemon`, `--remove`, `--rm`	Stops and deletes the running repeater service
`--scripts=json`, `-S=json`	Loads scripts to the Repeater from a JSON of `{"host": "filepath"}`. Note: Wildcards are also supported, for example: `--scripts '{"": "./hmac.js"}` for a global script for all target hosts, or `--scripts '{"_.domain.com": "./hmac.js"}` for all target hosts on sub-domains. 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.
`--cacert=pathToCACerts`	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: `bright-cli repeater --cacert /etc/ssl/certs/ca-certificates.crt` You can load certificates from the “Trusted Root Certification Authorities Certificate Store” (Windows only): `bright-cli repeater --cacert true` The Bright CLI also supports autodiscovery from the following files: `/etc/ssl/certs/ca-certificates.crt` // Debian/Ubuntu/Gentoo etc. `/etc/pki/tls/certs/ca-bundle.crt` // Fedora/RHEL 6 `/etc/ssl/ca-bundle.pem` // OpenSUSE `/etc/pki/tls/cacert.pem` // OpenELEC `/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem` // CentOS/RHEL 7 `/etc/ssl/cert.pem` // Alpine Linux `bright-cli repeater --cacert true` Important: Currently, the Bright’s insecure TLS configuration test is limited to cloud-based scans and is not available for scans run in the Repeater mode. In this case, you need to manually check if the ciphers and encryption applied to the TLS certificates are strong enough, to ensure a high level of security of your application. To simplify the check, you can use open-source TLS/SSL testers, for example: https://github.com/drwetter/testssl.sh https://testssl.sh Neither of the tools requires installation or an internet connection. For more information about the TLS configuration issue, see the Vulnerability Guide.
`--cert=json`	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 (``) in the host, for example `.brightsec.com`. Format: `--cert "{"hostname": "example.com", "path": "./example.pem", "passphrase": "pa$$word"}"` Example: `bright-cli repeater --cert "{\"path\": \"/home/user/example.pfx\", \"hostname\": \"\*.example.com\", \"passphrase\": \"pa$$word\"}"` The passphrase is optional.
`--config=pathToConfig`	Specifies the path to the configuration file. By default, the CLI tries to discover the config in the`package.json` in the root directory of your application or a separate file by a specified name in the working directory. For details, see Configuration Files for more information.
`--log-level =0/1/2/3/4/silent/` `error/warn/notice/verbose`	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". Default: 3
`--cluster`	Bright cluster (domain name). Default: `https://app.brightsec.com`
`--insecure`	Allows the Bright CLI to proceed and operate even if the server connection is considered insecure
`--proxy=socksProxyUrl`	SOCKS URL to proxy all traffic. SOCKS4, SOCKS5, SOCKS4a, SOCKS5h are currently supported. By default, if you specify `SOCKS://<URL>`, then SOCKS5h is applied. Note: `--proxy is mutually exclusive with --proxy-external and --proxy-internal`
`--proxy-internal`	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>`, then SOCKS5h is applied. Note: `--proxy is mutually exclusive with --proxy-external and --proxy-internal`
`--proxy-external`	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 `SOCKS://<URL>`, then SOCKS5h is applied. Note: `--proxy is mutually exclusive with --proxy-external and --proxy-internal`
`--bus=eventBusUrl`	(Deprecated). Bright event bus URL. Default:`--bus amqps://amq.app.brightsec.com:5672`

🚧Important

Options

🚧
Important