Asignar logs de servicio de Sophos Firewall

En Sophos Firewall hay tres niveles importantes para la solución de problemas: los registros de eventos en el Log viewer, herramientas de diagnóstico en WebAdmin y archivos de servicio o log en el firewall. El Log Viewer es ideal para preguntas rápidas como “¿se permitió o bloqueó la conexión?”. Los archivos en /log son más importantes cuando un servicio no se inicia, un túnel VPN es inestable, los filtros web actúan inesperadamente o el soporte necesita datos detallados.

Este artículo clasifica los servicios y archivos de registro más importantes según problemas típicos de administración. También es útil cuando en el panel de control, en la Advanced Shell o en un caso de soporte aparece un nombre técnico de servicio y no está claro de inmediato qué función del firewall está detrás. Nombres como zebra, warren, awed, garner o strongswan no son autoexplicativos en la vida cotidiana.

Selección de herramienta y requisitos previos

Antes de buscar en archivos de log, debe estar claro qué herramienta ofrece la respuesta más rápida. Muchos casos ya pueden delimitarse con Log Viewer o Packet Capture. La shell solo resulta realmente útil cuando hay que comprobar un servicio en sí o cuando soporte necesita datos de log detallados.

¿Qué herramienta de solución de problemas es adecuada?

No todos los problemas del firewall comienzan con una shell. A menudo, otra herramienta es más rápida al principio:

• ¿Conexión permitida o bloqueada? Probar regla de firewall con Log Viewer, Policy Test y Packet Capture.
• ¿Todo Log Viewer ha dejado de mostrar eventos nuevos? Revisar filtros, logging y el workaround de Garner específico de la build.
• ¿Se ha reiniciado inesperadamente todo el firewall? Primero clasificar el reinicio como reboot del appliance, failover HA o fallo de un servicio y después guardar sysinit.log, syslog.log y el CTR.
• ¿Los paquetes llegan, pero no está claro si continúan? Usar Sophos Firewall Packet Capture en WebAdmin.
• ¿La captura debe durar más, guardarse como PCAP o analizarse en Wireshark? Sophos Firewall tcpdump: capturar paquetes por CLI.
• ¿Se sospecha una modificación de configuración como causa? Revisar Sophos Firewall Audit Trail Logs.
• ¿Una modificación desde Sophos Fusion (antes Sophos Central) está atascada? Revisar Sophos Fusion Firewall Task Queue.
• ¿Se necesitan informes o historial en Sophos Fusion? Activar y operar Sophos Firewall Central Reporting.
• ¿Los logs deben ir a largo plazo a SIEM, SOC o servidor de logs? Enviar Syslog de Sophos Firewall a SIEM.
• ¿El foco son los flujos de tráfico, los picos de ancho de banda o los patrones de comunicación? Configurar la monitorización sFlow en Sophos Firewall.
• ¿Un servicio no funciona o soporte necesita logs? Este artículo.
• ¿Guardar logs locales para Sophos Support o Avanet? Asegurar registros de Sophos Firewall para soporte y análisis.
• ¿Preparar un caso de soporte? Abrir un ticket de soporte de Sophos: Preparación y portal.

El orden es importante. Log Viewer suele mostrar más rápido qué regla o módulo tomó la decisión. Packet Capture demuestra el flujo de paquetes en WebAdmin. tcpdump es útil cuando se necesita una captura más larga, un archivo PCAP o un filtro CLI muy preciso. Los registros de servicio y depuración ayudan cuando un servicio específico es el problema o cuando se deben recopilar datos para Sophos Support.

Entrada rápida por síntoma

Si no está claro qué log es relevante, ayuda empezar por el síntoma en lugar del nombre del servicio.

• Una conexión individual no funciona: primero revisar Log Viewer con origen, destino, servicio y hora. Después usar Packet Capture, firewall_rule.log y nat_rule.log.
• El túnel VPN está inactivo o inestable: revisar el estado de la VPN, la IP del peer, la hora y Log Viewer. Después consultar strongswan.log, charon.log, sslvpn.log y los datos de diagnóstico de IPsec.
• WebAdmin, User Portal o SSH no son accesibles: revisar Device Access, Local Service ACL y la zona afectada. Después usar apache.log, tomcat.log, sshd.log y Packet Capture sobre el puerto de destino.
• Webfilter, TLS Inspection o IPS bloquean inesperadamente: revisar módulo de Log Viewer y Policy ID. Después comparar ips.log, awarrenhttp.log y Packet Capture.
• Una tarea de Sophos Fusion queda atascada: comparar Central Task Queue y estado local. Después revisar centralmanagement.log, sophos-central.log y fwcm-api-executor.log.
• HA se comporta de forma distinta según el nodo: identificar el nodo activo, el nodo auxiliar y la ruta de tráfico afectada. Después iniciar sesión directamente en el nodo afectado y revisar los registros de HA.
• Faltan informes locales o el almacenamiento se llena: revisar los ajustes de informes, el espacio disponible y Central Reporting. Después usar reportdb.log, garner.log y el análisis de almacenamiento.

Esta vista evita una trampa habitual: buscar en un registro de servicio aunque primero habría que comprobar la coincidencia de reglas, Device Access, NAT o el enrutamiento.

¿Log Viewer o archivo de registro?

