Revisar Sophos Firewall a diario: lista operativa para administradores

Una Sophos Firewall puede seguir siendo accesible y, aun así, mostrar señales tempranas de alerta: una conexión WAN oscila, aumenta la ocupación del disco, un servicio comunica un error o se acumulan los inicios de sesión administrativos fallidos. Una revisión operativa breve y repetible permite detectar estos cambios antes de que provoquen una interrupción prolongada o un incidente de seguridad.

Este procedimiento se ocupa del funcionamiento actual. El Health Check de Sophos Firewall, en cambio, determina si algunas configuraciones cumplen las recomendaciones de Sophos y CIS. Ambas revisiones se complementan, pero no se sustituyen.

La revisión de diez minutos

Para la visión general diaria basta con un procedimiento fijo:

1. En Control Center, anotar el modelo, la versión del firmware y la compilación, abrir los mensajes nuevos y hacer clic en los iconos de estado de servicios, WAN, interfaces y VPN.
2. En Diagnostics > System graphs, comparar la CPU, la memoria, el promedio de carga, el disco y las interfaces importantes con la línea base habitual.
3. Revisar los paneles de seguridad y los informes utilizados durante el último periodo completamente disponible para detectar nuevos eventos de IPS, web, aplicaciones, zero-day o Active Threat Response.
4. Abrir Log Viewer en la esquina superior derecha, seleccionar el módulo y el periodo, y revisar los inicios de sesión administrativos fallidos, los orígenes inusuales y los servicios asociados.
5. En HA, tener en cuenta el nodo que procesó el tráfico y, en los informes centrales, el origen de datos esperado.
6. Documentar cada desviación relevante con la hora, el firmware, el nodo, el origen, el servicio afectado y el siguiente paso.
7. No reiniciar servicios, borrar registros ni ampliar reglas debido a un único pico. Correlacionar primero la tendencia, los registros y el funcionamiento real.

Esta revisión breve no pretende provocar un cambio de configuración cada mañana. Su valor reside en detectar pronto las variaciones y decidir con claridad si se requiere observación, diagnóstico o escalación.

Cuatro vistas, cuatro afirmaciones distintas

Las vistas más importantes no muestran lo mismo:

• Control Center: visión actual del sistema, los servicios, la WAN, las interfaces, las VPN, el tiempo de actividad y los mensajes que requieren una acción.
• System graphs: evolución temporal de la CPU, la memoria, el promedio de carga, el disco, la transferencia WAN y los contadores de interfaces.
• Reports: evaluación consolidada de un periodo finalizado. Algunos widgets y datos de informes no se actualizan en tiempo real.
• Log Viewer: eventos individuales con hora, módulo, acción, origen, destino y, según el tipo de registro, Rule ID u otros detalles.

Un widget rojo es una señal, no un diagnóstico completo. Del mismo modo, un estado verde actual no demuestra que no se produjera un error breve durante la noche. Solo la combinación del estado actual, la evolución, el informe y el evento individual ofrece una imagen fiable.

Revisar el estado y la disponibilidad del sistema

Leer primero Control Center

En Control Center, la revisión comienza con los mensajes nuevos. Sophos muestra allí, entre otros, problemas de registro, licencia, informes, WAN o actualización. Algunos mensajes desaparecen automáticamente cuando se corrige la causa y no se pueden eliminar manualmente. Por tanto, cada mensaje relevante necesita un responsable y un siguiente paso trazable.

Aparece un mensaje Registration cuando Sophos Firewall no está registrado. Aparece un mensaje Licenses cuando hay módulos del firewall que no tienen licencia.

Algunos contadores de widgets de Control Center se restablecen tras reiniciar el firewall. Por tanto, un recuento bajo después del reinicio no demuestra que no se produjeran eventos antes. Para interpretarlo, correlacionar el tiempo de actividad con los registros conservados de forma duradera para el periodo afectado, como exportaciones CSV o registros centrales dentro de su periodo de retención. La consola de administración web no muestra información de temperatura.

