Agent Configuration for Secure

Configure Malware Control

Malware Control, which is comprised of Malware Detection and Prevention, is enabled by default for containers. Malware Detection is enabled by default for hosts, but Malware Prevention is disabled by default for hosts.

You can configure the agent to:

• Enable or disable Malware Control for both hosts and containers.
• Enable or disable Malware Prevention for hosts.

To configure the agent, see Understand the Agent Configuration.

Prerequisites

• Sysdig Agent v13.0.1 and above
• Linux kernel v5.0 and above

Enable or Disable Malware Control

To enable Malware Control for hosts and containers, use this configuration:

agent:
  sysdig:
    settings:
      malware_control:
        enabled: true

Alternatively, use the following Helm command:

--set agent.sysdig.settings.malware_control.enabled=true

To disable Malware Control for hosts and containers, use this configuration:

agent:
  sysdig:
    settings:
      malware_control:
        enabled: false

Enable or Disable Malware Prevention for Hosts

Malware Prevention, by default, is disabled for Hosts. To enable it, use the following configuration:

protections:
  malware_control:
    enable_prevention_on_host: true

To disable Malware Prevention on hosts, use the following configuration:

protections:
  malware_control:
    enable_prevention_on_host: false

Enable or Disable Malware Detection on Opens and Writes

Malware Detection is enabled for opens and writes by default with the following configuration:

protections:
  malware_control:
    enable_elf_object_malware_scanning: true

To disable Malware Detection on opens and writes, use the following configuration:

protections:
  malware_control:
    enable_elf_object_malware_scanning: false

Configure Container Limits

• For kernel versions below v5.13, Malware can monitor up to 128 containers per node.

• For kernel versions v5.13 or above, modify the container limit using one of the following methods:

  • Open the sysctl -n fs.fanotify.max_user_groups file and set the new value using sysctl -w fs.fanotify.max_user_groups=<new_limit>.

  • Check the current limit using cat /proc/sys/fs/fanotify/max_user_groups file and use echo <new_limit> > /proc/sys/fs/fanotify/max_user_groups to set the new limit.

Configure Drift Control

Sysdig Agent v12.16.0+

Drift Control is enabled by default on agent versions v12.16.0 and later.

Optional Values

Enable detections from mounted/persistent volumes.

Configuration

drift_deny_execution_from_volumes: true

Helm Command

--set agent.sysdig.settings.drift_deny_execution_from_volumes=true

Sysdig Agent v12.14.0

This configuration is deprecated for newer agent versions.

Configuration

Enable Drift

drift_killer:
  enabled: true

Disable Drift

drift_killer:
  enabled: false

Here is an example configuration:

agent:
  ebpf:
    enabled: "true"
    kind: "universal_ebpf"
  sysdig:
    settings:
      enrich_with_process_lineage: "true"
      drift_control:
        enabled: false

Helm Command

 --set agent.sysdig.settings.drift_killer.enabled=true

Configure Container Limits

• For kernel versions below v5.13, Drift Control can monitor up to 128 containers per node.

• For kernel versions v5.13 or above, modify the container limit using one of the following methods:

  • Open the sysctl -n fs.fanotify.max_user_groups file and set the new value using sysctl -w fs.fanotify.max_user_groups=<new_limit>.

  • Open the cat /proc/sys/fs/fanotify/max_user_groups file and run echo <new_limit> > /proc/sys/fs/fanotify/max_user_groups.

    Replace <new_limit> with your choice of container limit.

Configure Falco Rule Matching Strategy

Sysdig agent v.12.18+

From Sysdig agent v12.18.0+, the agent evaluates an event against all the rules, potentially triggering multiple alerts. In previous versions, the agent stopped evaluating rules after the first match.

To control this behavior, a new option has been added to dragent.yaml: security.falco_match_strategy

security:
  falco_match_strategy: all

To evaluate all rules for every event; set it to all. This is the default option.

To stop evaluation after the first match; set it to first.

Report Actions in Kubernetes Events

Sysdig agent v.12.18+

For a full description of the feature, see Threat Detection Policies.

Permissions

• Helm: If you deploy the agent using Helm, the permissions to enable create and patch actions for events on all APIs are automatically granted.

• Manual: If you deploy manually, you must set up a Kubernetes cluster role with those permissions enabled. Example without cluster role binding:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: sysdig-agent
  rules:
  - apiGroups:
    - ""
    resources:
    - events
    verbs:
    - create
    - patch
  

  Example with cluster role binding:

  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRole
  metadata:
    name: sysdig-agent
  rules:
  - apiGroups:
    - ""
    resources:
    - events
    verbs:
    - create
    - patch
  ---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: ClusterRoleBinding
  metadata:
    name: sysdig-agent
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: sysdig-agent
  subjects:
  - kind: ServiceAccount
    name: sysdig-agent
    namespace: sysdig-agent
  ---
  

Ignore Container Actions at the Agent Level

Sysdig agent v12.10+

For Threat Detection policies, you can use the agent-level configuration, ignore_container_action to prevent the Sysdig agent from taking potentially disruptive container operations, such as kill, pause, stop, regardless of the runtime threat detection policy.

This configuration is disabled by default. To enable it, add the following to the dragent.yaml file:

security:  ignore_container_action: true

See Configure the Agent.

When the configuration is enabled, and a policy instructs the agent to perform a container operation, the agent ignores the policy and creates an Info log message explaining the agent did not perform the action because of the configuration.

See Workload Policy for an example of the container action at the policy level.

Configure Response Actions

Response Actions allow you to perform both Containment and Data gathering actions:

• Remotely, from Sysdig, to stop a threat or collect data to support an investigation.
• Automatically, after an event occurs, based on the relevant Threat Detection Policy.

You can configure the agent to:

• Enable/Disable Response Actions
• Customize the actions

To understand how you can configure the classic agent, see Configure Sysdig Linux Agent.

Response Actions requires Agent 13.19.0 or later.

To read more about this feature, see Respond.

Enable or Disable Response Actions

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

Additional configurations

You can further customize and tweak additional parameters for Response Actions. All the different installation methods share the same configuration, defined in YAML format under the path features.respond.response_actions.

File quarantine permissions

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
• Linux Host Shield: 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.

Linux 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:

1. 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.

2. Define or edit the ProtectHome and ProtectSystem directives. To grant the agent full write permissions, change them to:

[Service]
ProtectHome=no
ProtectSystem=no

3. Run the following commands to restart the agent and systemd:

sudo systemctl daemon-reexec
sudo systemctl restart dragent