Sophos Linux Sensor: recopilar datos de soporte de forma segura

Ante un problema con Sophos Linux Sensor (SLS), se recopilan un archivo de soporte y los registros correspondientes del sensor, preferiblemente mientras se produce el error o inmediatamente después. La recopilación requiere aproximadamente 30 segundos. Primero hay que determinar el tipo de implementación: con Helm, se recopilan los datos por cada nodo afectado; con Docker, en el host Docker; y con una instalación directa, en el host Linux. Tras la señal de depuración, la descarga debe realizarse de inmediato; la ventana temporal de depuración es de 60 segundos.

Esta guía se aplica exclusivamente a Sophos Linux Sensor. SLS no es Sophos Protection for Linux (SPL), ni su XDR Sensor, ni su política de Linux Runtime Detection. Su inclusión en la vista general de servidores sirve para la navegación y no convierte los productos en equivalentes. Para SPL se aplica la guía de instalación y funcionamiento independiente; los siguientes comandos de SLS no deben utilizarse allí.

Comprobar el sistema de destino y la autorización antes de la recopilación

Antes de enviar una señal o reiniciar, se confirma mediante el inventario de la implementación y la instancia en ejecución que el producto afectado es realmente SLS. En el caso de soporte se registran el host o el clúster, el namespace, el pod, el nodo o el contenedor, la versión instalada del sensor y la hora del error con su zona horaria. La información de versión del archivo que se recopile posteriormente complementa esta identificación. Esta guía sigue el procedimiento de soporte actualizado el 5 de octubre de 2026; de ello no se deriva una versión mínima ni una aprobación para todas las versiones anteriores del sensor, Helm, Kubernetes o Docker. Si los nombres o los puertos difieren, o si falta un endpoint de monitorización, primero hay que aclarar con soporte cuál es la implementación real.

Se necesita un directorio de trabajo con acceso protegido y suficiente espacio libre. Los nombres de archivo que se muestran a continuación son relativos a ese directorio; antes de repetir el procedimiento, hay que guardar por separado los paquetes existentes para evitar que se sobrescriban. Limitar el acceso al archivo, los registros y los perfiles a las personas responsables y establecer un plazo de conservación. Para las descargas, las direcciones de monitorización deben seguir siendo locales. No configurar ningún servicio público, Ingress ni puerto de depuración accesible de forma general.

Las herramientas deben estar ya autorizadas y disponibles. Si falta curl en un host Linux con instalación directa, el procedimiento documenta estos comandos de instalación:

# Sistemas basados en Red Hat
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Utilizar únicamente el comando adecuado para la distribución dentro del proceso autorizado de gestión de paquetes. La instalación de un paquete modifica el host; no forma parte de la mera revisión del artículo. Para Helm y Docker también se necesitan tar y gzip. Si faltan las herramientas o los permisos necesarios, detenerse antes de activar la depuración.

Helm: un paquete por cada nodo afectado

En el equipo de administración, kubectl debe estar configurado para el clúster correcto. Los permisos deben permitir enumerar pods, leer sus registros, reenviar sus puertos y añadir un contenedor de depuración efímero. Además, el entorno de ejecución de contenedores debe admitir la selección del namespace de procesos de otro contenedor como destino. En este equipo se necesitan curl, tar y gzip.

El clúster debe poder obtener busybox:latest. Si ese registro no está autorizado, la imagen se replica previamente en un registro autorizado y accesible, y se sustituye únicamente el valor de --image por esa referencia de imagen verificada. No flexibilizar las reglas de seguridad del registro para forzar la recopilación. El contenedor efímero supone un cambio en el pod y requiere la autorización operativa correspondiente.

Seleccionar el pod y mantener abierto el reenvío de puertos

El chart de Helm de SLS proporciona un pod de sensor por cada nodo Linux supervisado. Sustituir <namespace> por el namespace de la instancia de SLS desplegada mediante Helm:

kubectl --namespace <namespace> \
get pods \
--selector app=sophos-linux-sensor \
--output wide

La salida debe vincular el pod del sensor con el nodo afectado. <sensor-pod> es exactamente ese pod y <node-name> es el nombre de su nodo. No utilizar cualquier pod que funcione correctamente de la misma instancia desplegada mediante Helm.

En el primer terminal, reenviar el puerto de monitorización:

kubectl --namespace <namespace> \
port-forward pod/<sensor-pod> 9010:9010

Este terminal debe permanecer abierto hasta que finalice la descarga. Si el puerto local ya está ocupado, detener el procedimiento y aclarar el conflicto en lugar de finalizar un proceso ajeno. No añadir una vinculación a direcciones accesibles públicamente. Si se interrumpe el reenvío, debe volver a estar activo antes de repetir la descarga.

Enviar la señal, descargar de inmediato y añadir los registros

En el segundo terminal, el contenedor de depuración se dirige al contenedor de SLS. El comando envía SIGUSR2 al proceso del sensor; no es una instrucción para finalizar el sensor:

kubectl --namespace <namespace> \
debug pod/<sensor-pod> \
--image=busybox:latest \
--target=sophos-linux-sensor \
--attach=false -- \
pkill -USR2 -f '[s]ophoslinuxsensor'

El patrón de búsqueda [s]ophoslinuxsensor evita que pkill coincida con su propia línea de comandos. Si fallan la descarga de la imagen, los permisos o la selección del proceso de destino, la recopilación no se ha activado de forma fiable. No añadir más contenedores de depuración a ciegas; primero hay que aclarar el mensaje de error.

Inmediatamente después, descargar desde el segundo terminal:

curl --fail --silent --show-error \
--max-time 120 \
http://127.0.0.1:9010/support.tar \
--output sophos-linux-sensor-support-<node-name>.tar

--max-time 120 limita la llamada HTTP, pero no prolonga la ventana de depuración. Después, guardar los registros actuales del mismo contenedor y nodo:

kubectl --namespace <namespace> \
logs pod/<sensor-pod> \
--container sophos-linux-sensor \
--timestamps \
> sophos-linux-sensor-<node-name>.log

Enumerar el contenido sin extraerlo:

tar -tf sophos-linux-sensor-support-<node-name>.tar

Tras comprobar que el archivo está completo, como se describe más abajo, finalizar el reenvío de puertos en el primer terminal con Ctrl+C. Para cada nodo afectado adicional, utilizar su propio pod y un nombre de archivo único.

Docker: comprobar el contenedor en ejecución y el puerto publicado

Todos los comandos siguientes se ejecutan en el host Docker con los permisos de Docker autorizados allí. El contenedor de SLS debe estar en ejecución y su puerto de monitorización debe estar ya publicado en el host. El puerto predeterminado dentro del contenedor es 9010. Deben estar disponibles curl, tar y gzip. Aquí no se indica que se publique un puerto posteriormente ni que se reinicie el contenedor como medida de reparación.

docker ps
docker port <sensor-container> 9010/tcp

<sensor-container> es el nombre o el ID del contenedor de SLS confirmado. La segunda salida indica la dirección y el puerto del host. <host-port> se sustituye por ese puerto, no automáticamente por 9010. La descarga siguiente presupone que la dirección publicada es accesible mediante 127.0.0.1 en este host Docker. Si está vinculada exclusivamente a otra dirección o no hay salida, comprobar primero la implementación; no añadir ningún puerto accesible públicamente.

El siguiente comando modifica el estado de depuración durante 60 segundos. En este contexto, docker kill no debe ejecutarse sin --signal=SIGUSR2:

docker kill --signal=SIGUSR2 <sensor-container>

Inmediatamente después, acceder al endpoint local publicado:

curl --fail --silent --show-error \
http://127.0.0.1:<host-port>/support.tar \
--output sophos-linux-sensor-support.tar

Los registros y la comprobación del archivo forman parte del mismo paquete:

docker logs <sensor-container> \
> sophos-linux-sensor.log 2>&1

tar -tf sophos-linux-sensor-support.tar

El modo de depuración temporal finaliza automáticamente. Una nueva consulta con docker ps debe seguir mostrando el contenedor previsto en ejecución; sin embargo, esto por sí solo no demuestra que la detección funcione.

Host Linux con instalación directa: utilizar el modo de depuración temporal

Esta rama se aplica a SLS ejecutado directamente en el host, no a un contenedor ni a /opt/sophos-spl. Se requieren permisos de root y acceso al puerto local de monitorización. En una instalación con systemd, comprobar previamente con journalctl -u sophoslinuxsensor que el journal corresponde al servicio y al host previstos. Si falta el servicio o hay varias instancias del sensor, aclarar primero su correspondencia.

El comando de host documentado actúa sobre todos los procesos activos del host que coincidan con el patrón sophoslinuxsensor. No limita su alcance a una sola instancia. No ejecutarlo sin autorización para esas instancias o si los nombres de los procesos no están claros.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

Después, el sensor ofrece información de soporte y depuración durante 60 segundos en el endpoint de monitorización. Recopilarla de inmediato en el directorio de trabajo preparado:

curl -O http://localhost:9010/support.tar && gzip support.tar

La recopilación requiere aproximadamente 30 segundos. Tras una compresión correcta, estará disponible support.tar.gz. Esta llamada para el host no incluye ni comprobación de errores HTTP ni límite de tiempo; por tanto, la existencia del archivo o una llamada correcta a gzip no demuestra que el archivo esté completo. Para comprobarlo localmente sin extraer el paquete:

tar -tzf support.tar.gz

Los registros del host se consultan con:

journalctl -u sophoslinuxsensor

Para una observación continua, también se documenta esta llamada:

journalctl -efu sophoslinuxsensor

Finalizar la observación con Ctrl+C y guardar la información del journal necesaria para el periodo del error mediante el método de exportación autorizado. No tratar una salida continua sin límite como un paquete de soporte finalizado.

Comprobar el archivo, acotar el error y entregarlo de forma segura

Un archivo de depuración completo contiene entradas como runtimedetections.yaml, environment.json, goroutine.out y profile.out, además de información de métricas y versiones. Las entradas mencionadas son ejemplos, no una garantía de contenidos idénticos para todas las versiones. tar debe poder listar el contenido del archivo sin errores. Una página de error HTML, un paquete vacío o una descarga interrumpida no son resultados utilizables.

Si el paquete contiene únicamente metrics.txt y version.json, la recopilación de depuración no estaba activa. Comprobar la instancia de destino, los errores al enviar la señal y el intervalo transcurrido. Después, volver a enviar SIGUSR2 en la rama correspondiente al tipo de implementación y descargar de nuevo inmediatamente. En la rama de Helm, el reenvío de puertos debe estar activo durante toda la descarga. Escalar a soporte los fallos repetidos con el mensaje de error exacto, la versión del sensor y la hora del error; no eludirlos mediante un modo de depuración permanente o un puerto de red abierto.

Los archivos, registros y perfiles pueden contener configuración confidencial, variables de entorno e información del host y del entorno de ejecución. Aunque algunas partes de la configuración se oculten automáticamente, el paquete no queda automáticamente anonimizado para su difusión pública.

Antes de la transmisión, revisar la lista de archivos y, cuando sea necesario, sus contenidos en un entorno aislado para detectar credenciales, tokens, nombres de host internos y datos personales. Para ocultar información, utilizar una copia independiente y documentar los cambios; no modificar perfiles binarios de forma incontrolada. Aclarar con soporte qué contenidos se necesitan sin modificaciones para el diagnóstico. Conservar el original únicamente con acceso protegido y durante el plazo acordado.

Transmitir el archivo y los registros asociados exclusivamente mediante el canal de soporte de Sophos autorizado y confirmado en el caso de soporte. Verificar el destinatario y el destino de carga a partir del caso existente, no de un mensaje no solicitado. No utilizar un ticket público, un foro, un repositorio Git ni un repositorio multimedia de la base de conocimientos. El paquete debe ir acompañado del tipo de implementación, los nodos o hosts afectados, la versión del sensor, la hora del error con su zona horaria, el síntoma y los pasos de recopilación ya realizados; no enviar credenciales como texto adjunto.

Perfiles de CPU y memoria solo cuando sean específicamente necesarios

Para un archivo de soporte normal basta con la señal temporal. Los siguientes perfiles individuales constituyen un procedimiento independiente para problemas de CPU o memoria y utilizan el formato pprof de Google. Para activar la depuración mediante una configuración permanente, debe estar claro de antemano cómo se inicia el servicio real de SLS y cómo se puede restablecer su configuración.

Primero, guardar el contenido anterior de /etc/sophos/runtimedetections-rules.yaml, el valor anterior de debug o su ausencia, y el entorno de inicio efectivo. En particular, determinar si RUNTIMEDETECTIONS_DEBUG ya está definida. Una copia de seguridad de esa configuración también es confidencial. No confundirla con el archivo de nombre similar runtimedetections.yaml del archivo de soporte.