El Log viewer se abre en la consola WebAdmin en la parte superior derecha. Se actualiza automáticamente, se puede filtrar por módulo, tiempo, valores de campo y texto libre, y puede exportar registros como CSV.

Para proteger nombres de usuario y direcciones IP, MAC y de correo en la vista diaria de logs se puede utilizar Data Anonymization para logs e informes locales. Su efecto en Log viewer no demuestra automáticamente que los archivos en /log, CTR, Remote Syslog o Central anonimicen las mismas identidades; cada ruta de salida se comprueba por separado.

Los registros de solución de problemas se encuentran en el directorio /log. La ruta documentada oficialmente pasa por la CLI: iniciar sesión, elegir 5 Device Management y después 3 Advanced Shell. SSH suele resultar más cómodo para sesiones largas con tail, grep o less. Su preparación segura se describe en Conectar Sophos Firewall por SSH.

Antes de sesiones largas en la shell, debe estar claro desde qué red de administración se conecta, si se ha verificado la huella digital SSH y si realmente se necesita la Advanced Shell. Para muchas verificaciones iniciales, el Log Viewer o Packet Capture en WebAdmin son suficientes.

Como regla general, esta es la secuencia:

1. Un flujo de tráfico individual está afectado: filtrar en Log Viewer por origen, destino, servicio y hora.
2. Log Viewer no muestra decisión: iniciar Packet Capture con filtro estrecho.
3. Packet Capture muestra Incoming, pero no una decisión clara: revisar Rule ID, NAT ID, Firewall ID 0, ruta de retorno y log adecuado.
4. Un servicio concreto parece inestable: observar el archivo adecuado en /log con tail -f.
5. Un error es esporádico o necesita soporte: preparar ventana temporal, filtro, archivo de logs y, si procede, tcpdump.
6. Los logs normales no bastan: activar Debug solo para el servicio afectado y durante poco tiempo.

Esto mantiene el análisis lo suficientemente pequeño. Primero se recopila la evidencia visible, luego se cambia al flujo de paquetes y solo después a los registros de servicio o depuración. Esto reduce el riesgo de activar registros de depuración amplios demasiado pronto o evaluar un archivo de registro incorrecto.

Leer archivos de registro en la Advanced Shell

Antes de buscar en /log, el caso de prueba debe estar documentado lo más estrechamente posible: hora local, IP de origen afectada, IP de destino, puerto, usuario, módulo y comportamiento esperado. Estos datos marcan la diferencia entre un análisis de registros útil y una búsqueda larga a través de entradas antiguas.

1. Iniciar sesión en la CLI, elegir 5 Device Management y después 3 Advanced Shell.
2. Cambiar al directorio de registros.

cd /log

Comandos útiles:

tail -f firewall_rule.log
tail -f nat_rule.log
grep -i error ips.log
less strongswan.log
service -S | grep ips

Los comandos más importantes de la Advanced Shell:

• Leer en vivo: tail -f /log/<logfilename>.log, por ejemplo tail -f /log/ips.log.
• Leer un archivo estático: less /log/<logfilename>.log, por ejemplo less /log/ips.log.
• Buscar un término: grep <keyword> /log/<logfilename>.log, por ejemplo grep error /log/ips.log.
• Leer el estado de un servicio: usar service -S o limitarlo a un nombre, por ejemplo service -S | grep ips. Esta comprobación no modifica el servicio.

Para soporte o un análisis posterior, no solo se deben copiar líneas individuales de registro. Es mejor tener un rango de tiempo claro, la prueba reproducida, capturas de pantalla relevantes de Log Viewer o Packet Capture y, si es necesario, un archivo de registro completo. Los registros locales rotan; por lo tanto, los datos importantes deben asegurarse mientras el evento aún está dentro del período afectado. El procedimiento se describe en Asegurar registros de Sophos Firewall para análisis externo.

Descargar troubleshooting logs en WebAdmin

No toda recopilación debe montarse manualmente en Advanced Shell. WebAdmin reúne los archivos en Diagnostics > Tools.

En la práctica hay dos caminos:

• Archivos de log individuales: abrir Diagnostics > Tools > Troubleshooting logs, seleccionar los logs afectados y descargarlos como archivo comprimido.
• Consolidated Troubleshooting Report (CTR): usar Diagnostics > Tools > Consolidated troubleshooting report cuando soporte necesita todos los logs más estado del sistema, procesos y datos de recursos en un solo paquete.

Esto resulta práctico cuando basta un paquete de registros bien delimitado. El CTR es mejor cuando Sophos Support necesita una instantánea amplia del sistema. Debe indicarse un motivo claro, como el número de ticket, el intervalo temporal o el síntoma. El informe se descarga cifrado; su nombre también contiene el número de serie del firewall, por lo que no debe incluirse en adjuntos públicos.

De forma predeterminada, un CTR contiene 10.000 líneas por cada service subsystem log. En Device Console el valor solo puede fijarse entre 250 y 10.000, por lo que únicamente se puede reducir respecto al valor predeterminado. Los default subsystem logs incluyen todas sus líneas. Este límite se aplica solo al CTR; los archivos individuales completos siguen disponibles mediante Troubleshooting logs o Advanced Shell.

Importante: un paquete de logs descargado no sustituye los datos de contexto. Soporte sigue necesitando hora con zona horaria, IPs afectadas, usuario, nombre del túnel, Rule ID, NAT ID y una breve descripción de lo que se reprodujo exactamente.

