Configurar y comprobar Linux Runtime Detection para servidores Sophos

Linux Runtime Detection (RTD) supervisa los procesos y las aplicaciones en ejecución en servidores Linux con Sophos Protection for Linux (SPL). Una detección de RTD notifica actividad sospechosa; no significa que RTD haya bloqueado el proceso ni eliminado la amenaza. RTD complementa Server Threat Protection, pero no sustituye su protección contra malware ni el análisis en tiempo real de Linux. Finalizar procesos maliciosos cuando se detecta malware en tiempo real es una opción independiente de Server Threat Protection, no una función de RTD. Guardar la configuración de un perfil, por sí solo, no activa la detección en un servidor.

En resumen: comprobar la licencia y los servidores SPL → activar Linux runtime detections en la política Server Threat Protection que se aplica a los servidores → habilitar una política Linux Runtime Detection para un grupo pequeño de servidores Linux, con las detecciones predeterminadas de SophosLabs o una versión de perfil elegida expresamente → comprobar la asignación y las detecciones → solo entonces ampliar el despliegue.

Requisitos previos y decisiones antes de la prueba piloto

Las políticas de RTD se aplican únicamente a servidores Linux, no a servidores Windows ni al Sophos Linux Sensor, que se configura por separado. Según la documentación de Sophos sobre la política de RTD, se requiere Sophos XDR - Server o Sophos MDR Plus - Server. No se debe inferir de ello que una licencia genérica de Server Protection, Endpoint u otro producto MDR dé derecho a usar RTD. Comprueba la licencia concreta del servidor, la disponibilidad de la función en tu tenant y el agente SPL instalado antes de aprobar la prueba piloto. Si la política o la licencia no están disponibles, no intentes sustituirlas por una configuración de Endpoint o del sensor que parezca similar.

Elige un servidor Linux representativo y de baja criticidad, y crea un grupo exclusivo para la prueba piloto, por ejemplo, linux-rtd-pilot. Puedes escoger otro nombre, pero los miembros del grupo deben corresponder a los servidores previstos. Anota las políticas que se aplican actualmente, la pertenencia a los grupos y, si existe, el nombre del perfil junto con su Profile Version. Así podrás revertir el cambio de forma precisa sin alterar la protección básica. Una regla de RTD puede generar alertas por operaciones legítimas; por eso, también hay que observar los procesos de mantenimiento y automatización durante la prueba.

Configurar la política y, si procede, un perfil

1. En Sophos Fusion, abre la política Server Threat Protection que se aplica a los servidores piloto desde My Products > Server > Policies. Usa Show filters > Operating System > Linux para mostrar las opciones correspondientes. Comprueba que Linux runtime detections esté activado en Runtime Protection y guarda la política. Si esa política también protege otros servidores, crea o utiliza una política limitada al grupo piloto en lugar de cambiar toda la flota sin advertirlo. El interruptor independiente Enable scan for Server Protection for Linux agent controla el análisis de archivos en tiempo real en Linux; no es el interruptor de RTD y no debe desactivarse para probar RTD.
2. Antes de crear la política de RTD, decide qué opción usar: Sophos Labs Default Detection emplea las detecciones predeterminadas de SophosLabs sin ajustes propios de las reglas. Elige Linux Runtime Detection Profile solo si necesitas adaptar y versionar deliberadamente reglas concretas o sus listas de permitidos y bloqueados. Un perfil también se basa en contenido de SophosLabs; no sustituye a la política.
3. Solo si optas por un perfil: abre My Products > Global Settings > Protection and Remediation > Linux Profiles, haz clic en Create Profile, asígnale un nombre como linux-rtd-pilot, comprueba Content Version, documenta si procede la Change Description y modifica únicamente las reglas que comprendas. Save crea inicialmente la versión 1. Para introducir cambios posteriores, usa Create New Version; anota qué Profile Version se ha aprobado para la prueba piloto. La versión del perfil (tu configuración) y Content Version (el contenido de SophosLabs) son cosas distintas. Registra ambas en cada cambio en lugar de interpretar el número de versión del perfil como una descripción completa de las detecciones disponibles. SPL obtiene siempre el contenido predeterminado más reciente de SophosLabs; los perfiles existentes también se actualizan con el nuevo contenido de SophosLabs. En cambio, las actualizaciones de contenido seleccionadas manualmente corresponden al Sophos Linux Sensor, administrado por separado, no a la política para servidores SPL. Vuelve a comprobar tus ajustes de reglas tras las actualizaciones posteriores del contenido.
4. En My Products > Server > Policies, crea una política Linux Runtime Detection. Abre Settings, activa Enable Linux Runtime Detection y selecciona Sophos Labs Default Detection o Linux Runtime Detection Profile. Si utilizas un perfil, selecciona expresamente Profile y Version. Activa la política, asígnala únicamente al grupo piloto y haz clic en Save. Después, comprueba la asignación: guardar una política o un perfil no demuestra, por sí solo, que los servidores de destino los estén aplicando.