Messages también muestra el tiempo transcurrido desde la creación de un mensaje. Según el tipo o la gravedad, este widget utiliza los indicadores Alert, Warning y Available firmware versions. Registrar juntos el indicador, el tiempo transcurrido y el texto del mensaje; los recuentos de Services y WAN/VPN descritos a continuación no se aplican a Messages.

El color debe interpretarse siempre junto con los detalles. En Services, Warning significa que se ha detenido al menos un servicio, mientras que Alert significa que al menos uno no ha podido iniciarse. En WAN y VPN, Warning indica que están caídas hasta la mitad de las conexiones configuradas, y Alert que lo están más de la mitad. Estos recuentos no consideran la importancia para el negocio. Por eso, un único túnel principal caído puede ser más urgente que varias conexiones inactivas de forma intencionada. Al hacer clic en el icono correspondiente se muestran los elementos afectados.

A continuación se comparan los servicios, las conexiones WAN, las interfaces y las VPN realmente utilizados con el estado esperado. Una interfaz roja no implica automáticamente una interrupción: un puerto sin uso y sin dirección IP o una interfaz física principal de una VLAN pueden aparecer en rojo de forma esperada. Lo relevante es la desviación respecto al diseño documentado.

Si se utilizan LAG, en SFOS 23 abrir el icono Interfaces y comprobar también si hay cables desconectados en cada uno de los miembros del LAG. La ayuda de SFOS 23 menciona expresamente esta vista detallada; la ayuda correspondiente de SFOS 22 no lo hace. Como interpretación operativa: que el agregado siga siendo accesible no demuestra que todos sus miembros estén disponibles ni, por tanto, que lo estén la redundancia y la capacidad previstas. Registrar en el ticket el miembro afectado y la desviación respecto al estado esperado.

Si se utilizan túneles RED y Wireless APs, comparar los widgets de estado de conexión con el estado esperado: RED cuenta los túneles establecidos frente a los configurados, y Wireless APs los puntos de acceso activos frente a los configurados. Los AP pendientes aparecen además entre paréntesis rojos y no deben contarse como AP activos. RED abre la lista de túneles y Wireless APs lleva a Wireless > Access points. Connected remote users cuenta los usuarios conectados mediante SSL VPN y abre Current activities > Remote users; Live users, en cambio, cuenta todos los usuarios actuales y abre Current activities > Live users. Estos recuentos de usuarios no sustituyen una comprobación de disponibilidad de RED o de los AP.

Si está previsto utilizar DNS Protection, comprobar su estado de configuración en el widget System. La ayuda de SFOS 22 enumera cinco estados: Not subscribed significa que falta la licencia; se requiere Xstream Protection. Not configured indica que deben introducirse las direcciones IP de DNS Protection. En caso de Unrecognized source, comprobar la IP pública del firewall y su asignación a una ubicación en Sophos Fusion. Active indica que DNS Protection está activo; un icono de información señala que falta el registro en Fusion. En caso de IP address conflict, comprobar la IP introducida en la ubicación y escalar a Sophos Support cualquier conflicto que no pueda resolverse.

La ayuda de SFOS 23 enumera Not subscribed, Not configured y Active, y remite a Configure DNS servers cuando falta la configuración; para el icono de información de Active, menciona el registro en Sophos Central. Esto no implica que los otros dos estados documentados en SFOS 22 se hayan eliminado en tiempo de ejecución. La ruta de configuración y resolución de problemas adecuada para cada versión se describe en Configurar DNS Protection con Sophos Firewall: no trasladar sin cambios la ruta de DNS tradicional y ubicación de SFOS 22 a la ruta integrada de SFOS 23.

Para consultar los eventos de DNS Protection, seleccionar el módulo System en Log Viewer y filtrar por DNS Protection. Guardar en el ticket la versión, el estado del widget y las líneas de registro relevantes. Esta comprobación de configuración y eventos no sustituye ni las pruebas funcionales de resolución de nombres y de eficacia del filtrado ni los informes de DNS Protection; los informes generales de seguridad por sí solos no demuestran que DNS Protection esté operativo.

