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 alias)	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. Required option.
`--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`	(Deprecated). Use the `--header` instead. 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), Linux (System-V, Upstart, SystemD), and macOS.
`--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 Default: `false` 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.
`--bus=eventBusUrl`	(Deprecated). Bright event bus URL. Default:`--bus amqps://amq.app.brightsec.com:5672`
`--rabbitmq`	(Deprecated). Enables legacy mode, utilizing the RabbitMQ connection for communication.
`--ntlm`	Configure experimental support for TCP connections reuse.

👍Important:

Options

👍
Important: