Installing Sophos Linux Sensor on Docker
Overview
Sophos Linux Sensor (SLS) is a lightweight agent installed on Linux hosts, collecting events from the hosts to trigger alert generation and automated response. SLS integrates with your existing logging and alerting infrastructure. You can deploy the Sensor wherever you have Linux, in public or private cloud environments, in containers or VMs, in on-premises bare metal hosts, each supporting a large number of kernel versions and Linux distributions.
Sophos maintains an external Docker registry where Docker images of the SLS components are made available to customers. You can run this Docker image in your desired environment to protect the host.
These instructions are an example meant provide an outline for deploying the sensor as a container on a host running Docker. You can use the guidance here to configure the SLS Docker image to run in your environnment.
Requirements
You must meet the following requirements before you can deploy the SLS docker image in your environment.
-
Docker is installed and running.
- We recommend having a good understanding of Docker before following this guide.
-
Get
{LINUX_REPO_API_KEY}
and{tenant-id}
by following How to generate the Sophos Linux Sensor package repository API token.{LINUX_REPO_API_KEY}
is a short string that starts with "SLS-".-
{tenant-id}
is a string in the following format:1a2345b6-78c9-012d-ef34-5a6b789c0de1
-
Kubernetes isn't in use. If it is, see Installing SLS on Kubernetes.
Pull the Docker images
There are two images published to the registry that you must pull:
sophos-linux-sensor:<SENSOR_VERSION_TAG>
: Sophos Linux Sensor packaged as a container image.sophos-linux-content:<CONTENT_VERSION_TAG>
: The default content publised by Sophos Labs.
To pull the most recent Docker images, do as follows:
-
Log into the Sophos Docker registry, replacing
{LINUX_REPO_API_KEY}
with your Sophos package repository API key. Your API key is utilized for authorization and doesn’t require a password. You must enter at least single space for password.docker login registry.sophosupd.com -u {LINUX_REPO_API_KEY} -p {LINUX_REPO_API_KEY}
Here's an example:
# docker login registry.sophosupd.com -u SLS-################ -p SLS-################ Password: WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded
Note
The warning message in this example is based on Docker configuration. We recommend following Docker best practices by configuring credential storage so that your API key and password are not stored in plain text in the Docker config file. See Credentials store.
-
Pull the available tags for the SLS and default content images.
curl -u {LINUX_REPO_API_KEY}:{LINUX_REPO_API_KEY} -X GET https://registry.sophosupd.com/v2/release/sophos-linux-sensor/tags/list |jq '.tags'
curl -u {LINUX_REPO_API_KEY}:{LINUX_REPO_API_KEY} -X GET https://registry.sophosupd.com/v2/release/sophos-linux-content/tags/list |jq '.tags'
Tip
Note the most recent version tags for both
sophos-linux-sensor
andsophos-linux-content
. You will need these tags for most of the following steps to replace the<SENSOR_VERSION_TAG>
and<CONTENT_VERSION_TAG>
placeholders. If you're not sure, you can find the latest SLS version in the Release notes. See Release notes. -
Pull the latest SLS image from the registry.
docker pull registry.sophosupd.com/release/sophos-linux-sensor:<SENSOR_VERSION_TAG>
-
Pull the latest SLS content from the registry.
docker pull registry.sophosupd.com/release/sophos-linux-content:<CONTENT_VERSION_TAG>
-
Verify you have the latest images on the host.
docker image ls
Here's an example:
# docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE registry.sophosupd.com/sophos-linux-sensor 5.5.0.398 4d09482d2962 7 days ago 108MB registry.sophosupd.com/sophos-linux-sensor 5.5.0.384 a624cf037647 7 days ago 108MB registry.sophosupd.com/sophos-linux-content 5.4.1.241 ff3d9894434e 7 days ago 7.48MB registry.sophosupd.com/sophos-linux-sensor 5.5.0.330 94cf007943af 2 weeks ago 108MB
Deployment
SLS won't do anything if you just run the docker run registry.sophosupd.com/sophos-linux-sensor:<SENSOR_VERSION_TAG>
command. It requires non-default access to the host to protect more than its docker sandbox. There are three files that need to be accessible from mount points when you start SLS.
This example uses the following options:
- Sets the configuration file location to
/etc/sophos/runtimedetections.yaml
. You can place this in any location, as long as you change the host's mount point in any following commands. - Sets the content path to
/tmp/sophos-content
. You can point this to any location, as long as you change the host's mount point in any following commands. - Sends alerts to
stdout
. You can change the alert options to suit your monitoring strategy. See Exporting Alerts.
To deploy SLS as a container, do as follows:
-
On the host, create the SLS configuration file, replacing {tenant-id} with your unique Sophos Central ID.
mkdir -p /etc/sophos echo "send_labs_telemetry: true # Set your customer id: customer_id: "{tenant-id}" alert_output: outputs: - type: stdout enabled: true template: 'Alert Triggered: {{ .StrategyName}}'" > /etc/sophos/runtimedetections.yaml
Note
If you don't want to send telemetry data to Sophos, set
send_labs_telemetry
tofalse
. -
Check that the
/tmp/sophos-content
path exists. If it does, skip the next step. If not, create it with the following command:mkdir -p /tmp/sophos-content
-
Add the Sophos Labs default content file.
Warning
If
/tmp/sophos-content/runtimedetections-content.yaml
already exists, running the following command will overwrite it.docker run --user "$(id -u):$(id -g)" \ -v /tmp/sophos-content:/var/lib/sophos/content:rw \ registry.sophosupd.com/release/sophos-linux-content:<CONTENT_VERSION_TAG>
You now see a file named runtimedetections-content.yaml under /tmp/sophos-content.
-
Optional: Create /etc/sophos/runtimedetections-rules.yaml if there are updates you want to apply to the default content. See Managing Enabled Content
Run the Sensor container
On the host, run the following command:
docker run \
--pid=host \
--privileged \
--user=0 \
--detach \
-v /etc/sophos:/etc/sophos:rw \
-v /tmp/sophos-content:/var/lib/sophos/content:rw \
-v /tmp/sophos-log:/var/log/sophos-log:rw \
-v /sys/fs/cgroup:/var/run/sophos/mnt/sys/fs/cgroup:ro \
-v /sys/kernel/debug:/var/run/sophos/mnt/sys/kernel/debug:rw \
-v /etc/hostname:/var/run/sophos/mnt/hostname:ro \
-v /proc:/var/run/sophos/mnt/proc:ro \
-v /var/lib/docker:/var/lib/docker:ro \
-v /var/run/docker:/var/run/docker:ro \
--cap-add SYS_ADMIN --cap-add SETUID --cap-add SETGID --cap-add SETPCAP \
--cap-add SYS_PTRACE --cap-add KILL --cap-add DAC_OVERRIDE --cap-add IPC_LOCK \
--cap-add FOWNER --cap-add CHOWN --cap-add SYSLOG \
--cap-add NET_RAW --cap-add SYS_RESOURCE \
registry.sophosupd.com/release/sophos-linux-sensor:<SENSOR_VERSION_TAG>
Confirm Sensor Functionality
Suspicious Interactive Shell
SLS content from the container defaults to a set of protections that include the "Suspicious Interactive Shell" detection. We'll use this to confirm that the sensor can detect activity on the host. To confirm Sensor functionality, do as follows:
-
Confirm the container is running.
docker ps
-
Look for a SLS container and confirm that its STATUS column contains Up.
- Copy the CONTAINER ID for the next step.
-
Confirm SLS is running in the container.
docker logs <containerID>
A typical SLS startup will end with the line "Analytics started processing telemetry".
Note
If you see "Zero policies configured" it means that the sensor doesn't have any enabled detection rules. It's likely that SLS is not loading content policies. Contact Sophos technical support to resolve the issue.
-
Run the following command:
/bin/sh -i exit
This command triggers the Suspicious Interactive Shell detection. If the Sensor is configured correctly, it will report the activity.
The
runtimedetections.yaml
file in this example contains a "stdout" alert output type with a custom template, allowing us to check the logs to see the alert that was triggered. If you've customized your alert outputs, you may have to look elsewhere. See Getting Started: Exporting Alerts.Here's an example:
docker logs <containerID> ... Alert triggered: Suspicious Interactive Shell
Confirm configuration files
If you are using runtimedetections-rules.yaml
to adjust individual detections, you can confirm that SLS is using the file with the docker logs
command. You'll see similar output as you would when running as a host process.
Here's an example:
2023-05-16T17:14:37.227Z INFO using sensor configuration file "/etc/sophos/runtimedetections.yaml"
2023-05-16T17:14:37.227Z INFO using analytics strategy file "/etc/sophos/runtimedetections-rules.yaml"
2023-05-16T17:14:37.227Z INFO fetching metadata
2023-05-16T17:14:37.228Z INFO fetched metadata
2023-05-16T17:14:37.228Z ERROR File permissions on runtimedetections YAML file are world-accessible, proceeding anyway
2023-05-16T17:14:37.228Z INFO using sensor configuration file "/etc/sophos/runtimedetections.yaml"
2023-05-16T17:14:37.228Z INFO using analytics strategy file "/etc/sophos/runtimedetections-rules.yaml"