En clústeres HA hay que tener en cuenta además: los logs e informes no se sincronizan simplemente entre Primary y Auxiliary. Cada nodo contiene los logs del tráfico y de los servicios que ha procesado él mismo. En errores específicos de un nodo, por tanto, debe revisarse el nodo afectado.

Entender la rotación de logs y los datos volátiles

Los Troubleshooting Logs se crean primero en memoria y la firewall los copia al sistema de archivos. Si la firewall deja de responder, pueden perderse entradas que todavía no se hayan copiado. Por tanto, un reinicio inesperado o un bloqueo no justifican retrasar la conservación de evidencias; primero se guardan CTR, logs y cronología disponibles.

Cada subsistema tiene límites propios de tamaño de archivo y almacenamiento según su criticidad y el modelo de appliance. Cuando el archivo activo alcanza el límite, SFOS lo comprime como .gz y sigue escribiendo con el nombre original. Cuando también se alcanza el límite de rotaciones del subsistema, elimina primero el archivo comprimido más antiguo. Por eso, el número de rotaciones y el historial disponible no son iguales en todos los servicios.

Los archivos de log y las rotaciones .gz no se renombran ni eliminan manualmente. Para el análisis de espacio, la exportación y los comandos de purge documentados se aplica el flujo de Gestionar el almacenamiento y los reports de forma segura.

Advanced Shell o Device Console?

En Sophos Firewall hay dos áreas de consola diferentes que a menudo se confunden:

• Device Console: CLI de Sophos para comandos específicos del firewall, por ejemplo prioridad de enrutamiento, rutas IPsec u opciones del sistema.
• Advanced Shell: shell cercana a Linux para el sistema de archivos, los logs y comandos de solo lectura como tail, grep, less y service -S.

No todos los comandos funcionan en ambas áreas. /log, tail -f, grep y service -S corresponden a Advanced Shell. Los comandos documentados system diagnostics ... para límites de CTR, purga de logs y depuración de subsistemas corresponden a Device Console.

Esta distinción es importante porque muchos errores solo ocurren porque un comando correcto se ingresa en el lugar incorrecto.

El registro debe estar activo

No toda la información esperada aparece automáticamente.

• En las reglas de firewall, Log firewall traffic debe estar activo.
• En las reglas de inspección SSL/TLS, el registro debe estar activado.
• En System services > Log settings debe definirse qué tipos de registro se envían localmente, a Sophos Fusion o a Syslog.

Para almacenamiento a largo plazo, un servidor Syslog o Sophos Central Firewall Reporting son útiles. Cómo conectar servidores de registro externos o un SIEM se describe en Enviar Syslog de Sophos Firewall a SIEM. Para Sophos Fusion, Activar Central Firewall Reporting es el procedimiento adecuado.

Activar depuración solo de manera dirigida

El registro de depuración genera muchos más datos, consume espacio y puede capturar contenido confidencial. Por eso no es un primer paso razonable. Primero se fijan el log normal, el intervalo temporal y la prueba reproducible; la depuración se usa solo para el subsistema afectado y durante el tiempo imprescindible.

Sophos documenta dos métodos distintos. La forma de Advanced Shell service <service>:debug -ds nosync conmuta el estado y no admite un argumento separado on u off. Para un subsistema de servicio compatible deben preferirse los comandos explícitos de Device Console documentados por Sophos: system diagnostics subsystems <subsystem> debug on, reproducir el problema y recopilar los datos, y después ejecutar system diagnostics subsystems <subsystem> debug off. Por ejemplo, el nombre de subsistema para la depuración de Packet Capture es Pktcapd. La depuración está desactivada de forma predeterminada, pero antes de cambiarla hay que confirmar que ningún otro administrador ni Sophos Support esté recopilando datos. Registrar el cambio y comprobar al final que la depuración está desactivada.

Tratar la depuración del controlador del sistema CSC como un conmutador independiente

SFOS 22 documenta un comando de Device Console independiente para el controlador del sistema (CSC):

system diagnostics subsystems CSC debug

A diferencia de la sintaxis del subsistema de servicio anterior, este comando no tiene argumento on ni off: cada ejecución conmuta la depuración CSC. Debe tratarse como un cambio controlado, no como una consulta de estado:

1. Comprobación previa: Confirmar con los demás administradores y Sophos Support que la depuración CSC no esté ya activa ni forme parte de una recopilación en curso. Registrar firewall o nodo HA, hora, motivo y ventana de recopilación prevista. Conservar una copia de referencia del log CSC relevante antes del cambio. No ejecutar el conmutador solo para averiguar su estado.
2. Activar y reproducir: Ejecutar el comando exactamente una vez en Device Console. Reproducir únicamente el problema delimitado y anotar la hora de prueba con zona horaria.
3. Conservar las pruebas: Antes del rollback, descargar el log de troubleshooting individual relevante o generar el CTR y descargar el archivo CTR completado. Restringir el acceso al CTR cifrado y a cualquier archivo de logs porque pueden contener datos confidenciales; no purgar ni sobrescribir las pruebas necesarias para el caso.
4. Desactivar / rollback: Volver a Device Console y ejecutar exactamente una vez el mismo comando. Esta segunda ejecución planificada vuelve a desactivar la depuración CSC.
5. Verificar: Realizar una prueba controlada breve y confirmar en las nuevas líneas del log CSC que ha cesado la salida de nivel debug y que el crecimiento del log ha vuelto a su ritmo normal. Registrar la hora y el resultado del rollback. Si el estado inicial o la comprobación posterior son ambiguos, no repetir el conmutador; detenerse y coordinar el estado con Sophos Support.

