Sophos Server Protection: validar de forma segura las plataformas Windows y Linux

Decisión rápida: Incluya un servidor en la siguiente tanda de instalación o actualización solo si su sistema operativo concreto y su agente cumplen los requisitos vigentes de Sophos, las funciones necesarias están disponibles en su tenant y un piloto representativo se mantiene en buen estado. Una entrada en unas notas de versión antiguas solo demuestra que en algún momento existieron componentes para esa plataforma, no que hoy se admita su sistema operativo sin restricciones. Si no hay pruebas fiables, excluya el servidor de la tanda y consulte la compatibilidad de la plataforma con el soporte de Sophos.

Esta guía ayuda a tomar la decisión de aprobación antes de una instalación nueva, un cambio de sistema operativo o una actualización del agente. Los pasos propiamente dichos para Windows Server y Sophos Protection for Linux (SPL) se encuentran en sus respectivas guías de instalación.

Comprobar por separado la versión publicada y la compatibilidad vigente

En la comprobación del 24 de septiembre de 2026, las notas de versión del Windows Server Core Agent indican 2026.2.2.1 (septiembre de 2026) como versión más reciente y presentan secciones de componentes separadas para Windows Server 2016 y posteriores y para plataformas antiguas heredadas. Las notas de versión actuales del Windows Server Core Agent son la referencia para los cambios de versiones y componentes. También advierten de que el despliegue del software puede prolongarse durante varias semanas después de su publicación. Una sección de componentes, sea histórica o actual, no equivale a la aprobación de una edición o compilación concreta de Windows.

Según los requisitos del sistema de Windows Server de Sophos (KBA-000003024, actualizados el 7 de mayo de 2026), Windows Server 2016, 2019, 2022 y 2025 son generaciones totalmente compatibles. Windows Server 2008 R2, 2012 y 2012 R2 son plataformas heredadas y requieren una licencia de soporte ampliado; algunas funciones pueden faltar o no recibir soporte o actualizaciones. Sensor Mode no es compatible con plataformas heredadas. Esta relación fechada no aprueba de forma general todas las ediciones, arquitecturas o compilaciones. Antes de la tanda, inventaríe la edición exacta, la compilación completa del sistema operativo, la arquitectura, la versión del agente, el modo de protección previsto y, para hosts heredados, el derecho efectivo a soporte ampliado. Contraste la combinación concreta con los requisitos actuales del sistema de Windows Server de Sophos, la información sobre variantes de Windows compatibles y el calendario de retirada. Si la página de soporte de Sophos no puede consultarse o no da una respuesta inequívoca, suspenda la aprobación y consulte a Sophos Support. Ni que el agente arranque ni una entrada en las notas de versión prueban por sí solos el derecho a soporte.

Compruebe los recursos según licencia y modo: A 7 de mayo de 2026, Sophos Endpoint – Server requiere al menos 8 GB de espacio libre en disco, 8 GB de RAM y 2 núcleos. Para Sophos EDR, XDR y MDR – Server, los mínimos son 10 GB de espacio libre en disco, 8 GB de RAM y 2 núcleos; se recomiendan 10 GB de espacio libre en disco, 16 GB de RAM y 4 núcleos. Se aplican tanto a Full Protection como a Sensor Mode: la tabla de recursos no anula la prohibición del sensor en plataformas heredadas. Sophos recomienda encarecidamente una SSD para el volumen de arranque. Son valores orientativos generales, no una garantía de rendimiento suficiente para cualquier carga: la detección y limpieza de malware pueden elevar temporalmente el uso de CPU, RAM y disco. Compruebe el margen y el comportamiento en su propio piloto.

Para Linux, las notas de versión de SPL señalan 2026.3 (septiembre de 2026) como versión más reciente en la misma fecha de comprobación. También en este caso la disponibilidad en su tenant puede ser posterior a la publicación de las notas. En System requirements figuran actualmente al menos 2,5 GB de espacio libre en disco, 2 GB de memoria RAM libre, x86_64 o ARM64, systemd en ejecución, Bash y glibc 2.17 o posterior; para ARM64 se requieren glibc 2.18 o posterior y kernel 5.3 o posterior. Estos valores son una referencia fechada para la comprobación, no una aprobación permanente de todas las distribuciones o kernels de Linux.

Las indicaciones de Sophos sobre distribuciones y kernels para SPL remiten a System requirements > Supported platforms de las notas de versión para consultar la lista vigente de plataformas; no constituyen una segunda matriz de compatibilidad independiente. Deben ser compatibles entre sí la distribución, su versión principal y secundaria, la arquitectura, el kernel en ejecución y el soporte del fabricante. En la fecha de comprobación indicada, la lista de plataformas probadas incluye, entre otras, RHEL 8–10, Debian 11–13 y Ubuntu 22.04/24.04 LTS, así como 26.04; existe además una lista de plataformas heredadas identificada por separado, que no supone una aprobación automática. Sophos prueba las versiones secundarias o los service packs activos más recientes; en x86_64 pueden aplicarse mínimos de kernel específicos de cada distribución. Por tanto, un kernel 5.3 no constituye una aprobación general para x86_64. Incluso un kernel que supere el mínimo puede plantear problemas: las notas actuales señalan un fallo conocido de ftrace entre 5.10.133 y 5.10.142 que puede bloquear el kernel. No apruebe esa combinación solo porque la instalación parezca funcionar; aclare antes la versión del kernel y las indicaciones de Sophos.