Elegir una de las activaciones documentadas:

• Ejecutar el sensor con RUNTIMEDETECTIONS_DEBUG=true en su entorno de inicio real. Un simple export en una shell de administración no cambia el entorno de un servicio que ya está en ejecución.
• Establecer debug: true en /etc/sophos/runtimedetections-rules.yaml sin sustituir las demás reglas ni crear una segunda entrada contradictoria.

Un reinicio interrumpe el servicio de SLS. La autorización de mantenimiento, el intervalo sin detección tolerable y el acceso a la configuración original deben estar definidos de antemano. Esta llamada de systemd se aplica a la instalación directa en el host; no es un procedimiento de reinicio para Helm o Docker.

Ejecutar el reinicio documentado con permisos de root:

systemctl restart sophoslinuxsensor

Después, comprobar el estado del servicio y el journal. Solo cuando el servicio esté en ejecución y la configuración sea válida, recopilar los perfiles necesarios en el endpoint local:

curl -s http://localhost:9010/debug/pprof/heap > heap.out
curl -s 'http://localhost:9010/debug/pprof/profile?seconds=60' > profile.out

heap.out recoge muestras de la memoria ocupada por objetos vivos del heap; profile.out recoge el uso de CPU durante 60 segundos. Estas llamadas no incluyen comprobación de errores HTTP: la mera creación de un archivo no demuestra que el perfil sea válido. No interpretar archivos vacíos ni respuestas de error como valores de medición; comprobar el endpoint y la configuración de depuración efectiva y, si es necesario, validar el formato con soporte. Estos archivos también siguen siendo confidenciales.

Las métricas, en cambio, no requieren modo de depuración ni un reinicio por motivos de depuración:

curl -s http://localhost:9010/metrics > metrics.out

Restablecer el estado de depuración y el estado operativo

En la recopilación temporal, no enviar más señales una vez transcurrida la ventana de 60 segundos. Dejar que el sensor siga ejecutándose y comprobar mediante sus registros o la monitorización operativa existente que continúa funcionando con normalidad. Un proceso en ejecución o un endpoint de métricas accesible no constituyen una prueba completa de la detección y la transmisión de datos. Si el comportamiento difiere del esperado, trabajar con soporte.

Cuando la depuración está configurada de forma permanente, no hay una restauración automática al cabo de 60 segundos. Restablecer en el archivo YAML el valor de debug guardado previamente o su ausencia original, y devolver al estado anterior cualquier variable RUNTIMEDETECTIONS_DEBUG definida expresamente para este diagnóstico en la configuración de inicio real. No sobrescribir indiscriminadamente otros ajustes ni toda una configuración que haya cambiado desde entonces. El cambio exacto del entorno depende del mecanismo de inicio existente; sin una configuración de referencia conocida, no hay un comando universal de restablecimiento seguro.

Para el servicio systemd instalado directamente, tras esta restauración volver a utilizar el comando systemctl restart sophoslinuxsensor mostrado anteriormente dentro de la ventana de mantenimiento autorizada. Revisar el servicio y el journal en busca de errores de inicio o configuración, comparar el ajuste de depuración efectivo con el estado anterior y comprobar que no quede ningún acceso a perfiles activado expresamente para el diagnóstico. Si la depuración ya estaba activa antes, desactivarla constituye una decisión operativa adicional, no una restauración.

Finalizar el reenvío de puertos de Helm y confirmar que su proceso de terminal ha terminado. El contenedor de depuración efímero no se puede eliminar del pod existente como un contenedor normal; no eliminar un pod del sensor únicamente para limpiar los elementos de este diagnóstico. Si la política local del clúster exige renovar el pod, el operador responsable debe planificarlo por separado, teniendo en cuenta el intervalo sin detección y el control del despliegue.

Una vez confirmada la recepción por parte de soporte y transcurrido el plazo de conservación establecido, eliminar los archivos de soporte, registros y perfiles concretamente generados, así como las copias temporales utilizadas para ocultar información, conforme a la política local de eliminación. No realizar eliminaciones con comodines ni eliminar reglas del sensor, registros del producto u otros casos de soporte. Eliminar un archivo no garantiza que se sobrescriban las copias de seguridad, las instantáneas o los bloques de SSD; su conservación corresponde a la política de almacenamiento y protección de datos pertinente.