⚠️ Depuración WAF y reverseproxy.log: Sophos corrigió con SFOS 22.0 MR2 Build 546 el error NC-177457, por el que una contraseña era visible en reverseproxy.log cuando la depuración WAF estaba activada. Sophos no indica ni el inicio del intervalo de versiones afectadas ni el tipo de contraseña. Por eso, los logs de depuración WAF, archivos de troubleshooting y ficheros CTR ya generados en builds anteriores o desconocidos deben tratarse como si pudieran contener credenciales.

Si se encuentra una credencial en texto claro: limitar el acceso, documentar el incidente y rotar la credencial afectada. No eliminar los logs de forma indiscriminada antes de aclarar los requisitos de soporte, análisis forense y conservación.

El tema del registro de depuración y los comandos básicos de CLI se describen con más detalle en el artículo Solución de problemas de CLI de Sophos Firewall: comandos importantes. Para reiniciar servicios individuales, también es útil Reiniciar servicios de Sophos Firewall de manera segura.

Errores típicos en la búsqueda de registros

Muchos análisis de registros no se alargan por falta de datos, sino porque se busca demasiado pronto en la herramienta incorrecta.

• Activar Debug directamente: primero revisar Log Viewer, log adecuado y prueba reproducible.
• Buscar solo mensajes de error: además delimitar Source, Destination, User, Rule ID, NAT Rule ID y hora.
• Ignorar Packet Capture: si no está claro si los paquetes llegan o continúan, usar Packet Capture pronto.
• Entender Central Reporting como depuración en tiempo real: usar Central Reporting para el historial y los informes, y los registros locales para el análisis detallado.
• Asegurar logs de soporte días después: asegurar logs, hora y pasos de reproducción mientras el evento aún es rastreable.
• Dejar Debug activo tras la prueba: desactivar Debug de nuevo y controlar espacio de almacenamiento.

Un buen caso de solución de problemas siempre tiene tres cosas: una prueba estrecha, la fuente de registro adecuada y una hora documentada. Sin esta base, se pueden ver muchas líneas de registro, pero no necesariamente la causa.

Archivos de registro por área funcional

Las siguientes listas sirven como referencia. Lo mejor es seleccionar primero el área funcional afectada y después revisar el log adecuado con una ventana temporal estrecha.

Las asignaciones principales siguen la documentación actual de SFOS 22.0. En instalaciones antiguas o archivos de soporte anteriores también pueden aparecer los nombres utilizados previamente app-feedback.log, sig_update.log, sessiontbl.log, webproxy.log, fqdndebug.log, ipsec_Test_Connect.log, redis, hotspot.log, awarrenmta_debug.log, smbnetfs.log, snireport.log, confdbstatus.log y crreportdb.log. Sophos ya no los incluye en la lista actual de logs de SFOS 22.0, por lo que no deben darse por supuestos en un build actual.

Sistema, gestión y servicios básicos

• Inicio del sistema: sysinit.log; comprobarlo primero ante problemas de arranque y Failsafe.
• Mensajes del sistema: syslog.log; revisar además la hora, los reinicios y los eventos de las interfaces.
• Servidor web de WebAdmin: apache.log, apache_access.log; revisar además Device Access y Local Service ACL.
• Aplicación WebAdmin: tomcat.log; revisar además errores de GUI, alta carga y estado del servicio.
• SSH: sshd.log; revisar además Device Access, la red de origen y el inicio de sesión con clave pública.
• Errores GUI/CLI: error_log.log; revisar además los cambios recientes, el navegador y las acciones del administrador.
• Cambios de configuración: applog.log, csc.log; revisar además Audit Trail y Config Studio.
• Base de datos de configuración: postgres.log; revisar además el almacenamiento, la copia de seguridad/restauración y el caso de soporte.
• Canal de comunicación entre determinados componentes y sus servicios: garner.log; para Central Management y reporting, comprobar también las entradas de los plugins correspondientes.
• API: apiparser.log; revisar además validation.log, API ACL, token y Central Task Queue.
• Validación: validation.log, validationError.log; revisar además objetos defectuosos o importaciones.
• Licenciamiento: licensing.log; revisar además estado de licencia, Central Sync y caso especial Air-Gap.
• Actualizaciones del sistema: u2d.log; revisar además el estado de los patrones, DNS/HTTPS y el espacio de almacenamiento.

En problemas de gestión no se debe revisar solo el log de WebAdmin. Muy a menudo Device Access, una Local Service ACL Exception Rule o una red de origen incorrecta deciden si WebAdmin, SSH, User Portal, VPN Portal, DNS o SNMP son accesibles. Para esta parte, Asegurar el acceso a Sophos Firewall: Configurar correctamente el Device Access es el mejor punto de entrada.

Firewall, NAT y Packet Capture