Distinga las excepciones antes del piloto: Si la imagen de Linux es inmutable, no apruebe SPL para ella: Sophos indica que SPL no está diseñado para distribuciones inmutables y remite al producto independiente Sophos Linux Sensor (SLS) para esas plataformas. SLS no es el XDR Sensor de SPL; esta guía no describe la instalación de SLS. Las distribuciones derivadas que no figuran en la lista, los kernels propios o mínimos y los sistemas reforzados tampoco pasan automáticamente a ser plataformas probadas: Sophos contempla para ellos una evaluación según esfuerzos comercialmente razonables y puede exigir reproducir el problema en una plataforma admitida o actualizarla.

Para un host Linux heredado ya existente, compruebe además su derecho efectivo a soporte ampliado y el paquete de software instalado, así como el asignado mediante Update Management. A 24 de septiembre de 2026, Sophos identifica 2026.1.0.35 como el paquete LTS admitido para versiones heredadas y recomienda asignarlo mediante Update Management; si surge un problema con un paquete más reciente, puede ser necesario volver al paquete admitido para investigarlo. Antes de cualquier cambio, compruebe las indicaciones vigentes de Sophos y la disponibilidad del paquete concreto: el encabezado SPL 2026.3 no convierte esa versión automáticamente en el objetivo para un host heredado, ni 2026.1.0.35 es una garantía permanente o una instrucción general para volver a una versión anterior.

Documentar la aprobación de una tanda concreta

Un registro breve de comprobaciones evita tomar una instalación funcional por una prueba de compatibilidad. Registre por separado cada familia de servidores —por ejemplo, servidores de aplicaciones Windows y servidores de bases de datos Linux—:

Estado actual y objetivo: función del servidor; edición del sistema operativo o distribución y versión secundaria; compilación completa o uname -r; arquitectura; agente instalado con sus componentes; y versión de destino prevista. En Windows, compruebe el tipo de licencia (Endpoint – Server o EDR/XDR/MDR – Server), Full Protection o Sensor Mode, el espacio libre, la RAM, los núcleos y el volumen de arranque. En Linux, compruebe también el tipo de imagen (inmutable o modificable), la RAM y el espacio libres en el volumen de instalación real, systemd en ejecución, Bash y glibc. En sistemas Linux heredados, registre por separado el paquete de software instalado y el asignado.
Pruebas: anote la fecha y versión de los requisitos del sistema de Windows y de las notas de Windows o SPL, los requisitos actuales de sistema operativo y kernel, el ciclo de vida y el soporte ampliado —incluido el derecho efectivo de los hosts heredados—, así como la licencia y las funciones del tenant necesarias. En Windows, si no hay pruebas inequívocas para la edición, compilación, arquitectura y modo de protección, registre expresamente pendiente en lugar de «compatible». Una mención de una nueva función en las notas —por ejemplo, Linux como Update Cache o Message Relay desde SPL 2026.3— no sustituye la comprobación de su disponibilidad efectiva en el tenant ni de sus requisitos independientes.
Decisión: «aprobado para el piloto», «actualizar primero el sistema operativo o el kernel» o «detener y consultar con soporte». Identifique a la persona que revisa, la ventana de cambio, los equipos piloto y los criterios de parada. La primera opción requiere una prueba positiva de compatibilidad de la plataforma; una compilación derivada no probada no equivale a una combinación probada. Linux inmutable queda fuera de la tanda de SPL; continúe con Linux heredado solo si se han aclarado el derecho a soporte, la asignación del paquete adecuado y las pruebas actuales de compatibilidad.

En el piloto Linux, ejecute estos comandos de solo lectura en el servidor de destino lo más cerca posible de la ventana de cambio y conserve las salidas:

cat /etc/os-release
uname -r; uname -m
free -m
df -h -- /opt
ps -p 1 -o comm=; test -d /run/systemd/system && printf 'systemd läuft\n'
command -v bash; getconf GNU_LIBC_VERSION

