Initializing the Repeater

--id=repeaterId,

The ID of an existing Repeater that you want to use.

--token=apiKey, -t=apiKey

The token (API key) to use, either a User Key, a Project Key or an Organization Key. 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.

--timeout=milliseconds

Time to wait for a server to send response headers (and start the response body) before aborting the request.

Default: 30000 ms

--log-file

File path to write logs to. If specified, logs will be written to this file

Default: User home directory

Extra optional params when --log-file is specified:

--log-max-size Maximum size of log file before rotation (e.g., "10MB", "1GB"). Default: 10MB

--log-max-files Maximum number of rotated log files to keep. Default: 5

--log-rotate-interval Time interval to rotate log files (e.g., "1d", "12h", "7d"). Default: 1d

--log-compress Compress rotated log files using gzip. Default: true

--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 Insecure TLS Configuration vulnerability page.

--cert=json

Certificate Configuration
You can load certificate files for multiple hosts by specifying the --cert flag multiple times. Each certificate file must contain a certificate in PKCS or PFX format. This is obligatory for request authorization on a server-side when signed client certificates are requested.

Multiple Certificates Support
The Repeater supports loading multiple mTLS certificates for different hosts and ports. You can specify multiple --cert flags in a single command, with each flag containing the configuration for one certificate.

Certificate Configuration Format
Each --cert flag accepts a JSON object with the following parameters: hostname: The target hostname or IP address path: Path to the certificate file (PKCS or PFX format) passphrase: Certificate passphrase (optional) port: Target port number (optional)

Wildcard Support
For cases where a single Repeater needs to handle multiple domains and subdomains, you can specify wildcards (*) in the hostname. For example: *.brightsec.com.

Format
--cert '{"hostname": "example.com", "path": "./example.pem", "passphrase": "pa$$word", "port": "8443"}'

Single Certificate
bright-cli repeater --cert '{"path": "/home/user/example.pfx", "hostname": "*.example.com", "passphrase": "pa$$word"}'

Multiple Certificates for Different Ports
bright-cli repeater --insecure --cert '{"path": "/path/to/example1.pfx", "hostname": "\*.example1.com", "passphrase": "password", "port": "8443"}' --cert '{"path": "/path/to/example2.pfx", "hostname": "\*.example2.com", "passphrase": "password", "port": "8444"}'

Multiple Certificates for Different Hosts
bright-cli repeater --cert '{"path": "/certs/api.pfx", "hostname": "api.internal.com", "passphrase": "secret123"}' --cert '{"path": "/certs/web.pfx", "hostname": "web.internal.com", "passphrase": "secret456"}'

--ntlm

Configure experimental support for TCP connections reuse.