Sophos Fusion: configurar y comprobar de forma segura Server Threat Protection
Tras instalar un agente de servidor, que la política sea visible no demuestra que la protección sea efectiva. Si todavía están pendientes la instalación y la aceptación del agente, para Windows Server consulte la instalación y aceptación de Windows Server; los servidores Linux requieren, en cambio, su propio procedimiento de instalación de SPL. Para establecer una base segura en Sophos Fusion (antes Sophos Central), compruebe primero el servidor real y su plataforma, mantenga después la configuración recomendada en un grupo piloto pequeño y, por último, verifique en las pestañas Policies, Status y Events del servidor qué configuración se ha aplicado. Los servidores Windows y Linux comparten una interfaz de políticas, pero no todas las funciones de protección.
Antes de cambiar nada: documentar la plataforma y el alcance
Anote el tenant, el nombre del servidor, el sistema operativo, el agente instalado, la licencia disponible o las funciones contratadas, la función del servidor y la política actual. Compare un servidor piloto Windows y otro Linux que tengan el mismo perfil de producción; los servidores de bases de datos, los controladores de dominio y los hosts de contenedores Linux merecen pruebas separadas por sus distintas cargas y accesos a archivos. Los ejemplos Pilot-Windows-App y Pilot-Linux-App son nombres de grupos de servidores elegidos libremente, no valores prescritos por Sophos. En My Products > Server > Servers, abra la pestaña Server Groups y seleccione Add Server Group. Cree un grupo para cada plataforma y asígnele servidores individuales. Un servidor solo puede pertenecer a un grupo: al asignarlo a un grupo piloto, se elimina del grupo anterior y también pueden cambiar otras políticas efectivas. Antes, documente por servidor el grupo anterior, las políticas aplicadas y su orden, asignaciones y ajustes como base para la reversión. Incluya primero solo unos pocos servidores representativos, no toda la producción.
La Base Policy protege los servidores cuando no se aplica ninguna política coincidente de mayor prioridad. Las políticas adicionales sirven para introducir desviaciones concretas. Sophos Fusion aplica, para cada tipo de política, la primera política activa coincidente de arriba abajo; los ajustes de varias políticas de Threat Protection no se combinan. El artículo sobre los fundamentos de las políticas explica el modelo de selección compartido; para este piloto, sin embargo, lo determinante son las políticas de Server y los grupos de servidores, no los grupos de equipos Endpoint. Coloque la política específica del piloto por encima de una política general y mantenga el resto de la configuración de referencia recomendada. Los cambios en una política compartida afectan a todos los servidores asignados a ella: compruebe la asignación antes de pulsar Save.
Configurar Server Threat Protection en el piloto
- Abra My Products > Server > Policies y seleccione Add Policy. Si aparece una selección, elija Threat Protection; para una política existente, abra primero el tipo de política y después su nombre. En Assigned to, asigne la nueva política al grupo piloto pequeño y compruebe Excluded from si aparece. No modifique inadvertidamente la Base Policy de todos los servidores.
- Abra Settings y deje activada la política. En Show filters > Operating System, seleccione primero Windows, haga clic en Apply, repita el procedimiento para Linux y vuelva a hacer clic en Apply. El filtro muestra los ajustes disponibles para cada plataforma; no habilita funciones en el agente. Recommended y Enabled/Disabled ayudan a detectar desviaciones.
- Mantenga Live Protection, Deep Learning y Real-time Scanning - Local Files and Network Shares en sus ajustes recomendados siempre que sea posible. En Real-time Scanning - Local Files and Network Shares, Scan controla el análisis en tiempo real de archivos locales y de archivos a los que se accede por red; Local lo limita a los archivos del dispositivo. Cambiar a Local requiere una justificación concreta y una prueba de los recursos compartidos afectados.
- La protección al acceder a archivos en Linux está desactivada de forma predeterminada. Para un piloto Linux con protección al acceder a archivos, debe estar instalado el producto
antivirusde SPL o su complemento AV. En la política efectiva de Server Threat Protection deben estar activadas tanto Scan como Enable scan for Server Protection for Linux Agent en Real-time Scanning - Local Files and Network Shares; la segunda opción viene desactivada de fábrica. Compruebe el componente AV instalado en el servidor piloto según se describe en el artículo de instalación de SPL enlazado. Si falta el componente o no está activada alguna de las dos opciones, no dé por aceptado el piloto como protegido al acceder a archivos; documente la brecha y detenga la ampliación. Un análisis programado no sustituye al análisis en tiempo real: comprueba los archivos en momentos fijos, no cuando se accede a ellos. Enable scheduled scan está disponible para ambas plataformas; si lo necesita, elija un horario de baja carga. La hora se rige por la hora local del dispositivo. En Linux, el análisis programado utiliza Live Protection con independencia del ajuste correspondiente de la política. - Mantenga activado Enable event journals siempre que sea posible: si se desactiva, faltarán registros para investigaciones posteriores del periodo en que estuvo apagado; además, Threat Graphs y, si se utiliza, Server File Integrity Monitoring dejarán de funcionar. No configure aquí tamaños globales de los registros. Guarde el cambio y compruebe la política efectiva en el dispositivo antes de asignar más servidores.
No confunda las funciones entre plataformas: el análisis en tiempo real de Internet, el descifrado HTTPS, la protección CryptoGuard/contra exploits, AMSI, Adaptive Attack Protection y Security Heartbeat están documentados en esta política como funciones de Windows. Esto no implica una protección equivalente en Linux. Linux runtime detections es una función independiente para Linux que requiere una licencia adecuada; la mera visibilidad de la opción no demuestra ni el derecho a utilizarla ni que la detección en tiempo de ejecución esté activa. Compruebe la licencia concreta y el estado del agente y del tenant antes de contar con esta función. Las opciones de Linux para el análisis en tiempo real y para detener procesos maliciosos relacionados con él tampoco son equivalentes a los módulos de protección en tiempo de ejecución de Windows.
Exclusiones solo ante un conflicto demostrado
Una exclusión del análisis reduce la protección, aunque otras comprobaciones puedan seguir actuando sobre el objeto excluido. Ante una detección errónea, busque en la pestaña Events la marca de tiempo, la detección y la ruta afectada; compárelas con la versión de la aplicación, las indicaciones del fabricante y un fallo reproducible. Una aplicación de base de datos también puede sufrir una degradación medible por los análisis debido a accesos frecuentes a archivos, aun sin eventos de detección: compare de forma reproducible los tiempos de ejecución, la carga y los accesos afectados antes y después de una prueba limitada en el tiempo dentro del grupo piloto. Un servicio que simplemente funciona lento, sin una relación verificable con el análisis, no justifica una exclusión.
En Settings > Exclusions > Add Exclusion, seleccione Exclusion Type e introduzca solo el objeto concretamente afectado. Para File or folder, limite Active for a Real-time Scanning o Scheduled Scanning si no se ha demostrado que ambos estén afectados. Si se ha constatado una carga problemática en una base de datos Windows, examine primero Process (Windows) con la ruta completa de la aplicación según las indicaciones del fabricante: solo se excluyen los archivos utilizados por ese proceso cuando accede a ellos, en lugar de dejar todo un árbol de archivos sin protección frente a otros procesos. Para Linux, File or folder (Linux) admite rutas de archivos y carpetas, así como ? y *; una ruta completamente especificada como /mnt/hgfs/excluded es un ejemplo de sintaxis de la documentación de Sophos, no una recomendación general de excluir esa carpeta. Sustitúyala únicamente por una ruta verificada en el servidor afectado. No traslade las exclusiones de procesos o exploits de Windows a Linux como si fueran equivalentes. No utilice exclusiones de Detected Exploits o de hashing como solución general a problemas de análisis; para las exclusiones de hashing, consulte primero a Sophos Support. Una exclusión de política solo se aplica a los servidores a los que se aplica esa política; una Global Exclusion, en cambio, tiene alcance en todo el tenant. Al revisar eventos, no cree una exclusión global de detección mediante Don’t detect this again. La guía conjunta sobre exclusiones para Endpoint y Server explica los tipos, el alcance y la reversión; la selección aquí sigue siendo una decisión de política de servidor. Documente el evento de detección o los datos reproducibles de rendimiento, las indicaciones del fabricante, el motivo, la persona responsable, los servidores afectados, la prueba y la fecha de caducidad prevista. Tras guardar, compruebe el flujo de trabajo afectado y retire la exclusión cuando se haya resuelto la causa y verificado la reversión.
Demostrar el efecto en el servidor concreto
Abra My Products > Server > Servers, seleccione el servidor piloto y compruebe lo siguiente:
- Policies: ¿Aparece realmente la política prevista en Threat Protection? Si no es así, compruebe la asignación, la activación y el orden. Al hacer clic en la política se abren sus ajustes; los cambios realizados allí también afectan a los demás servidores asignados.
- Status: En los servidores Windows más recientes, Health status y las evaluaciones de Communication, Operations, Services, System, Threat y Update muestran posibles problemas. En Linux y en los servidores Windows más antiguos, Security Health muestra, entre otros datos, el último contacto con Sophos Fusion y los servicios de Sophos en ejecución; no es la misma evaluación detallada de Windows. Un estado verde por sí solo no demuestra que se haya verificado la protección frente a ataques.
- Events: Compruebe los mensajes, las actualizaciones correctas y, si existe alguna detección previa, sus datos mediante Details, dentro del intervalo de tiempo pertinente. La ausencia de un evento de malware no constituye una prueba funcional. No desencadene acciones de malware o exploits expresamente en un servidor de producción. La hora mostrada en Last active puede ser anterior a la de un evento porque se actualiza aproximadamente cada hora.
En Linux, compruebe además localmente el producto antivirus/complemento AV instalado y la política recibida (las rutas de comprobación figuran en el artículo de instalación de SPL). Policies, Status, Events y un indicador de salud verde no demuestran por sí solos ni que el análisis al acceder a archivos esté activo ni que detecte amenazas. Solo en un sistema no productivo autorizado, una prueba funcional controlada con el archivo de prueba inocuo EICAR, siguiendo las instrucciones de Sophos, puede comprobar la reacción al acceder al archivo, la entrada en el registro AV y la alerta en Fusion; elimine el archivo de prueba y gestione la alerta de prueba conforme al procedimiento local. Sin esa prueba, la capacidad de detección sigue sin confirmarse; no haga pruebas de malware en producción.
Además, Account Health Check muestra las desviaciones de las políticas de Server Threat Protection respecto de las recomendaciones de Sophos. Ante una advertencia, abra la política indicada, revise los ajustes marcados en rojo y corríjalos de forma selectiva. Fix automatically restablece todas las opciones de las políticas afectadas a los ajustes recomendados y puede sobrescribir desviaciones deliberadas del piloto; antes de confirmar, compruebe los servidores afectados y el alcance del cambio. Revise por separado la advertencia sobre Policy exclusions peligrosas: la comprobación solo detecta exclusiones especialmente inseguras; un estado verde no certifica que todas las exclusiones sean inocuas. Tampoco aplique allí una corrección automática sin revisar todo el alcance de las políticas afectadas: puede eliminar exclusiones de todas ellas. El registro de auditoría documenta los cambios automáticos. Después de cada corrección, vuelva a comprobar la política, el estado y los eventos en el servidor piloto.
Si el resultado no coincide con la configuración
- Política incorrecta o no aparece la esperada: compruebe el tenant, el grupo de servidores, la activación de la política y su prioridad en la lista. Consulte el nombre correcto en la pestaña Policies del servidor; no deduzca su efecto únicamente de la lista de políticas.
- No está claro si el análisis en tiempo real funciona en Linux: compruebe Scan y Enable scan for Server Protection for Linux Agent en Real-time Scanning - Local Files and Network Shares de la política efectiva filtrada para Linux, y compruebe localmente el complemento AV de SPL/producto
antivirus. Si falta algún elemento o el efecto sigue sin estar claro, no afirme que existe protección al acceder a archivos, no amplíe el piloto y remita a Sophos Support los datos del agente y la licencia junto con el diagnóstico. - Advertencia o evaluación de salud en rojo: en Windows, abra la evaluación concreta de Communication, Services o Update; en Linux, compare la última actividad en Fusion, los servicios en ejecución y las alertas. Resuelva primero los problemas de comunicación o actualización y vuelva a comprobar después que se haya recibido la política.
- La aplicación responde lentamente o se bloquea un archivo: si hay un bloqueo, compruebe el evento simultáneo y la ruta; si hay una caída del rendimiento sin evento, reúna comparaciones reproducibles de carga y acceso junto con las indicaciones del fabricante. No excluya por conjetura todo un árbol de directorios ni cree una exclusión para todo el tenant. Una exclusión limitada al piloto solo es justificable con una causa demostrada y un plan de reversión. Si la desviación persiste, documente el hallazgo, la asignación de la política y el estado del agente, y escale el caso.
Detener el piloto y revertir los cambios
Detenga la ampliación si falta la protección al acceder a archivos en Linux, se aplica una política incorrecta, el agente mantiene un estado deficiente, hay bloqueos sin aclarar o se produce una alteración medible de una carga de trabajo crítica para el negocio. Registre los servidores afectados y la desviación; coordine la reversión durante la ventana de cambios con los responsables de la carga de trabajo. Devuelva cada servidor trasladado a su grupo anterior o elimínelo del grupo piloto si antes no pertenecía a ninguno. Si los cambios del piloto modificaron una política existente, su prioridad o su asignación, restaure también el orden, la asignación y los ajustes documentados; volver al grupo anterior no repara por sí solo una política modificada. Retire de forma selectiva las exclusiones del piloto tras comprobar la carga de trabajo afectada: asegúrese primero de que el bloqueo o la degradación de rendimiento anteriores no vuelvan a producirse; si hace falta, investigue la causa y documente mientras tanto la necesidad residual, estrictamente limitada y con fecha de caducidad, en lugar de eliminarlas sin control. Compruebe después en cada servidor afectado la pertenencia al grupo, las políticas efectivas, el estado/salud, los eventos y el flujo de trabajo que se había visto afectado. Si no se obtiene una verificación satisfactoria, mantenga detenido el despliegue y escale el incidente.