En la salida de free -m, compare la columna available (no total) con los 2 GB de memoria libre requeridos. df -h -- /opt solo sirve para una instalación estándar si /opt reside en el volumen de destino real; si hay un montaje independiente o se usa --install-dir, compruebe en su lugar una ruta que ya exista en el volumen de instalación real mediante df -h -- <Pfad> y confirme 2,5 GB libres. Si todavía no puede determinarse ese volumen, no apruebe los recursos. ps y el directorio /run/systemd/system comprueban el sistema de inicio en ejecución; Bash debe poder localizarse y la versión de glibc mostrada debe corresponder a la arquitectura. Confirme además si la imagen es inmutable a partir del tipo de imagen o de sistema operativo que figura en el inventario de despliegue: os-release por sí solo no demuestra que un host sea modificable. En Windows, conserve los datos completos del sistema operativo y del agente procedentes del inventario administrado y de las propiedades del sistema, así como los recursos correspondientes a la licencia y al modo de protección previstos. Repita la comprobación si cambian el sistema operativo, el kernel, el agente, la licencia o los requisitos de Sophos; no se base únicamente en la fecha de este artículo.

Piloto, estado y siguiente tanda

Elija primero un servidor representativo de cada combinación de plataformas relevante: misma versión secundaria del sistema operativo, arquitectura y kernel, ruta de red o proxy similar y función y carga comparables. Antes del piloto, compruebe la copia de seguridad y la vía de recuperación, asegure el acceso por consola o fuera de banda y reserve una ventana de mantenimiento que contemple un posible reinicio. Una base de datos con picos de E/S particulares necesita una prueba de carga adecuada; no basta con arrancar una máquina virtual de prueba vacía.

Después de instalar o actualizar, compruebe en My Products > Server > Servers del tenant correcto que el piloto aparece una sola vez, se comunica correctamente, tiene los componentes de protección previstos y el grupo de servidores esperado, y no muestra una alerta de estado persistente. Compare los componentes instalados y sus versiones en el equipo y en Fusion; compruebe la política de servidor efectiva en el host, no solo la asignación al grupo. En Linux, compruebe también sudo systemctl status sophos-spl. Solo si está instalado el plugin antivirus, lea sudo cat /opt/sophos-spl/plugins/av/VERSION.ini para la ruta predeterminada (ajuste la ruta si se modificó --install-dir) y compare su versión con el componente Server Protection, no con el componente base de SPL, en Central. En un SPL XDR Sensor sin plugin antivirus, compruebe en su lugar los componentes realmente instalados y sus versiones y estado en Central; la ausencia del archivo de antivirus no es un error en ese caso. Un servicio en buen estado por sí solo no confirma que la protección antimalware esté actualizada ni que una política sea efectiva. Solo cuando esté instalada la protección antivirus y se haya verificado que la Server Threat Protection Policy efectiva tiene activadas tanto Real-time scanning - Local files and network shares como Enable scan for Server Protection for Linux Agent, realice una prueba planificada y segura de detección en acceso según la guía de instalación de Linux; un XDR Sensor sin antivirus no es un candidato adecuado para esa prueba.

Compare después la aplicación de negocio, el comportamiento tras el reinicio, las conexiones de red y la carga normal con el estado anterior. Si se trata de una nueva función del agente, compruebe primero si se ofrece realmente al piloto en el tenant. La siguiente tanda, de alcance limitado, solo debe comenzar cuando se hayan superado conjuntamente la comprobación de la plataforma, la revisión del agente y la política, el estado y la prueba de la aplicación. Las notas de versión pueden publicarse antes de que la versión esté disponible: si la versión ofrecida en la práctica es distinta, investíguelo en lugar de forzar una descarga.

Preparar los criterios de parada y la reversión

Antes del cambio, registre las versiones funcionales del sistema operativo, el kernel y el agente; en Linux heredado, también el paquete de software instalado y el asignado; además, la copia de seguridad, la ventana de mantenimiento, el modo de protección y la persona responsable. No se puede dar por hecho que sea posible volver a un agente antiguo solo porque su versión aparezca en unas notas de versión históricas. Para revertir el sistema operativo o el kernel deben comprobarse por separado el arranque, la integridad de los datos y la compatibilidad de la versión de destino. Aunque Sophos pueda solicitar, en casos de soporte de Linux heredado, que se vuelva al paquete admitido, los paquetes de software o las políticas de actualización de Sophos no son un mecanismo universal para bajar de versión: acuerde de antemano con Sophos una vía de reversión para el host concreto.

Si no se registra el agente, el estado es persistentemente deficiente, el alcance de protección es incorrecto, se producen reinicios inesperados o falla una aplicación del servidor, detenga de inmediato la distribución y los reintentos automáticos, aísle los hosts afectados y no inicie otra tanda. Compruebe primero el tenant, la conexión, la política efectiva, la versión del agente ofrecida y las diferencias del sistema operativo o el kernel respecto del registro. Limite cualquier corrección de la política al piloto y vuelva a validarla después; no desactive la protección para todo el tenant. Si es necesario volver atrás, utilice la vía de recuperación del sistema definida y probada previamente y el procedimiento de soporte de Sophos correspondiente a la versión concreta del agente. No elimine componentes ni controladores por mera sospecha. Si la compatibilidad de la plataforma o una vía de reversión admitida siguen sin aclararse, conserve los registros y datos de la plataforma y contacte con el soporte de Sophos; hasta entonces, mantenga detenida la tanda de despliegue.