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 Central está atascada? Revisar Sophos Central Firewall Management Task Queue.
• ¿Se necesitan informes o historial en Sophos Central? 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 Central 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 del firewall. Se puede acceder a ellos a través de la consola WebAdmin o por SSH. Para verificaciones rápidas, Device Management > Advanced Shell en el navegador funciona, pero en la práctica, SSH suele ser más cómodo, estable y mejor para sesiones más largas de tail, grep o less. Cómo preparar SSH de manera segura se describe en la guía 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. Conectarse por SSH o abrir Device Management > Advanced Shell en la consola WebAdmin.
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.
• Controlar servicio o activar Debug: service <service>:<start/restart/stop/debug> -ds nosync, por ejemplo service ips:debug -ds nosync. start, restart y stop modifican el funcionamiento y deben ejecutarse en una ventana de mantenimiento o siguiendo una indicación de soporte.

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 de logs debe construirse manualmente con tar desde la Advanced Shell. Para casos de soporte, WebAdmin también ofrece Diagnostics > Tools > Log file details o la selección de troubleshooting logs. Allí se pueden seleccionar y descargar archivos de log por módulo.

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 es práctico si un administrador no quiere abrir una sesión de shell larga o si solo se necesita un paquete de registros claramente delimitado. El CTR es mejor cuando Sophos Support necesita una instantánea amplia del sistema. Al crear un CTR, conviene indicar un motivo breve y claro, por ejemplo el número de ticket, el intervalo de tiempo o el síntoma. El informe se descarga cifrado y, para los registros de subsistemas de servicio, normalmente contiene solo una cantidad limitada de líneas. Los registros individuales completos se obtienen de forma más fiable mediante Troubleshooting logs o directamente desde /log.

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.

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 sistema de archivos, logs, tail, grep, less, service -S, reinicios de servicio y comandos de Debug.

No todos los comandos funcionan en ambas áreas. Si un artículo menciona explícitamente Device Console, el comando debe ejecutarse allí. Si se trata de /log, tail -f, grep, service -S o registro de depuración, generalmente se refiere a la Advanced Shell.

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 Central 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 Central, Activar Central Firewall Reporting es el procedimiento adecuado.

Activar depuración solo de manera dirigida

El registro de depuración es muy útil, pero genera muchos datos y puede consumir espacio de almacenamiento. La depuración solo debe activarse para el servicio relevante. Luego se reproduce el problema y se desactiva la depuración nuevamente. Los logs de depuración pueden contener credenciales y otros datos confidenciales; antes de descargarlos o compartirlos hay que revisarlos y transferirlos de forma protegida.

Ejemplo de IPS para la Advanced Shell:

service ips:debug -ds nosync

El comando conmuta el estado de depuración del servicio y se ejecuta de nuevo después de recopilar los datos para desactivar la depuración. No está documentado añadir off a este comando de Advanced Shell. La sintaxis exacta depende del servicio. Si el servicio afectado no está claro, primero se debe verificar el archivo de registro normal correspondiente.

⚠️ 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.

Sophos distingue aquí dos vías de operación. En la Advanced Shell se usan comandos de servicio como service ips:debug -ds nosync. En la Device Console existen además los comandos system diagnostics subsystems <subsystem> debug on y system diagnostics subsystems <subsystem> debug off para subsistemas compatibles. Estas variantes no deben mezclarse: primero aclarar en qué consola se trabaja y después usar el comando adecuado.

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.

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.
• 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 Central, 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 problemas de Central, 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 Central no llega localmente, se debe comparar la Sophos Central Firewall Management Task Queue con los registros locales. Un estado verde en Central 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.

Los registros de HA se encuentran en el dispositivo donde se generaron. Para registros en bruto del dispositivo auxiliar, debe conectarse directamente a ese dispositivo, por ejemplo, a través de su puerto de administración por SSH. Para informes consolidados, Sophos Central Firewall Reporting es más práctico.

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.
• Proxy POP/IMAP: servicio warren, registro warren.log.

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.
• Autenticación Wi-Fi: servicio wifiauth, registro wifiauth.log.
• Hotspot: servicios hostapd, hotspotd; registros hostapd.log, hotspotd.log.
• RED: servicio RED, registro red.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 Central.

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