El widget Messages se trata como una lista de acciones, no como un feed general de eventos. Si solicita crear la Secure Storage Master Key, hay que crearla para proporcionar protección adicional a datos sensibles como las contraseñas. Un mensaje de acceso WAN significa que WebAdmin (HTTPS) y la CLI (SSH) son accesibles desde la zona WAN: si se necesita administración remota, utilizar una VPN o una Local Service ACL Exception limitada a hosts o redes de gestión concretos en lugar de mantener un acceso WAN amplio. Ante un mensaje sobre el disco de informes, reducir el uso por debajo del umbral inferior; no basta con quedar por debajo del umbral superior. Los mensajes vinculados a un requisito desaparecen cuando se cumple y no se pueden borrar manualmente.

Ante un mensaje de fallo de actualización en firewalls de software, virtuales y en la nube, comprobar primero si la firewall ya se ha reclamado en Sophos Central (Claim). Reclamarla es un requisito previo a la actualización, no solo una medida tras un fallo. La documentación de SFOS 22 llama al portal «Sophos Fusion (previously Sophos Central)», mientras que la de SFOS 23 indica «Sophos Central»; el requisito no cambia. Registrar el estado de la reclamación y el mensaje de fallo en el ticket antes de planificar otro intento mediante el runbook de firmware.

Active threat response se interpreta por fuente y acción. MDR y Sophos X-Ops muestran el número de amenazas bloqueadas, NDR Essentials las amenazas monitorizadas y las fuentes de terceros tanto su estado de sincronización como las amenazas bloqueadas. Configure abre la configuración de la protección, Reports el informe asociado y More details amplía el widget. La acción Reports no aparece en modelos sin informes locales. Una amenaza monitorizada no equivale a una amenaza bloqueada, y un fallo de sincronización de terceros debe distinguirse del número de amenazas.

El widget Reports es un acceso directo a un máximo de cinco informes críticos seleccionados según los módulos suscritos, no una lista completa de eventos en directo. La correspondencia es:

• High-risk applications — Web Protection
• Objectionable websites — Web Protection
• Web users — Web Protection
• Intrusion attacks — Network Protection
• Web server protection — Web Server Protection
• Email usage — Email Protection
• Email protection — Email Protection
• Traffic dashboard — Web Protection o Network Protection
• Security dashboard — Web Protection o Network Protection

High-risk applications, Objectionable websites, Intrusion attacks, Web server protection y Email protection se refieren a ayer; Web users clasifica a los diez usuarios que más bytes web transfirieron ayer. Email usage muestra los bytes de correo transferidos, mientras que Traffic dashboard y Security dashboard resumen las categorías de tráfico y la actividad denegada. La ausencia de un mosaico puede deberse a la suscripción y no a una actividad nula. Hacer clic en el nombre abre el informe y el icono de descarga permite conservarlo. Para conocer los periodos y desgloses independientes de las señales de endpoint, usuario, Zero-day, TLS y sesión, consulte Cómo interpretar User & Device Insights.

Traffic insight resume el tráfico procesado durante las últimas 24 horas. Web activity muestra la tendencia y los bytes medios y máximos transferidos; Cloud applications presenta las aplicaciones detectadas y los bytes de entrada y salida, y al pasar el cursor muestra los estados New, Sanctioned, Unsanctioned y Tolerated. Los demás gráficos clasifican las cinco categorías principales de aplicaciones y web permitidas por bytes, las categorías de aplicaciones bloqueadas por hits y los hosts a los que se denegó el acceso a la red por su estado de seguridad. Hacer clic en un gráfico cloud o una barra de categoría abre la página de Cloud applications o el informe filtrado correspondiente; realizar este desglose antes de considerar un pico o una entrada del top cinco como incidente.

Una revisión diaria incluye al menos:

• servicios detenidos o degradados de forma inesperada;
• enlaces WAN caídos o que cambian de estado repetidamente;
• interfaces productivas con nuevos errores, descartes o colisiones;
• conexiones VPN importantes desconectadas en contra del plan operativo;
• un reinicio inesperado o un tiempo de actividad inusualmente corto;
• mensajes nuevos que aún no tienen responsable ni ticket.

Leer System graphs frente a una línea base

En Diagnostics > System graphs se buscan patrones, no solo picos aislados. La CPU, la memoria y el promedio de carga se evalúan junto con el número de núcleos, el tráfico y el periodo afectado. Un pico breve durante una copia de seguridad, un informe o una actualización de patrones tiene un significado diferente a una carga alta permanente con tráfico normal.

