HomeDocumentationAPI Reference
Log In
Documentation

Special Case Server Configurations

This section contains special case settings for the server's JSON configuration file (sandfly-setup/setup/setup_data/config.server.json) which can be used if needed on a per setting basis.

Postgres Pool Sizes

Postgres pool_size, pool_size_nodes, and result_workers properties are available under server.db.postgres. For all but the largest and/or complex installations, the default values are expected to be sufficient. If you experience database performance issues we recommend contacting Sandfly Support before changing any of these values.

  • pool_size - for all interactive and API tasks, including user activity on the UI and Splunk data ingestion.
    • Default is 20, minimum is 20, maximum is 500.
  • pool_size_nodes - for API calls that the nodes make in order to insert results and add/update hosts.
    • Default is 30, minimum is 20, maximum is 500.
  • result_workers - for the quantity of ingestion threads that can run simultaneously.
    • Default is 20, minimum is 10, maximum is 500.
    • NOTE: If pool_size_nodes is less than 10 more than result_workers, it will automatically be adjusted to be result_workers+10.

Example of all three properties in a snippet of a config.server.json file:

                "db": {
                        "postgres": {
                                ...
                                "pool_size": 20,
                                "pool_size_nodes": 30,
                                "result_workers": 20,
                                ...
                        }
                },

To complete a change in these values Sandfly will need to be stopped then started via the provided scripts after the JSON file was updated and saved. Container restarts will not reload the changed configuration file.

# ~/sandfly-setup/start_scripts/shutdown_sandfly.sh

# ~/sandfly-setup/start_scripts/start_sandfly.sh

TLS Policies

By default, the Sandfly server restricts TLS connections to TLS 1.3 cipher suites and a small handful of TLS 1.2 ciphers that SSLLabs does not flag as potentially weak:

  • tls.TLS_AES_128_GCM_SHA256, // TLS 1.3
  • tls.TLS_AES_256_GCM_SHA384, // TLS 1.3
  • tls.TLS_CHACHA20_POLY1305_SHA256, // TLS 1.3
  • sandfly-servertls.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, // TLS 1.2
  • tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, // TLS 1.2
  • tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, // TLS 1.2

For compatibility with Internet Explorer on Windows 7 and 8, Sandfly also leaves the following TLS 1.2 cipher enabled:

  • tls.TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

However, some users may need to access the Sandfly API (or have particularly outdated desktop browser TLS support) from older systems that do not support TLS 1.3 and do not include elliptic curve ciphers in their TLS 1.2 support.

In those cases, there is a disable_strict_tls_policy server configuration option which allows the Sandfly server to use the default Go TLS cipher suite instead of Sandfly's restricted set.

Example of disabling the strict TLS policy in the config.server.json file:

                "options": {
                        "log_level": "info",
                        "disable_strict_tls_policy": true
                }

To complete this change, the sandfly-server container will need to be stopped and restarted after the JSON file was updated and saved. A container restart will not reload the changed configuration file.

# docker stop sandfly-server
sandfly-server

# ~/sandfly-setup/start_scripts/start_server.sh
sandfly-server
cc834e81f32f76afc8ff364d50e643eaf2a825b76a14bab72bac26ecfacbc278

Updated 2 months ago