• Coincidencia de reglas de firewall: firewall_rule.log; revisar además el módulo Firewall en Log Viewer.
• Procesamiento general de firewall: fwlog.log; usar además Packet Capture.
• Reglas NAT: nat_rule.log; revisar además NAT Rule ID en Log Viewer.
• DNAT con Link Load Balancing: revisar además dgd.log cuando interviene la selección de gateway o enlace.
• Packet Capture en WebAdmin: pktcapd.log; revisar además Diagnostics > Packet capture.
• Bandwidth Management / QoS: bwm.log; revisar además Traffic Shaping Policy.
• Virtual Host / publicación de servidor antigua: vhost.log; revisar además NAT y WAF.
• Web Server Protection / WAF: reverseproxy.log; revisar además regla WAF, Hosted address y accesibilidad del backend.

En problemas de DNAT, siempre verificar la regla de firewall y la regla NAT juntas. NAT solo traduce, pero no permite tráfico. Más información: Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT.

Sophos Firewall utiliza, entre otros, IP tables, ARP table, IPset y conntrack para conexiones de firewall. Para QoS o gestión de ancho de banda se utiliza IMQ. Esta información es útil cuando se ven mensajes de registro o salidas de soporte con términos técnicos del camino de red de Linux.

IPS, Application Control e Inspección TLS

• Intrusion Prevention: servicio ips, registro ips.log.
• Application Control: servicio ips / Application Filter, registro ips.log.
• DPI y TLS Inspection: motor DPI, registro ips.log.
• Antivirus en la ruta de red: servicio avd, registro avd.log.
• Zero-Day Protection / Sandbox: servicio Sandbox, registro sandboxd.log.
• Active Threat Response / X-Ops Threat Feeds: ATR en la ruta de red; primero Log Viewer, según módulo además ips.log.
• MDR Threat Feeds: ATR / estado del feed MDR, registro atr.log; la guía operativa correlaciona Audit ID, Task Queue y la prueba de tráfico local.
• Actualizaciones de firmas: actualizador de firmas, registro sig_upgrade.log.
• Migración de firmas: migración de firmas, registro sigmigration.log.

Muchas funciones de protección modernas solo ven suficientes detalles cuando HTTPS se descifra. Si la inspección TLS no se aplica, los filtros web, el control de aplicaciones, IPS y el escaneo de malware son menos significativos según el tráfico.

Si no está claro si IPS está activo, qué política se aplica o por qué una firma bloquea, primero ayuda Configurar y probar Sophos Firewall IPS de manera segura. Luego se pueden combinar ips.log, Log Viewer y Packet Capture de manera más dirigida.

Si se trata de reconocimiento de aplicaciones, filtro de aplicaciones o bloqueos inesperados de control de aplicaciones, primero se debe usar Configurar y probar Sophos Firewall Application Control.

Para Zero-Day Protection conviene comprobar además si Web Protection, TLS Inspection, el tipo y el tamaño del archivo, la política y la acción encajan. El artículo operativo adecuado es Comprender y operar Sophos Firewall Zero-Day Protection. Para Threat Feeds encaja Configurar y operar Sophos Firewall Threat Feeds de forma segura. Más sobre TLS Inspection: Implementar inspección TLS en Sophos Firewall paso a paso.

Web, Proxy, WAF y filtro web

• HTTPS Proxy: servicio awarrenhttp, registro awarrenhttp.log.
• Acceso del proxy HTTPS: registro de acceso de awarrenhttp, archivo awarrenhttp_access.log.
• Categorización/reputación web: servicio nSXLd, registro nSXLd.log.
• Proxy HTTP/FTP heredado: servicio skein, registro skein.log.
• Proxy FTP: servicio ftpproxy, registro ftpproxy.log.
• Web Application Firewall: proxy inverso, registro reverseproxy.log.

Ante un posible bucle de proxy, block_proxy_loop junto con el debug de awarrenhttp activado brevemente puede generar Duplicate Via header values, proxy loop. Comprobar de forma segura los ajustes HTTP Proxy explica el requisito, el efecto global y la reversión segura. El debug solo permanece activo durante la prueba reproducible.

Si el tráfico web aparece como bloqueado en el Log Viewer, la causa puede estar en varios módulos: política web, inspección SSL/TLS, control de aplicaciones, IPS o WAF. Por lo tanto, siempre seleccione el módulo específico en el Log Viewer y verifique además el archivo de registro adecuado.

Sophos bloquea sitios web de la categoría highly objectionable criminal activity de manera predeterminada y oculta el nombre de dominio en registros e informes. Si una entrada en esta área parece intencionalmente anonimizada, esto puede ser deliberado.

Para categorías web, grupos de URL, políticas web y alertas instantáneas, consulte Usar categorías web y alertas instantáneas en Sophos Firewall.

VPN

• IPsec desde SFOS v17+: servicios strongswan, charon; registros strongswan.log, charon.log.
• IPsec específico de conexión: una IPsec Connection concreta, log /log/ipsec_conn/ipsec_<connectionname>.log.
• IPsec en versiones anteriores: servicio IPsec, registro ipsec.log.
• IPsec Monitoring: IPsec Monitor, log ipsec_monitor.log.
• XFRM / VPN basada en rutas: servicio xfrmi, registro xfrmi.log.
• SSL VPN: SSL VPN / OpenVPN, log sslvpn.log.
• SSL VPN Status: OpenVPN Status, log openvpn-status*.log.
• VPN Portal: log vpnportal.log.
• L2TP: servicio l2tpd, registro l2tpd.log. L2TP Remote Access en Sophos Firewall explica la configuración y el diagnóstico.
• PPTP: PPTP VPN, log pptpvpn.log.
• Certificados VPN: servicios de certificados VPN, registro vpncertificate.log.
• Clientless SSL VPN: Clientless Access, log clientless_access.log.

