Ir al contenido
Avanet

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

¿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:

El orden es importante. El Log Viewer a menudo muestra más rápido qué regla o módulo decidió. 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 Source, Destination, Service y hora. Después usar Packet Capture, firewall_rule.log y nat_rule.log.
  • El túnel VPN está down o inestable: revisar estado VPN, peer IP, hora y Log Viewer. Después consultar strongswan.log, charon.log, sslvpn.log y datos de diagnóstico 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, webproxy.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 distinto por nodo: identificar nodo activo, Auxiliary Node y ruta de tráfico afectada. Después iniciar sesión directamente en el nodo afectado y revisar HA logs.
  • Faltan reports locales o el almacenamiento se llena: revisar ajustes de reports, espacio y Central Reporting. Después usar reportdb.log, garner.log y análisis de almacenamiento.

Esta vista evita una trampa habitual: buscar en un log de servicio aunque primero habría que demostrar rule matching, Device Access, NAT o routing.

¿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.

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 traffic flow individual está afectado: filtrar en Log Viewer por Source, Destination, Service 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.

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 admin no quiere abrir una sesión de shell larga o si solo se necesita un paquete de logs 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 número de ticket, intervalo de tiempo o síntoma. El informe se descarga cifrado y, para logs de subsistemas de servicio, normalmente contiene solo una cantidad limitada de líneas. Los logs 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 routing, 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.

Ejemplo:

service ips:debug -ds nosync
service ips:debug -ds nosync off

La sintaxis exacta depende del servicio. Si el servicio afectado no está claro, primero se debe verificar el archivo de registro normal correspondiente.

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

Muchas análisis de registros no duran mucho debido a la 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 live debug: usar Central Reporting para historial e informes, logs locales para 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.

Sistema, gestión y servicios básicos

  • Mensajes del sistema: syslog.log; revisar además hora, reboot e interface events.
  • WebAdmin Webserver: 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, red de origen y Public-Key-Login.
  • Errores GUI/CLI: error_log.log; revisar además cambio reciente, navegador y acción de admin.
  • 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 almacenamiento, backup/restore y caso de soporte.
  • Comunicación entre componentes: garner.log; revisar además reporting, Central Reporting y procesamiento de logs.
  • API: apiparser.log, app-feedback.log; revisar además API ACL, token y Central Task Queue.
  • Validación: validation.log, validationError.log; revisar además objetos defectuosos o imports.
  • Licenciamiento: licensing.log; revisar además estado de licencia, Central Sync y caso especial Air-Gap.
  • System Updates: u2d.log, sig_update.log; revisar además estado de patrones, DNS/HTTPS y 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

  • Firewall rule matching: firewall_rule.log; revisar además 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: Service ips, log ips.log.
  • Application Control: Service ips / Application Filter, log ips.log.
  • DPI e TLS Inspection: DPI Engine, log ips.log.
  • Antivirus en la ruta de red: Service avd, log avd.log.
  • Zero-Day Protection / Sandbox: Sandbox Service, logs sandboxd.log, sessiontbl.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 de MDR feed, log atr.log.
  • Actualizaciones de firmas: Signature Updater, logs sig_upgrade.log, sig_update.log.
  • Migración de firmas: Signature Migration, log 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, tipo de archivo, tamaño de archivo, policy y 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: Service awarrenhttp, log awarrenhttp.log.
  • HTTPS Proxy Access: awarrenhttp Access Log, log awarrenhttp_access.log.
  • Web Proxy: log webproxy.log.
  • Web Categorization / Reputation: Service nSXLd, log nSXLd.log.
  • Legacy HTTP/FTP Proxy: Service skein, log skein.log.
  • FTP Proxy: Service ftpproxy, log ftpproxy.log.
  • Web Application Firewall: Reverse Proxy, log 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+: Services strongswan, charon; logs strongswan.log, charon.log.
  • IPsec específico de conexión: una IPsec Connection concreta, log strongswan-<connection>.log.
  • IPsec versiones anteriores: IPsec Service, log ipsec.log.
  • IPsec Test Connection: IPsec Test, log ipsec_Test_Connect.log.
  • IPsec Monitoring: IPsec Monitor, log ipsec_monitor.log.
  • XFRM / route-based VPN: Service xfrmi, log 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: Service l2tpd, log l2tpd.log.
  • PPTP: PPTP VPN, log pptpvpn.log.
  • VPN Certificates: VPN Certificate Services, logs vpncertificate.log, wc_remote.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: Service nasm, log 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.
  • STAS: STAS / contexto de Access Server, según contexto de servicio y access_server.log.