Comprobar el alcance: un perfil puede utilizarse en varias políticas de RTD. Antes de crear una versión o modificar una regla, despliega Active en Linux Profiles y comprueba qué políticas se verán afectadas. Un cambio en una política compartida puede afectar a varios grupos. No desactives una regla para todos ni crees una excepción global como respuesta rápida a un único falso positivo.

Comprobar la aplicación de la política y las detecciones

Abre My Products > Server > Servers > Server Groups, selecciona linux-rtd-pilot y comprueba en la pestaña Policies que tanto la política Threat Protection como la de RTD estén activadas y se apliquen al grupo. Comprueba además en el servidor afectado qué política tiene realmente asignada y el estado actual del agente y de su conexión. Si utilizas un perfil, Profile y Version en la política de RTD deben coincidir con los valores aprobados. Una entrada en Linux Profiles > Active indica qué políticas usan el perfil, pero no demuestra que se haya producido una detección de prueba en el host.

A continuación, observa las detecciones del servidor piloto en Threat Analysis Center > Detections y registra la hora, el servidor, la regla, el proceso observado y el contexto operativo de cada alerta. Esta vista necesita datos cargados desde los dispositivos; si no llega ningún dato, comprueba también la transferencia de datos al Data Lake configurada para ese servidor. Una detección de RTD pertinente confirma que se ha notificado un evento, no que RTD lo haya bloqueado o eliminado. La ausencia de alertas durante el funcionamiento normal no demuestra ni que la función opere correctamente ni que haya fallado. No ejecutes acciones maliciosas en servidores de producción para hacer pruebas.

Si faltan datos esperados, comprueba primero la licencia y el tenant, la conexión de SPL y que se apliquen realmente ambas políticas activadas. Si usas un perfil, comprueba además que contenga una regla adecuada y que esta esté Enabled. Según Sophos, una diferencia en los últimos dígitos de compilación entre Content Version en Fusion y rtd_content_version en el dispositivo Linux no implica necesariamente que el contenido esté obsoleto; no cambies la versión del perfil a ciegas. Si sigue sin estar claro el origen de un problema de política, agente o carga de datos, proporciona a Sophos Support las marcas de tiempo y los detalles de las políticas aplicadas, en lugar de utilizar un comando de prueba no documentado o forzar un reinicio del agente. La investigación de una detección sospechosa corresponde al equipo de seguridad propio o al proveedor de MDR contratado; si hay un incidente activo, sigue el proceso de respuesta a incidentes.

Acotar los falsos positivos y revertir los cambios con seguridad

Ante una alerta sospechosa, investiga primero lo ocurrido: ¿está autorizado el proceso?, ¿a qué host y regla afecta?, ¿coincide con tareas de mantenimiento? Solo después de esa comprobación, examina en el perfil la regla concreta y su Allow/Block List. Es preferible un ajuste bien delimitado a desactivar la regla de forma general; documenta su alcance, el motivo y la versión, y vuelve a probarlo únicamente con el grupo piloto. Modificar una lista de permitidos o bloqueados puede reducir o alterar las detecciones. Si no puedes confirmar que la alerta es un falso positivo, no permitas la actividad: solicita al equipo de seguridad o al proveedor de MDR contratado que continúe la investigación.

Para revertir los cambios, empieza por restaurar la asignación de la política de RTD al grupo piloto o la selección del perfil a su estado anterior documentado, y comprueba de nuevo qué política se aplica realmente. Si una versión nueva del perfil causa problemas, vuelve a seleccionar la Profile Version anterior documentada en la política piloto y guarda el cambio; antes comprueba las demás políticas que utilizan el mismo perfil. Esto revierte únicamente la configuración guardada del perfil o la asignación de la política: en SPL no restaura el contenido de detección de SophosLabs que se haya actualizado entretanto ni fija una Content Version anterior. Vuelve a comprobar los ajustes de las reglas con el contenido actual. Solo si durante la prueba piloto se activó el requisito Linux runtime detections —que antes estaba desactivado— en una política Threat Protection asignada exclusivamente al grupo piloto, puede devolverse ese interruptor a su estado anterior. No desactives el análisis en tiempo real de Linux, todo Server Threat Protection ni SPL para revertir RTD: eliminarías otra capa de protección. Después, comprueba de nuevo el estado de la conexión, las políticas aplicadas y las detecciones posteriores.