Response Actions

Response Actions let you execute response actions from the Events feed. This can be preferable to Threat Detection Policy Actions, because you can personally assess an event for false positives before you act.

Prerequisites

To perform Response Actions, you need:

A role with Response Actions permissions. Contained by default in Admin, Advanced User, and Team Manager. See Role management. The required permissions are:
- Containment Response Actions: READ, EXEC.
- Data Gathering Response Actions: READ, EXEC.
Sysdig Shield installed and configured. For more installation instructions, see:

Configuration

To enable or disable Response Actions you can modify the dedicated flag.

Shield Chart (Kubernetes), in values.yaml
Shield Chart (Linux Host) as a container, in ADDITIONAL_CONF environment variable
Host Shield (Linux Host) as a package, in dragent.yaml

features:
  respond:
    response_actions:
      # Enable Response Actions
      enabled: true/false

On the Shield Chart (Kubernetes), alternatively, as a Helm command argument:

--set features.respond.response_actions.enabled=true/false

Each action can be customized individually. The following sections address the available actions along with their specific configuration. Overall, it’s also possible to disable them selectively:

features:
  respond:
    response_actions:
      <action_name>:
        trigger: NONE # Set this to disable the action. Default: ALL

Along with the action being deactivated, if the Shield is installed through the Chart-based installation, the permissions and facilities for the action will not be provisioned, following the principle of least priviledge.

Additional global configurations:

Parameter	Description	Default
`docker.socket_path`	File paths that Sysdig checks for the Docker/Podman socket	`["/var/run/docker.sock", "/run/podman/podman.sock", "/run///podman/podman.sock"]`
`cri.socket_path`	File paths that Sysdig checks for the CRI socket for Containerd/CRI-O	`["/run//containerd.sock", "/var/run//containerd.sock", "/run//dockershim.sock", "/var/run//dockershim.sock", "/run//crio.sock", "/var/run//crio.sock"]`

Execute a Response Action

To execute a response action from an event in the Events feed:

Log in to Sysdig Secure.
Select Threats > Activity | Events.
Open an event happening on a Kubernetes, Host or Container workload.
Select Respond.
- Optional: Select Ask for Response Advice to open Sysdig Sage. Sage will suggest remediation actions based on your current context.
If a response action is available for you on that host, select Run Response Action to see the actions available for that context, as well as the last executed action, if any.
After you select an action, you can review the parameters.
To execute the action, select Run Action.
After the action executes, a message appears reporting the status and, in case of an error, the reason.

Container Kill

Type	Containment
Reverse Action	N/A
Requirements	Agent version 13.9 or higher

The Container Kill action instantly terminates the container, along with all of its process, without waiting for them to shut down. This can stop a malicious activity quickly, but can result in data loss (in stateful applications) and service disruption. It is the best choice for containing severe and urgent threats.

If the container is orchestrated with Kubernetes, the control plane will typically attempt to restart the container based on its configuration.

Drawbacks: Any possible forensic data will be lost. Possible service disruption, in cases where there’s no container orchestration or it’s not working as expected.

Container Stop

Type	Containment
Reverse Action	Container Start
Requirements	Agent version 13.9 or higher

Container Stop gracefully terminates the container with its processes, deleting the memory state and the file system upper layer. It’s best for stateful applications.

If the container is orchestrated with Kubernetes and it has a liveness probe defined, the control plane will restart the pod as soon as the liveness probe fails. If no liveness prove is defined, Kubernetes will restart the container based on the restartPolicy. By default, the behavior is to restart terminated containers. In case of Kubernetes environments, this action cannot be reverted, i.e. containers cannot be restarted directly.

On non-orchestrated environments, or when the control plane doesn’t restart the container, you can start the container again from Sysdig. Follow the steps in the Revert a Response Action section to understand how to do it.

Drawbacks: Possible service disruption, in cases where there’s no container orchestration or it’s not working as expected.

Container Pause

Type	Containment
Reverse Action	Container Unpause
Requirements	Agent version 13.9 or higher

Container Pause suspends the execution of a container, freezing its processes and preserving its runtime state. The container memory state disk state are maintained. This is ideal for forensic analysis and limiting disruption, but may result in higher resource consumption and prolonged risk due to lack of resolution.

If the container is orchestrated with Kubernetes and the pod’s liveness probe will start failing, it will be restarted, making this have the same effect of a Container Stop action.

In other cases, the execution will be temporarily stopped until further actions are taken. You can start the container again by reverting the action

Drawbacks: Possible service disruption, in cases where there’s no container orchestration or it’s not working as expected.

Process Kill

Type	Containment
Reverse Action	N/A
Requirements	Agent version 13.9 or higher

The Process Kill action sends a SIGKILL signal to the process, causing it to terminate instantly.

When you execute this action from an event, you can decide to kill the process that originated the event itself or any of the processes in its ancestor line.

Drawbacks: Possible service disruption, when the process is in charge of executing business critical applications without orchestrations/watchdog mechanisms.

File Quarantine