Sophos Firewall utiliza strongSwan para IPsec VPN y OpenVPN para SSL VPN. En problemas de IPsec, son cruciales la hora, IP del par, propuesta, subredes locales/remotas, NAT-T, enrutamiento y reglas de firewall.

Para problemas de IPsec, el artículo Solución de problemas de IPsec en Sophos Firewall es la mejor guía paso a paso. Si se trata de VPN basado en rutas y rutas IPsec manuales, ayuda Crear ruta IPsec en Sophos Firewall.

Autenticación, User Portal y SSO

• Autenticación de usuario: Access Server / AAA, log access_server.log.
• NTLM / NASM: servicio nasm, registro nasm.log.
• Chromebook SSO: Chromebook SSO Backend, log chromebook-sso-backend.log.
• OAuth SSO Captive Portal: log oauth_sso_captive.log.
• OAuth SSO WebAdmin: log oauth_sso_webadmin.log.
• OAuth SSO VPN: log oauth_sso_vpn.log.
• RADIUS SSO: Asociación de usuario e IP mediante accounting en access_server.log. RADIUS SSO con accounting explica la configuración y validación.
• STAS: STAS / contexto de Access Server, según contexto de servicio y access_server.log.

En reglas de usuario, siempre hay que comprobar primero si el usuario es conocido. Si Match known users está activo y la autenticación no funciona, la regla no coincide. Para los logins clásicos en el navegador, Configurar y probar Captive Portal en Sophos Firewall combina Device Access, la regla de usuario, Live users, Log Viewer y access_server.log en un procedimiento de diagnóstico completo.

Si todavía no está claro si falla la selección del servicio, la identidad, la Main Group, la cuota o solo el posterior recorrido del tráfico, Solucionar sistemáticamente los errores de autenticación en Sophos Firewall reúne estas capas en un único procedimiento de diagnóstico.

Si se utiliza el portal cautivo con Microsoft Entra ID SSO, Configurar Microsoft Entra ID SSO para el portal cautivo de Sophos Firewall ayuda a verificar oauth_sso_captive.log, Device Access, grupos y coincidencia de reglas posterior.

DNS, DHCP y red

• Servicio DNS: servicio dnsd, registro dnsd.log.
• DNS Grabber: servicio dnsgrabber, registro dnsgrabber.log.
• Entidad DNS / otros componentes DNS: servicios entity, eacd; registros entity.log, eacd.log.
• DHCP IPv4: servicio dhcpd, registro dhcpd.log.
• DHCP IPv6: log dhcpd6.log.
• Servicio de red: servicio networkd, registro networkd.log.
• Hosts FQDN: servicio fqdnd, registro fqdnd.log.
• Dead Gateway Detection: servicio dgd, registro dgd.log.
• Dynamic DNS: Dynamic DNS Client, log ddc.log.
• NTP Client: log ntpclient.log.
• IPv6 Router Advertisement: servicio radvd, registro radvd.log.

Los problemas de DNS y DHCP a menudo parecen problemas de firewall. Por lo tanto, primero se deben verificar la dirección IP, la puerta de enlace, el servidor DNS y si los clientes deben usar el firewall como servidor DNS o DHCP.

Si los dominios internos no se resuelven correctamente, generalmente es relevante Configurar rutas de solicitud DNS en Sophos Firewall. Para opciones especiales de DHCP, hay un artículo propio Configurar opciones DHCP en Sophos Firewall.

WAN celular

• WWAN / módem USB: revisar conexión y desconexión de dispositivos USB en modemd.log.
• Configuración de red del módem: revisar interfaces relacionadas con el módem y configuración IP en networkd.log.
• USB, módem y PPP: revisar mensajes de Syslog sobre USB, módem y Point-to-Point Protocol en syslog.log.

En problemas de WAN celular, también se debe verificar si se reconoce el módem, si PIN/SIM/APN son correctos y si el firewall crea una puerta de enlace adecuada.

Enrutamiento

• Rutas unicast estáticas: archivo de log staticd.log. Configurar y probar una ruta estática en Sophos Firewall explica la configuración y la comprobación.
• Instalación de rutas unicast IPv4 estáticas: servicio zebra, archivo de log zebra.log.
• Enrutamiento basado en aplicaciones: servicio appcached, registro appcached.log.
• Enrutamiento multicast: log mrouting.log.
• BGP: servicio bgpd, registro bgpd.log. La configuración y validación de BGP en Sophos Firewall explica el procedimiento; zebra.log también ayuda a comprobar si una ruta aprendida se instaló en el sistema.
• OSPFv2 y OSPFv3: servicios ospfd y ospf6d, registros ospfd.log y ospf6d.log. El archivo adicional zebra.log muestra si la ruta dinámica se ha instalado en el sistema. La configuración y validación de OSPF en Sophos Firewall explica el procedimiento.
• RIP: servicio ripd, registro ripd.log. Configurar y validar RIPv2 en Sophos Firewall explica la configuración y la validación; zebra.log también muestra si una ruta aprendida se instaló en el stack de routing.
• PIM-SM: servicio pimd, registro pimd.log. Configurar y validar PIM-SM en Sophos Firewall explica la configuración y la validación.