En reglas de usuario, siempre verifique primero si el usuario es conocido. Si Match known users está activo y la autenticación no funciona, la regla no coincide.

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

  • DNS Service: Service dnsd, log dnsd.log.
  • DNS Grabber: Service dnsgrabber, log dnsgrabber.log.
  • DNS Entity / otros componentes DNS: Services entity, eacd; logs entity.log, eacd.log.
  • DHCP IPv4: Service dhcpd, log dhcpd.log.
  • DHCP IPv6: log dhcp6.log.
  • Servicio de red: Service networkd, log networkd.log.
  • FQDN Hosts: Service fqdnd, logs fqdnd.log, fqdndebug.log.
  • Dead Gateway Detection: Service dgd, log dgd.log.
  • Dynamic DNS: Dynamic DNS Client, log ddc.log.
  • NTP Client: log ntpclient.log.
  • IPv6 Router Advertisement: Service radvd, log 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 mdev.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

  • Static Routing: Service zebra, log zebra.log.
  • Application Based Routing: Service appcached, log appcached.log.
  • Redis App Cache: Redis, log redis.
  • Multicast Routing: log mrouting.log.
  • BGP: Service bgpd, log bgpd.log.
  • OSPF: Service ospfd, log ospfd.log.
  • RIP: Service ripd, log ripd.log.
  • PIM-SM: Service pimd, log pimd.log.

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 tabla 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: Services csc, cschelper, csd; logs csc.log, cschelper.log, csd.log.
  • Security Heartbeat: Services heartbeatd, hbtrust; logs heartbeatd.log, hbtrust.log.
  • Heartbeat hacia Central: Services fwcm-eventd, fwcm-heartbeatd, fwcm-updaterd; revisar los respectivos Service-Logs.
  • Central API Executor: Service fwcm-api-executor, log 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 logs locales. Un estado verde en Central no demuestra por sí solo que una policy concreta se haya procesado localmente.

Alta disponibilidad

  • Estado y configuración HA: HA Application Log, log applog.log.
  • HA Pair Service: Service ha_pair, log ha_pair.log.
  • HA Tunnel: Service ha_tunnel, log ha_tunnel.log.
  • Conntrack Sync: Service ctsyncd, log ctsyncd.log.
  • Msync: Service msync, log 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: AV Service, log av.log.
  • Antivirus Updates: Up2Date AV, log up2date_av.log.
  • Anti-Spam: Service sasi, log sasi.log.
  • Sandbox: Service sandboxd, logs sandboxd.log, sessiontbl.log.
  • SMTP MTA: Service smtpd, log smtpd_main.log.
  • Errores SMTP: smtpd Error/Panic/Reject, logs smtpd_error.log, smtpd_panic.log, smtpd_reject.log.
  • Legacy SMTP/S Proxy: Services awarrensmtp, awarrenmta; logs awarrensmtp.log, awarrenmta.log, awarrenmta_debug.log.
  • POP/IMAP Proxy: Service warren, log 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

  • Wireless Controller: Service awed, log awed.log.
  • Wi-Fi Authentication: Service wifiauth, log wifiauth.log.
  • Hotspot: Services hostapd, hotspot, hotspotd; logs hostapd.log, hotspot.log, hotspotd.log.
  • RED: RED Service, log red.log.
  • SNMP: Service snmpd, log snmpd.log.
  • Syslog Service: log syslog.log.
  • Licensing: Licensing Service, log licensing.log.
  • System Updates: Service u2d, log u2d.log.
  • VMware Tools: Service vmtool, log vmtool.log.
  • SMB-Filesystem: Services smbnetfs, snireport; logs smbnetfs.log, snireport.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

  • Configuration database: Config DB, logs confdbstatus.log, crreportdb.log.
  • Postgres: Service postgres, log postgres.log.
  • Signature database: Service sigdb, log sigdb.log.
  • Report database: Report DB, log reportdb.log.
  • Migration database: Report Migration, logs sac-feedback.log, reportmigration.log.
  • Garner: Service garner, log garner.log.
  • iView: Service iview, log 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

¿Cuál es el archivo de registro más importante en Sophos Firewall?

Depende del problema. Para reglas de firewall, firewall_rule.log es importante, para NAT nat_rule.log, para IPsec strongswan.log, para SSL VPN sslvpn.log, para IPS y Application Control a menudo ips.log. Sin embargo, el Log Viewer sigue siendo la mejor primera entrada para conexiones individuales.

¿Qué es CTR en los logs de Sophos Firewall?

CTR significa en muchos contextos de Sophos Consolidated Troubleshooting Report. Para admins, lo importante es que un CTR o paquete de troubleshooting logs ayuda al soporte, pero no sustituye una descripción limpia del error con hora, IPs afectadas, usuario, nombre de túnel, Rule ID y pasos de reproducción.

¿Cuándo se necesita la Advanced Shell?

La Advanced Shell es útil cuando se deben verificar archivos de registro locales con tail, grep o less, se controla el estado de un servicio o Sophos Support necesita datos de registro detallados. Para muchas verificaciones iniciales, el Log Viewer, Policy Test y Packet Capture en WebAdmin son suficientes.

¿Se debe dejar el registro de depuración activado permanentemente?

No. La depuración genera muchos datos y puede consumir espacio de almacenamiento. La depuración solo debe usarse para el servicio afectado, para una prueba reproducible corta y con desactivación posterior.

¿Por qué no se ven eventos de firewall esperados en el Log Viewer?

A menudo, Log firewall traffic no está activo en la regla afectada, se elige el período o filtro incorrecto, o el tráfico no llega al firewall. Si el flujo de paquetes no está claro, se debe usar Log Viewer y Packet Capture juntos.

¿Son mejores los registros locales que Central Reporting o Syslog?

Son herramientas diferentes. Los registros locales ayudan en el análisis detallado directamente en el firewall. Central Reporting es adecuado para informes y historial de Sophos Central. Syslog es mejor para su propio SIEM, SOC o almacenamiento a largo plazo.