Skip to content

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

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:

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

  2. 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 and sophos-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.

  3. Pull the latest SLS image from the registry.

    docker pull registry.sophosupd.com/release/sophos-linux-sensor:<SENSOR_VERSION_TAG>

  4. Pull the latest SLS content from the registry.

    docker pull registry.sophosupd.com/release/sophos-linux-content:<CONTENT_VERSION_TAG>

  5. 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:

  1. On the host, create the SLS configuration file.

    You must replace {tenant-id} with your unique Sophos Central ID.

    mkdir -p /etc/sophos
echo "send_labs_telemetry: true
endpoint_telemetry_enabled: true
cloud_meta: auto
# 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 to false.

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

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

  4. 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 \
-v /var/run/containerd:/var/run/containerd:rw \
-v /var/run/crio:/var/run/crio:rw \
--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:

  1. Confirm the container is running.

    docker ps

  2. Look for an SLS container and confirm that its STATUS column contains Up.

  3. Copy the CONTAINER ID for the next step.

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

  5. 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 runtimedetections.yaml configured to send alerts to stdout with the name of the policy triggered:

    alert_output:
  outputs:
  - type: stdout
    enabled: true
    template: 'Alert Triggered: {{ .StrategyName}}'"

    Here's the alert output:

    docker logs <containerID>
...
Alert triggered: Suspicious Interactive Shell

    Tip

    You can configure additional fields to get more information about a detection in the output. See the following:

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"