Type	Containment
Reverse Action	File Restore
Requirements	Agent version 13.9 or higher Write permissions on the target file and the sandbox folder

File Quarantine is a Response Action you can use to isolate a suspicious or vulnerable file, so that it cannot be executed and can be accessed later for further investigations.

This action compresses the file, to make it non-executable, and moves it inside a quarantine folder. Optional: To change the default quarantine folder, see Configure File Quarantine.

As an example, this action can be useful if you see an Event warning you about a process receiving an unexpected connection. You can use the File Quarantine action to move the executable elsewhere and make it non-executable. Later, you can inspect the file in its safe new location.

This action can be reverted, moving the file back to its original location. To do this, see Revert a Response Action.

Drawbacks: If the action is performed on a business critical application executable, this can cause possible service disruptions.

Configure File Quarantine

In order to perform the File Quarantine action, Sysdig needs write access to the source file and the quarantine folder. You can customize the quarantine folder path by editing the configuration:

features:
  respond:
    response_actions:
      file_quarantine:
        quarantine_path: "/var/lib/sysdig/quarantine"

Alternatively, you can grant the write permission on that folder.

With regards to the source file, Sysdig permissions change based on the different Shield setup:

Shield chart: Sysdig has full write access to the root file system when response actions is enabled
Package setup: The Shield package defines SystemD directives required to apply the principle of least privilege. This means that, by default, some files cannot be quarantined. This behavior can be customized. Learn how in the next section.

Parameter	Description	Default
`file_quarantine.max_file_size_mb`	Maximum file size that Sysdig is allowed to quarantine (in MB)	50
`file_quarantine.quarantine_path`	Quarantine folder path, where quarantined files are moved into	`/var/lib/sysdig/quarantine`

Linux package Host Shield - customize read only path

By default, the Linux Host agent is not allowed to write in the following folders:

/home
/root
/run/user
/usr
/boot
/efi
/etc

This configuration is managed using systemd’s Unit configuration:

ProtectHome=read-only
ProtectSystem=full

ProtectHome manages the access to /home, /root and /run/user.
ProtectSystem manages the access to /usr, /boot, /efi and /etc.

To perform File Quarantine on files in those directories, the agent needs write permission.

To grant the agent write permission to these folders:

Edit the dragent configuration by writing this command on your terminal: sudo systemctl edit dragent.
An editable file to configure the dragent systemd configuration appears.
Define or edit the ProtectHome and ProtectSystem directives. To grant the agent full write permissions, change them to:

[Service]
ProtectHome=no
ProtectSystem=no

Run the following commands to restart the agent and systemd:

sudo systemctl daemon-reexec
sudo systemctl restart dragent

Troubleshoot File Quarantine

If you receive an error message, such as failed to remove quarantined file or file system mounted as read-only, the file may be in a folder the agent does not have permission to perform write actions in. The File Quarantine action requires write permissions on the target file and on the quarantine folder path.

Verify the instructions for customizing the quarantine folder path and the write permissions in the Configuration section

File Acquire

Type	Data Gathering
Reverse Action	N/A
Requirements	Agent version 13.9 or higher Custom Storage configured

The File Acquire action allows you to fetch a file from a workload. This can be useful to:

Download suspicious executable files for further examining them
Access log files to analyze the system activities and trace user actions
Check for modifications performed by actors to understand if they are malicious

Drawbacks: whoever is entitled to execute this action will be able to pull data from workloads, if the Sysdig agent has such a permissions.

Configure File Acquire

In order to acquire a file, you need to setup a Custom Storage, where the file is uploaded from the workload. See how to do it in the dedicated page.

File Acquire also supports limiting the maximum file size to acquire, to avoid excessive resource usage.

Parameter	Description	Default
`file_acquire.max_file_size_mb`	Maximum file size that Sysdig is allowed to acquire (in MB)	50

Download an acquired file

Once you terminate a File Acquire action with success, you will see the execution in the Response History. In the case of successful File Acquire actions, you will also be able to download the file from the context menu or from the execution details.

See Previous Executions

To view the history of response actions:

Log in to Sysdig Secure.
Select Threats > Activity | Events.
Open an event happening on a Kubernetes, Host or Container workload.
The Event Details panel appears.
In the Response History section, you can see response actions previously taken in that context. For example, container actions targeting the same host or cluster. Each row in the section represents an execution request sent to the agent.
The actions displayed are limited by the time frame of currently applied to the Events page. See Change Time Span to expand or reduce it.
By using the “View Detail” contextual action, you can see the action parameters:
- Metadata, containing the execution status and the execution timestamp
- Inputs, showing the action target information
- Configuration, having details about the setup when that action was run

Revert a Response Action

When you’re looking at the execution of a Response Action that can be reverted in the Response History, you will see the possibility to execute the reciprocal revert action from the context menu in the Response History and from the execution details.

From the Response History:

From the execution details:

Once you select that, you will be prompted to review the parameters, like with normal executions.

Upon submission, the revert action will trigger, trying to revert the previous action execution.

You will be able to see the outcome of that action and the details as for any other action.

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.