Skip to content
Last update: 2022-06-08

Getting Started with Automated Response

Summary

Introduction to setting up automated response actions.

Overview

In order to provide customers with resilient defense mechanisms,Sophos Linux Sensor (SLS) Policies can be configured with the ability to dynamically respond to attacks in real-time, effectively disrupting exploitation and preventing damage to your production environment.

For policies covering program behavior, a response action can suspend or kill the offending process. For policies covering containers, a response action can kill the container associated with the alert. For policies covering file activity, a response action can quarantine or delete the file associated with the alert. Response actions are not available for every policy type. At this time, only one response action per individual policy is supported.

Response actions are set through the policy's responseActions sub-key. When SLS produces an alert where a response action was taken, the alert's notifications field will include a new alert notification whose message_fields detail the response action taken and the status of the response action. We highly recommend testing response actions before enabling them by performing dry runs.

Prerequisites

In order to enable response actions, SLS must be run in the host's process namespace. If you are running SLS outside a container, no further steps are necessary to enable response actions. Inside a container that is not running in the host's process namespace, not all response actions work or will be available.

Docker

Set --pid="host" in your docker run command when starting the SLS container.

See the complete Docker Run Command documentation for more information on the --pid flag.

Docker Compose

Set pid: "host" in your Docker Compose file. The following incomplete Docker Compose file illustrates how to set this value:

version: "3.7"
services:
  sophoslinuxsensor:
    pid: "host"

See the complete Docker Compose documentation for more information on the pid setting.

Dry runs

Before enabling automated response, we recommend enabling dry runs to become comfortable with how response actions would impact your environment. For any policy supporting response actions, specify dryRun: true in its configuration to enable dry runs.

The following example demonstrates this applied to a Program Policy:

Enforced Wget Blocklist:
  policy: program
  responseActions:
  - kill
  - alert
  dryRun: true
  alertMessage: Unauthorized execution of wget
  comments: This policy detects and kills instances of wget running
  priority: High
  enabled: true
  rules:
  - match programName == "/usr/bin/wget"
  - default ignore

The following JSON is a truncated example alert demonstrating a successful "dry run" result:

"notifications": [
     {
        "timestamp": "2019-04-17T01:48:37.995942203-04:00",
        "name": "Enforced Wget Blacklist",
        "uuid": "7fe1b7b5-aca0-40e5-a5b8-fc0b6fe55ca9",
        "message": "The program \"/usr/bin/wget\" was executed, which violated the \"Enforced Wget Blacklist\" Program Policy.",
        "message_fields": {}
      },
      {
        "timestamp": "2019-04-17T01:48:37.995942203-04:00",
        "name": "Enforced Wget Blacklist",
        "uuid": "7fe1b7b5-aca0-40e5-a5b8-fc0b6fe55ca9",
        "message": "Would have taken responseAction: kill",
        "message_fields": {
          "action_type": "kill",
          "action_target_type": "process",
          "action_result": "dry run"
        }
      }
     ],
Back to top