En problemas de enrutamiento, también verifique Routing > SD-WAN routes, puertas de enlace y Packet Capture. El Policy tester no reemplaza una prueba de enrutamiento real.

Más información: Ajustar prioridad de enrutamiento en Sophos Firewall.

GUI, CLI y acceso al sistema

Para WebAdmin, SSH, API y servicios locales de gestión, la lista básica está más arriba en Sistema, gestión y servicios básicos. Si WebAdmin o SSH no son accesibles, no se deben revisar solo apache.log, tomcat.log o sshd.log. El acceso local se controla mediante Administration > Device access y Local Service ACL.

Más información: Establecer conexión SSH con Sophos Firewall.

Sophos Fusion, Heartbeat y Central Management

• Sophos Central Management: Central Management, logs centralmanagement.log, sophos-central.log.
• CSC: servicios csc, cschelper, csd; registros csc.log, cschelper.log, csd.log.
• Security Heartbeat: servicios heartbeatd, hbtrust; registros heartbeatd.log, hbtrust.log.
• Synchronized Application Control: revisar los datos enviados a SophosLabs en sac-feedback.log.
• Heartbeat hacia Central: servicios fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; revisar los respectivos registros de servicio.
• Central API Executor: servicio fwcm-api-executor, registro fwcm-api-executor.log.
• Active Threat Response: contexto ATR; revisar según versión y módulo.

En caso de problemas con Sophos Fusion, primero verifique si el firewall está registrado, si los servicios de Central están activos y si DNS/HTTPS saliente funciona. Si una modificación de Sophos Fusion no llega localmente, se debe comparar la Sophos Fusion Firewall Task Queue con los registros locales. Un estado verde en Sophos Fusion no demuestra por sí solo que una política concreta se haya procesado localmente.

Alta disponibilidad

• Estado y configuración de HA: registro de aplicación de HA, archivo applog.log.
• Servicio de par HA: servicio ha_pair, registro ha_pair.log.
• Túnel HA: servicio ha_tunnel, registro ha_tunnel.log.
• Sincronización de conntrack: servicio ctsyncd, registro ctsyncd.log.
• Msync: servicio msync, registro msync.log.
• Establecimiento de HA y cambios de estado: ha.log.
• Sincronización de archivos de servicios seleccionados con el dispositivo Auxiliary: filesync.log.

Los logs e informes HA no se sincronizan entre los dispositivos. Cada nodo almacena solo los datos del tráfico que ha procesado él mismo. Por tanto, Log Viewer y Diagnostics > Tools > Troubleshooting logs se revisan en cada dispositivo afectado. Para obtener los troubleshooting logs del dispositivo Auxiliary, hay que iniciar sesión directamente en su CLI mediante la dirección IP o FQDN de su interfaz de administración. Sophos Central Firewall Reporting puede combinar informes de ambos dispositivos, pero no sustituye los archivos de troubleshooting locales de cada nodo.

Correo y anti-spam

• Antivirus: servicio AV, registro avd.log.
• Actualizaciones del antivirus: Up2Date AV, registro up2date_av.log.
• Anti-Spam: servicio sasi, registro sasi.log.
• Sandbox: servicio sandboxd, registro sandboxd.log.
• SMTP MTA: servicio smtpd, registro smtpd_main.log.
• Errores SMTP: errores, fallos críticos y rechazos de smtpd; registros smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
• Proxy SMTP/S heredado: servicios awarrensmtp, awarrenmta; registros awarrensmtp.log, awarrenmta.log. Mail Protection en Legacy mode explica la configuración y la prueba end-to-end.
• Proxy POP/IMAP: servicio warren, registro warren.log. Analizar POP3 e IMAP en Sophos Firewall explica la configuración y la prueba end-to-end.

En problemas de correo, siempre verifique si el modo MTA, la regla de firewall, DNS, certificados y restricciones del proveedor son compatibles. El procedimiento para el flujo de correo, spool, cuarentena y relay se describe en Configurar protección de correo en modo MTA en Sophos Firewall.

Sophos Firewall utiliza Avira y Sophos Antivirus. El servicio anti-spam solo se inicia si hay una política de spam entrante o saliente. Esta dependencia es importante si sasi.log permanece vacío o el servicio anti-spam no se ejecuta.

Inalámbrico, RED, Hotspot y otros servicios

• Controlador inalámbrico: servicio awed, registro awed.log.
• Wireless Clients: revisar la comunicación entre el cliente y AP/APX en wc_remote.log.
• Hotspot: servicios hostapd, hotspotd; registros hostapd.log, hotspotd.log.
• RED: servicio RED, registro red.log. Según el tipo y la instancia RED, también pueden aparecer red-<serial ID of RED>.log y red-<RED ID>.log.
• SNMP: servicio snmpd, registro snmpd.log.
• Servicio Syslog: registro syslog.log.
• Licencias: servicio de licencias, registro licensing.log.
• Actualizaciones del sistema: servicio u2d, registro u2d.log.
• VMware Tools: servicio vmtool, registro vmtool.log.

En problemas de licencia, Air-Gap o patrones, licensing.log y u2d.log son los primeros puntos de referencia técnicos. Para el procedimiento operativo con archivo de licencia, ventana de 180 días y actualizaciones de patrones manuales, consulte Operar licencia y actualizaciones de patrones Air-Gap en Sophos Firewall.

Base de datos e informes

