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"
}
}
],