Elegir, instalar y verificar Sophos Linux Sensor

Sophos Linux Sensor (SLS) recoge eventos de ejecución Linux y los procesa con Detection Content para generar alertas o respuestas configuradas. Puede integrarse con la infraestructura existente de registros y alertas. SLS es un sensor independiente: no es Sophos Protection for Linux (SPL), su XDR Sensor ni una política SPL de detección en ejecución.

Para un primer piloto se verifican plataforma y derecho, se elige el método y se despliegan sensor y contenido. Después se sigue una alerta de prueba hasta el destinatario realmente previsto. Un servicio activo no basta. Esta guía describe la instalación directa en un host systemd; contenedores y Kubernetes utilizan otro método de despliegue.

Aclarar licencia y modelo operativo

Las instrucciones Sophos verificadas el 27 de octubre de 2026 enumeran Sophos XDR Powered by Secureworks (Server), Sophos MDR (Server) o Sophos MDR Plus (Server) para acceder a SLS. Las licencias de evaluación no son válidas. Una licencia endpoint cualquiera o la mera existencia de un servidor Linux no demuestra ese derecho.

SLS se licencia por dispositivo. Sin embargo, según Sophos, sus instancias no aparecen en la lista de servidores Fusion ni en la vista Devices o su contador de licencias. Por eso se mantiene un inventario separado de sensores instalados. Fusion puede recibir detalles de detección y alertas SLS, pero no administra el sensor. La ausencia de una entrada de servidor SLS no equivale a un registro SPL fallido.

Para un agente de servidor gestionado convencional con los componentes SPL necesarios se utiliza Sophos Protection for Linux. SLS se evalúa por separado para imágenes inmutables o plataformas especiales de contenedores; mencionar ese uso no autoriza todas las combinaciones de distribución, kernel y runtime.

Preparar plataforma y piloto

En la fecha de revisión, las notas SLS exigen al menos 2 GB de espacio libre en disco, 2 GB de memoria libre y x86_64 o ARM64. ARM64 requiere kernel 5.3 o posterior. La distribución concreta, versión menor actual y kernel en ejecución deben coincidir además con la lista de plataformas probadas. El kernel mínimo de otra distribución no es una aprobación universal. Las plataformas legacy tienen condiciones de soporte separadas.

Antes del piloto se registran función del host, distribución, arquitectura, kernel, protección existente, perfil de carga y destinatario de alertas. La instalación directa necesita permisos root/gestión de paquetes, un sistema systemd adecuado y el subsistema de depuración Linux requerido disponible o autorizado. No se debilita preventivamente un sistema endurecido para que avance un script.

Sophos ofrece un método Helm específico para Kubernetes; Docker, CRI-O y containerd también tienen instrucciones propias. Se revisan acceso al registro, visibilidad del host, permisos, imagen de contenido y runtime. Una orden de paquetes de este ejemplo no se traslada sin cambios a un contenedor del sensor.

Preparar el token de registro en el tenant correcto

SLS utiliza un Package Registry API Token independiente que empieza por SLS-. No es el access token OAuth temporal ni el Client Secret de una identidad API.

El procedimiento SLS actual requiere un Super Admin en el panel Fusion Admin del cliente, no en el de Partner o Enterprise. En Global Settings > Administration > API Credentials Management > Add Credential se crea la identidad necesaria con Service Principal Super Admin. El responsable autoriza previamente este amplio requisito del fabricante; no se convierte en el rol estándar de cualquier proyecto API. Client ID y Client Secret, que solo se muestra una vez, se guardan de forma segura.

El proceso de credenciales API y OAuth permite obtener el bearer token e identificar el ID único del tenant cliente con whoami/v1. En este proceso, idType debe confirmar el tenant cliente. Un identificador de partner no sirve. Después se realiza un POST a /accounts/v1/access-tokens en el host API global Sophos, con autenticación Bearer, X-Tenant-ID y este JSON:

{
  "label": "SLS Pilot",
  "type": "sophosLinuxSensor"
}

label es un nombre administrativo libre; type es el valor API fijo. Se utiliza el campo token de la respuesta para el registro, no el ID del objeto. El expiresAt opcional se elige según el plan de acceso; Sophos indica que una fecha posterior al vencimiento de la licencia de servidor se reduce a ese vencimiento. Una fecha lejana de ejemplo no demuestra un derecho permanente.

Se verifican estado y contenido de la respuesta HTTP. Tokens y secretos no deben aparecer en historial shell, diagnósticos proxy, tickets o capturas. Los errores de tenant, derecho o token se aclaran primero; no se cambian a ciegas protecciones o permisos de todo el tenant.

Instalar en el host mediante paquetes

Primero se prepara el acceso al registro SLS en la gestión de paquetes autorizada. Sophos documenta packages.sophos.com/sophos-linux-sensor/release/ y la clave sophos-linux-sensor-archive-keyring.gpg. Se obtiene mediante la vía autenticada del fabricante y se guarda en /etc/sophos-linux-sensor.gpg. Antes de usarla se verifican procedencia y fingerprint actual mediante la cadena de confianza aprobada. gpg --list-packets solo muestra un paquete de clave legible; no demuestra por sí solo una procedencia fiable.

Hosts Debian compatibles

Se añade la fuente a un archivo .list adecuado en /etc/apt/sources.list.d/:

deb [signed-by=/etc/sophos-linux-sensor.gpg] https://packages.sophos.com/sophos-linux-sensor/release/ stable main

El token asociado se guarda en un archivo .conf de acceso restringido en /etc/apt/auth.conf.d/:

machine packages.sophos.com login <SLS-REGISTRY-TOKEN>

Se sustituye el marcador por el token recibido. Solo los procesos privilegiados necesarios de gestión de paquetes deben poder leer el archivo; no se añade el token también a la URL del repositorio. Tras comprobar confianza de firma, origen y permisos del archivo, se ejecuta en la ventana autorizada:

sudo apt-get update
sudo apt-get install sophoslinuxsensor-systemd sophoslinuxcontent

Hosts RPM compatibles

El método RPM usa un archivo .repo separado en /etc/yum.repos.d/. Los nombres de sección y visualización siguientes son ejemplos libres; URL, comprobación de firma y ruta de clave corresponden al método documentado:

[sls]
name=Sophos Linux Sensor
baseurl=https://<SLS-REGISTRY-TOKEN>@packages.sophos.com/sophos-linux-sensor/release/
gpgcheck=1
enabled=1
gpgkey=file:///etc/sophos-linux-sensor.gpg

Se sustituye el marcador por el token recibido. El archivo que lo contiene tiene acceso restringido. Su URL no debe exponerse en registros diagnósticos, tickets o capturas. No se sustituyen repositorios existentes ni se deshabilitan comprobaciones de firma. El nombre visible no autoriza una distribución o versión concreta.

Con el origen configurado correctamente, Sophos indica estos paquetes:

sudo yum install sophoslinuxsensor-systemd sophoslinuxcontent

Se usa solo el método apropiado para la distribución realmente compatible. Sensor y contenido son necesarios. Zero policies configured indica que la aceptación de la detección no se ha superado, aunque el proceso funcione. Las versiones antiguas en las salidas de ejemplo del fabricante no son requisitos actuales de instalación.

Configurar tenant y salida de alertas

En /etc/sophos/runtimedetections.yaml se establece customer_id con el tenant comprobado. Se completan los ajustes YAML de forma selectiva, sin sobrescribir todo el archivo con un ejemplo. Antes de iniciar se verifica la finalidad y autorización de los datos de telemetría y destinos de alerta. Sophos describe salida a stdout por defecto; no conecta automáticamente todos los destinatarios deseados.

Para la comprobación inicial se documenta el destino real: journal local, sistema de registros existente o destinatario Sophos configurado expresamente. Credenciales, destino y formato se ajustan a esa salida. Registrar un token no prueba el reenvío de alertas.

En el host systemd directo se inicia y verifica:

sudo systemctl start sophoslinuxsensor
sudo systemctl status sophoslinuxsensor
sudo journalctl -u sophoslinuxsensor

Si falla el inicio se revisan primero plataforma, paquetes, YAML efectivo y permisos indicados en el journal. La instalación del fabricante describe las Linux Capabilities necesarias; no se sustituyen por contenedores indiscriminadamente privilegiados o un setcap no verificado sobre archivos arbitrarios.

Validar la detección hasta el destinatario

Con Default Content instalado y el sensor activo puede generarse la alerta documentada en un piloto autorizado. Primero se comprueba la sintaxis para la versión instalada: la instalación muestra en un punto -test-alert, mientras que la guía específica usa --test-alert. La orden siguiente solo se usa si esa versión admite esta forma:

sophoslinuxsensor --test-alert

La prueba genera deliberadamente un evento. Se coordina con el equipo receptor y no se ejecuta a escondidas en producción. Se espera Alert Tester en el destino configurado. Host, hora y destinatario deben coincidir; ejecutar correctamente la orden o ver un registro local no confirma entrega remota.

Si la sintaxis no es compatible o falta la alerta, no se sustituye por código malicioso real o un ataque incontrolado.

La aceptación documenta como mínimo versiones de sensor/contenido, reglas efectivas, inicio sin errores, alerta de prueba y recepción real. Confirma esa ruta, no todas las detecciones, cargas o derechos a investigación MDR. Se comparan la carga adicional del piloto y las aplicaciones con la situación inicial.

Reglas, actualizaciones y problemas operativos

El contenido estándar reside en /var/lib/sophos/content/runtimedetections-content.yaml y se sobrescribe durante las actualizaciones. Los cambios van en /etc/sophos/runtimedetections-rules.yaml, no directamente en el archivo del fabricante. Según la documentación de detección, Sophos soporta el contenido estándar sin modificar; la ayuda para reglas modificadas o propias se aclara por separado.

Core y Enhanced difieren en profundidad e impacto de carga. Más contenido no es automáticamente mejor para cualquier servidor sin un piloto. Sensor y contenido se actualizan por el despliegue de paquetes o contenedores correspondiente y se validan de nuevo; comprobar la instalación una vez no sustituye la operación de actualizaciones.

Si faltan alertas, se investigan por separado contenido, reglas cargadas, evento, salida y reenvío. Recoger datos de soporte SLS de forma segura explica registros y diagnósticos, incluidos los métodos distintos de Helm, Docker y host. Una retirada planificada usa valores iniciales documentados, protección restante y procedimiento de desinstalación pertinente. No se borran servicios o credenciales de otros hosts.