• Base de datos de configuración: Config DB, registro postgres.log.
• Postgres: servicio postgres, registro postgres.log.
• Base de datos de firmas: servicio sigdb, registro sigdb.log.
• Base de datos de informes: base de datos de informes, registro reportdb.log.
• Base de datos de migración: migración de informes, registro reportmigration.log.
• Garner: servicio garner, registro garner.log.
• iView: servicio iview, registro iview.log.

Si faltan informes, son lentos o hay problemas de espacio de almacenamiento, los registros de informes y bases de datos son relevantes. Además, se debe verificar si los informes se almacenan localmente o se envían a Sophos Fusion.

Otros archivos de log actuales de SFOS 22

Los siguientes archivos se necesitan con menos frecuencia para el troubleshooting diario del tráfico, pero forman parte de la asignación actual de SFOS 22. Se agrupan por función para no interpretar prematuramente un nombre de archivo como causa:

• Audit, FIPS y acceso de soporte: configuration-audit.log registra el cambio de configuración, el administrador y la hora; fips.log el inicio en modo FIPS; uma.log el Support Access.
• Pipeline de logs y mantenimiento de datos locales: syslog-ng.log muestra la supresión de eventos consecutivos; reportdb_v9.log pertenece a la antigua base de datos de reports. dbcleanup.log, readobject.log, fstrim.log y logrotate.log cubren la limpieza de la base de datos, la lectura interna de objetos, el trimming del sistema de archivos y la rotación de logs.
• ATR, NDR y FastPath: atr-service.log muestra el inicio y la detención del servicio ATR. ndr.log y ndr_agent.log cubren licencia NDR, configuración, inicio del agente y procesamiento de metadatos; vfpdf.log se aplica a metadatos NDR en XGS 88/88w, 108/108w, 118/118w y 128/128w. setup_vf_dpdk.log registra la inicialización de memoria de FastPath y no se aplica precisamente a esas cuatro gamas.
• TLS y SSL VPN: httplogd.log muestra conexiones HTTPS no descifradas en la ruta DPI. peruser_cert_sslvpn.log registra certificados SSL VPN generados por usuario; openvpn-status0.log, openvpn-status1.log y otros archivos numerados muestran conexiones SSL VPN activas por proceso.
• Red y HA: dhcprelay.log pertenece a DHCP Relay. ha.log muestra el éxito o error al establecer HA y los cambios de estado; filesync.log la sincronización de archivos de determinados servicios con el dispositivo Auxiliary.
• Central, deployment y ZTNA: fwcm-eventd.log, fwcm-heartbeatd.log, fwcm-updaterd.log y fwcm-frpcd.log cubren información de zonas/interfaces enviada a Central, conectividad, configuración transferida y Fast Reverse Proxy. ssod.log contiene información de firmware y backups de Central, zt.log y zerotouch.log variantes de Zero Touch, y ztna-connector.log el ZTNA Connector local.
• Backup, firmware, Air Gap y certificados: interfacemapping.log registra la asignación de interfaces durante el restore, legacyconversion.log los backups sin Secure Storage Master Key y fwmgmt.log la instalación y gestión de firmware. u2d_airgap.log se aplica a actualizaciones Air Gap, cps_messages.log a errores de hotfix y letsencrypt.log junto con applog.log a certificados Let’s Encrypt.
• Hardware y estado del sistema: npu-startup.log, npu_syslog.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-npu-serial.log y xgs-pport-wait.log cubren inicio, comunicación, firmware, puerto serie, estado de NPU y creación de interfaces físicas. raid.log muestra Software RAID y lcd.log la pantalla del hardware. system-monitor/cpu_trigger.log conserva el estado del sistema con CPU alta; system-monitor/memory_trigger.log se aplica en SFOS 22 con carga alta de memoria.
• Servicios de cloud y plataforma: iaasd.log registra provisioning e inspección de licencia en Azure, waagent.log el agente Azure y su Health Monitoring; vmtool.log pertenece a VMware Tools.

La presencia de un archivo no demuestra un error en ese módulo. Primero se correlacionan la hora del evento, el node afectado, la plataforma, el estado del servicio y un síntoma reproducible; solo después se busca con un filtro limitado en el archivo adecuado.

Flujo de análisis

1. Anotar el problema con precisión: hora con zona horaria, cliente, destino, puerto, usuario, acción.
2. Decidir si se trata de tráfico, estado de servicio, cambio de configuración o sincronización con Central.
3. Filtrar en Log Viewer por Source IP, Destination IP, módulo y hora.
4. Verificar visibilidad de Firewall Rule ID, NAT Rule ID, usuario, gateway y Policy IDs.
5. Usar Packet Capture si el flujo de paquetes, ruta de retorno o vista NAT no están claros.
6. Revisar el log adecuado con tail -f, less o grep.
7. Reproducir el problema y documentar el momento exacto de prueba.
8. Si es necesario, activar Debug solo para el servicio afectado y solo brevemente.
9. Desactivar Debug de nuevo y comprobar espacio de almacenamiento.
10. Guardar logs mientras el error aún se haya reproducido recientemente.

Para casos de soporte, también se deben documentar todos los mensajes de error, pasos de reproducción y pasos de solución de problemas ya realizados. Esta información acelera significativamente los casos de soporte. El procedimiento adecuado se describe en Abrir un ticket de soporte de Sophos: Preparación y portal.

FAQ