En Disk Usage importa sobre todo la tendencia. Una ocupación alta puntual y un crecimiento continuo son problemas distintos. En las interfaces, el tráfico, los errores, los descartes y las colisiones ayudan a distinguir la carga de la firewall de un problema de enlace, dúplex, cable o switch.

Para obtener pruebas comparables, registrar el tipo de gráfico y el periodo, y usar el mismo periodo en el ticket. Los gráficos de interfaces solo muestran un gráfico independiente para las VLAN de la zona WAN. SFOS combina los datos de las VLAN de otras zonas con el gráfico de su interfaz física principal. Por tanto, no cabe esperar un gráfico LAN VLAN independiente y sin anomalías cuando SFOS no lo ofrece.

La explicación detallada del promedio de carga, el offloading, TLS Inspection y System graphs se encuentra en Interpretar correctamente el rendimiento de Sophos Firewall. Para los límites de almacenamiento y los informes en el dispositivo, consulte Revisar el almacenamiento y los informes de Sophos Firewall.

⚠️ Un único valor alto todavía no justifica reiniciar un servicio. Primero deben coincidir la hora, la duración, el patrón recurrente, el tráfico afectado y los registros. Antes de reiniciar, se guardan los registros relevantes y, en un incidente, un CTR.

Revisar eventos de seguridad e inicios de sesión administrativos

Leer los informes en busca de cambios

La revisión diaria de seguridad se centra en patrones nuevos o que hayan cambiado claramente. Según las funciones activadas, estas áreas son especialmente relevantes:

• Reports > Dashboards > Security dashboard para la visión consolidada;
• Reports > Network & threats > Intrusion attacks para eventos de IPS;
• Reports > Network & threats > Active threat response para IoC bloqueados;
• Reports > Applications & web para el uso web y de aplicaciones arriesgado, no deseado o bloqueado;
• informes de zero-day, Security Heartbeat o Wireless cuando estas funciones se utilicen en producción.

En el informe seleccionado, definir primero el intervalo de fechas y hacer clic en Generate. Filter permite limitar los resultados al origen, la acción o la regla pertinentes. Los formatos de descarga disponibles conservan los datos mostrados como prueba para el ticket. Registrar el periodo y la zona horaria con la exportación para que una comparación posterior no use dos ventanas distintas.

No todos los eventos son incidentes. Son decisivos el origen, el destino, el usuario, la regla, la acción, la frecuencia y la relación temporal. Un único acceso desde un país no justifica bloquear todo el país. En cambio, los ataques repetidos contra un servicio expuesto o un nuevo tráfico de alto riesgo permitido merecen una investigación concreta.

Para evaluar de forma segura los orígenes y países, consulte Bloquear direcciones IP y países maliciosos. Si se ha descartado un paquete, Analizar paquetes descartados en Sophos Firewall lleva desde Log Viewer y Rule ID hasta la causa real del descarte.

Evaluar los inicios de sesión administrativos fallidos

Los inicios de sesión administrativos fallidos se revisan por hora, IP de origen, servicio de destino, nombre de usuario y repetición. Un error de escritura desde la red de administración debe tratarse de forma distinta a intentos distribuidos desde Internet o inicios repetidos en una cuenta desactivada.

Log Viewer se abre desde la esquina superior derecha de cualquier página de WebAdmin y aparece en una nueva ventana a pantalla completa. Seleccionar el módulo adecuado, establecer el periodo con Timer filter y especificar campo, condición y valor con Add filter. La búsqueda de texto libre sirve para direcciones IP, nombres de usuario, puertos o reglas. Antes de realizar más cambios, conservar las entradas filtradas en formato CSV mediante Export; Reset elimina después todos los filtros. La ausencia de una entrada de sesión no siempre demuestra que no hubo tráfico, porque las reglas de firewall normalmente registran las sesiones solo cuando el firewall recibe el evento de destrucción de la conexión.

En intentos sospechosos se revisan primero la exposición y la identidad:

1. ¿Está previsto que WebAdmin, SSH, User Portal o VPN Portal sean accesibles desde la zona afectada?
2. ¿Procede el origen de una red de administración autorizada o de una Local Service ACL Exception específica?
3. ¿Está activo MFA para el acceso administrativo afectado?
4. ¿Funcionan CAPTCHA, el tiempo de espera de sesión y Block login según lo previsto?
5. ¿Hay cambios de configuración simultáneos o inicios de sesión correctos con la misma cuenta?

El acceso de red se revisa en Device Access y Local Service ACL en Sophos Firewall. Para cuentas, perfiles y bajas, consulte Administradores locales y perfiles de acceso al dispositivo, y para el segundo factor, Activar MFA en Sophos Firewall.

⚠️ Block login puede bloquear la IP de origen para varios servicios tras intentos fallidos. No endurecer los valores de forma agresiva durante un incidente mientras no exista una vía alternativa y probada de administración y recuperación.

Entender los límites de HA, informes y modelos

En un clúster HA, cada nodo guarda únicamente los registros y los informes del tráfico que él mismo ha procesado. Por tanto, en un evento se identifica el nodo que estaba activo o que procesaba el tráfico en ese momento. Un informe local vacío en un nodo no demuestra que no hubiera ningún evento en el clúster.

Central Firewall Reporting en Sophos Fusion (antes Sophos Central) puede ofrecer una vista consolidada y una retención más larga. Sin embargo, las vistas local y central no se consideran fuentes idénticas en tiempo real. Activar y operar Central Firewall Reporting explica la selección, la llegada y la retención de registros.

Límites adicionales:

• Los informes de Control Center se actualizan periódicamente y no son una vista de eventos en tiempo real.
• Tras actualizar desde SFOS 20.0 o una versión anterior a SFOS 21.0 o posterior, el widget Reports puede mostrar cero o un valor inferior hasta la siguiente actualización de 24 horas porque Sophos almacena los informes anteriores y posteriores a la actualización en bases de datos separadas.
• XGS 87/87w y XGS 88/88w no admiten informes en el dispositivo. Por ello, los registros centrales, SIEM y la monitorización son más importantes en estos modelos.
• La falta de datos puede deberse al logging, al periodo del informe, a la licencia, a la retención, al disk watermark o al nodo HA equivocado. No demuestra automáticamente que no hubiera tráfico.

Comparar la compilación del firmware con los problemas conocidos

Cuando la observación no coincide con el estado esperado, siga el runbook de Avanet para decisiones de firmware. Compare la compilación instalada exacta y el síntoma concreto, no solo la versión principal. Registre en el ticket el ID del problema, las compilaciones afectadas y corregidas y cualquier workaround, y correlacione el resultado con los detalles de Control Center, los System graphs, los logs y una prueba funcional antes de modificar el sistema. Ejemplos para la revisión diaria:

• NC-181971: en SFOS 22.0 GA y versiones posteriores, el servicio IPS puede, en raras ocasiones, pasar al estado Dead y no volver a iniciarse. Sophos no publica una solución de autoservicio e indica que se contacte con Soporte para aplicarla.
• NC-181748: en SFOS 22.0 GA Build 411, no se generan correos Web Instant Alert para categorías bloqueadas por políticas web. En esta compilación, la ausencia de una alerta no demuestra que no se produjera un bloqueo.
• NC-180066, NC-180110, NC-178745 y NC-172912: las notas de la versión enumeran correcciones en SFOS 22.0 MR2 Build 546 para servicios antivirus detenidos, modo failsafe causado por el daemon de registro, reinicios de HA por falta de memoria y parpadeo de los System graphs. Si el síntoma coincide en una compilación anterior, registrar en el ticket el ID y la ruta de actualización. Actualizar el firmware solo en una ventana de mantenimiento aprobada, con copia de seguridad y vía de reversión.

Los problemas conocidos pueden cambiar independientemente de este artículo. Antes de escalar, volver a abrir la entrada y conservar su estado actual. Un ID coincidente puede explicar un síntoma, pero no sustituye la evaluación del impacto ni la verificación funcional.

Documentar y escalar desviaciones

