Response actions allow users with the Responder role to take remediation and investigation steps on hosts that are protected by Sandfly. Responders have the ability to kill or suspend/resume a malicious process, retrieve a suspicious file or process binary, remove unauthorized SSH keys, or de-duplicate multiple copies of SSH keys. Every action is recorded in a log with a full audit trail.

For automatic responses, which is a separate capability, please refer to the Sandfly Auto Response documentation.

In-Application Administration

The UI provides the following feature administration areas for Response Actions:

The Responder Role

The Responder role grants Sandfly user accounts the ability to perform response actions on protected hosts via the UI or API. Users without this role, including admins, can view the response action log but cannot initiate any actions. The Responder role can be assigned by an administrator alongside any existing role.

For general information on administering user accounts, please refer to the Adding Users documentation.

Response File Retention

Retrieved process binaries and files are stored in the Sandfly database and are available for download (by users with the Responder role) from the Response Action Log for a configurable number of days, ranging from 1 to 31, before being automatically purged. The number of days that these files are kept is set in the File Retention value in the Server and Data Retention section of the General Settings. The default retention period is set to 3 days.

For general information on administering the file retention period in the settings, please refer to the General Settings documentation.

Disabling Response Capabilities

In addition to the in-application Responder role to control access to response actions, the Sandfly response capabilities can be disabled server-wide or on nodes. The auto response feature within sandflies is not affected by these configurations.

Disabling Server-Wide

To completely disable response actions, edit the server environment file (sandfly-setup/setup/setup_data/config.server.env) and add the parameter SF_DISABLE_RESPONSES=true. Restart the Sandfly server using the stop and start scripts (a docker restart ... is not sufficient to apply environment changes).

When SF_DISABLE_RESPONSES is set to true, the server will behave as if no users have the Responder role. Regardless of actual roles, no users will be allowed to initiate response actions. Disabling response actions in this way ensures that in-application Sandfly administrators cannot enable responses.

Disabling Per-Node

Response actions can also be disabled at the Sandfly Node level. This allows protection against response actions for some network segments while allowing them in others. To enable this protection, install a Sandfly Node with SSH access to the protected network segment and configure it with a named queue. On the node (or multiple nodes that share the queue name), add the parameter SF_NODE_DISABLE_RESPONSES=true to the sandfly-setup/setup/setup_data/config.node.env file. Ensure in your network firewalls that other Sandfly nodes do not have SSH access to the hosts in the protected network segment. Add the hosts to Sandfly using the new named queue served by nodes with SF_NODE_DISABLE_RESPONSES=true.

When a user (with the Responder role) initiates a response action against a host that is served by a node with responses disabled, the node will receive the order to perform the response, but will send a rejection response back to the server and not take action on the target host. The response action will enter the Response Action Log as a pending entry, but upon execution will change to an error status with a message indicating that the node rejected the request.