Una revisión diaria solo termina cuando las desviaciones relevantes tienen un siguiente paso. Para un ticket o diario operativo suelen bastar estos campos:

• fecha, hora y zona horaria;
• nombre de la firewall, modelo, versión de SFOS y build;
• en HA: nodo, rol y último cambio de estado;
• función, zona, interfaz, VPN o regla afectada;
• estado observado y estado esperado;
• captura de pantalla, periodo del informe, filtro de registros o Rule ID;
• impacto sobre usuarios o servicios;
• responsable, prioridad, siguiente revisión y vía de escalación.

Antes de cualquier acción que cambie el estado, conservar el estado detallado de Control Center, el gráfico con el periodo visible y las líneas de registro filtradas o la exportación CSV. Para un caso de soporte, ir a Diagnostics > Tools > Consolidated troubleshooting report y crear un CTR con System snapshot y los archivos de registro necesarios: introducir el motivo, seleccionar Generate y descargar el archivo cifrado al finalizar. El modo de depuración y la purga de registros no forman parte de la revisión diaria: alteran el estado de diagnóstico o destruyen pruebas y solo deben usarse de forma deliberada siguiendo las indicaciones de Soporte.

Conviene escalar de inmediato si un enlace WAN productivo o una ruta VPN crítica falla de forma inesperada, se detiene un servicio de protección, sigue aumentando la ocupación del disco, la carga permanece alta, los ataques administrativos repetidos coinciden con un inicio de sesión correcto o un nuevo evento de seguridad corresponde a tráfico malicioso permitido.

La observación suele bastar ante un pico breve y explicable, una interfaz sin uso intencionadamente o un evento conocido que ya tenga un responsable documentado y una verificación funcional estable.

Elegir una frecuencia de revisión útil

Sophos no prescribe una frecuencia diaria universal para todas las vistas. Por tanto, la frecuencia depende del riesgo, el horario operativo y la monitorización existente:

• A diario o en cada turno: mensajes nuevos, servicios detenidos, WAN/VPN/HA, tiempo de actividad, eventos críticos de seguridad e inicios de sesión administrativos fallidos.
• Semanalmente: tendencias de gráficos, errores de interfaces, crecimiento del disco, patrones de informes, orígenes recurrentes y tickets abiertos.
• Después de cambios, actualizaciones o failover: volver a validar la función afectada, los registros, los informes, la ruta de alertas y el tráfico real.
• Regularmente fuera de la revisión breve: Health Check, revisión de reglas, prueba de restauración de copias, caducidad de licencias y certificados y planificación de capacidad.

Las notificaciones por correo electrónico o la monitorización acortan el tiempo de respuesta, pero no sustituyen la revisión. Una ruta de alertas solo es fiable cuando se han probado el transporte, la selección de eventos, el destinatario y la reacción. El procedimiento completo se encuentra en Configurar y probar las notificaciones por correo de Sophos Firewall.

Lista de comprobación operativa

• Revisar Control Center para detectar mensajes nuevos y cambios de estado inesperados.
• Comparar los servicios, enlaces WAN productivos, interfaces, VPN y tiempo de actividad con el estado esperado.
• Leer la CPU, la memoria, el promedio de carga, el disco y los contadores importantes de interfaces frente a la línea base.
• Revisar los informes de seguridad del último periodo completamente disponible.
• Definir el periodo del informe, seleccionar Generate y exportar los resultados destacados cuando sea necesario.
• En Log Viewer, seleccionar el módulo, Timer filter y Add filter; correlacionar origen, destino, usuario, acción y Rule ID, y conservar las líneas relevantes en CSV.
• Evaluar los inicios de sesión administrativos fallidos por origen, servicio y repetición.
• En HA, tener en cuenta el nodo que procesó el tráfico y los registros locales de cada nodo.
• Comparar la compilación y el síntoma coincidente con las notas de la versión y los problemas conocidos actuales; registrar el ID en el ticket.
• No provocar reinicios, borrados de registros ni cambios amplios de reglas sin conservar pruebas y una vía de recuperación.
• Documentar cada desviación relevante con responsable, prioridad y siguiente paso.
• Tras una corrección, volver a probar no solo el estado, sino también el funcionamiento real.

FAQ