Asegurar los registros de Sophos Firewall para soporte y análisis

En caso de fallos, problemas de VPN o eventos de firewall poco claros, las capturas de pantalla individuales de la interfaz web a menudo no son suficientes. Para un análisis exhaustivo, un caso de soporte necesita marcas de tiempo rastreables, archivos de registro adecuados y, a veces, una captura de paquetes adicional.

El procedimiento oficial de descarga y diagnóstico se aplica a SFOS 22 y SFOS 23. Los archivos manuales complementarios siguen siendo una vía de análisis independiente, no una exportación estándar confirmada para ambas versiones. Describe la vía oficial mediante Diagnostics > Tools y la distingue de la vía complementaria para logs en bruto mediante Advanced Shell. Para Sophos Support, el Consolidated Troubleshooting Report (CTR) suele ser el mejor punto de partida, porque reúne archivos de log y una instantánea del sistema en un archivo cifrado. Un archivo /log creado manualmente sigue siendo útil cuando se necesitan logs en bruto completos, datos adicionales de IPsec o un análisis interno. Sin embargo, no es un CTR cifrado ni la exportación estándar documentada por Sophos.

El proceso no sustituye la primera delimitación en Log Viewer. Si aún no está claro qué módulo está afectado, primero ayuda la visión general Solución de problemas de Sophos Firewall: Servicios y registros.

Delimitar primero el caso de soporte

Un archivo grande no es automáticamente un buen paquete de soporte. Primero hay que determinar qué prueba falló, cuándo se ejecutó y qué componente está probablemente implicado.

¿Analizar primero o recopilar ya los datos?

Dependiendo del tipo de error, otro punto de partida puede ser más rápido:

• Comprobar un intento de conexión concreto: Probar regla de firewall con Log Viewer, Policy Test y Packet Capture, si no están claras la regla, la regla NAT o la ruta.
• Asignar archivos de log locales: Solución de problemas de Sophos Firewall: Servicios y registros, si primero hay que aclarar qué log corresponde a VPN, Web, IPS, GUI o servicios del sistema.
• El problema es conocido y hay que entregar los datos: seguir este artículo para crear un CTR, logs específicos o un archivo de logs en bruto.

Para informes históricos o eventos recurrentes se utiliza Central Firewall Reporting. La retención y correlación a largo plazo requieren Syslog o SIEM. Un archivo para un caso de soporte puntual no sustituye a ninguno de los dos.

Elegir el paquete de datos según el problema

No todos los problemas requieren inmediatamente un archivo de registro completo. Cuanto más claro esté delimitado el error, más pequeños y útiles serán los datos.

• La regla de firewall o la regla NAT actúa inesperadamente: Hora, IP de origen, IP de destino, ID de regla, ID de NAT, exportación del Log Viewer y, si es necesario, Packet Capture.
• El servicio no se inicia o WebAdmin muestra errores: Consolidated Troubleshooting Report, servicio afectado, hora y último paso de configuración.
• El túnel IPsec no se establece o falla: Archivo de registro normal, datos de diagnóstico de IPsec, IP del par, redes locales y remotas, momento del intento de conexión.
• El tráfico no llega al destino: Log Viewer, Packet Capture o para análisis más largos tcpdump-PCAP.
• Problema después de un cambio de configuración: Audit Trail, momento aproximado del cambio, administrador involucrado, objetos afectados y, si hace falta, CTR.

Para muchos tickets, la combinación de momento del problema, breve descripción del error, archivo de registro y una prueba adicional específica es mejor que un paquete de datos muy amplio sin contexto. Si se crea un ticket oficial de Sophos, también es útil Abrir un ticket de soporte de Sophos: Preparación y portal.

Requisitos previos

Para esta guía se necesita:

• Acceso administrativo al Sophos Firewall
• Acceso a Diagnostics > Tools en WebAdmin
• Para archivos de logs en bruto, acceso adicional a la Advanced Shell
• Un servidor de destino, un portal de soporte u otra vía segura para transferir archivos
• Suficiente espacio libre en el firewall para el archivo temporal

Los comandos se ejecutan directamente en el firewall. Por lo tanto, se debe trabajar con cuidado y no eliminar archivos a menos que se sepa para qué se utilizan.

Si el acceso a la Shell aún no está configurado, la guía Conectar Sophos Firewall por SSH explica cómo establecer una conexión SSH con el firewall.

⚠️ Los archivos de registro y los archivos PCAP pueden contener información sensible. Dichos archivos solo deben permanecer brevemente en el firewall, transferirse de manera segura y eliminarse después de una transferencia exitosa.

Recopilar logs

Según el caso de soporte, puede bastar una descarga dirigida desde WebAdmin, un CTR o un archivo de logs en bruto desde la Advanced Shell. El proceso debe empezar con el conjunto de datos más pequeño que todavía explique el error de forma limpia.

La conservación local de los logs está limitada por el espacio asignado a cada subsistema y por el modelo del firewall. Cuando un archivo de log alcanza su límite de tamaño, se comprime con gzip; cuando el subsistema alcanza su límite de almacenamiento, se eliminan primero las rotaciones .gz más antiguas. Si el firewall deja de responder, también pueden perderse los datos de log que aún están en RAM y no se han escrito en el sistema de archivos. Por eso conviene recopilar los logs relevantes cuanto antes: una exportación solo contiene los datos que siguen disponibles y no recupera las entradas perdidas.

Los logs de diagnóstico se almacenan en la partición /var y se leen mediante /log. Los componentes críticos reciben más espacio; se conservan dos o más rotaciones comprimidas según el subsistema. Tras la rotación, el firewall sigue escribiendo con el nombre original. En una XGS Appliance, el historial disponible también depende del modelo y del servicio, no de un periodo de retención uniforme.

Vía estándar: crear CTR en WebAdmin

Para muchos casos de soporte conviene crear primero el Consolidated Troubleshooting Report. El CTR contiene un snapshot del sistema y archivos de log en un archivo cifrado. Sophos Support puede evaluar este archivo directamente dentro del caso de soporte.

Así se crea el CTR:

1. Reproducir el error si es posible y anotar la hora exacta.
2. Abrir Diagnostics > Tools en WebAdmin.
3. En Consolidated troubleshooting report, seleccionar las opciones necesarias.
4. Para un caso de soporte amplio, activar System snapshot y All log files.
5. Introducir un motivo breve, por ejemplo número de ticket, síntoma y ventana temporal.
6. Seleccionar Generate.
7. Tras la creación, seleccionar Download.
8. Proporcionar el archivo mediante el portal de soporte, la carga segura acordada o la vía interna de análisis.

System snapshot no necesita modo debug y recoge el estado actual del sistema, incluidos los procesos activos y el uso de recursos. El nombre documentado es CTR_<APPKEY>_<MM_DD_YY>_<HH_MM_SS>: APPKEY es el número de serie del firewall; los demás campos indican la fecha de creación en mes/día/año y la hora en hora/minuto/segundo. El propio nombre del archivo también es confidencial. Esto resulta práctico cuando varias firewalls o varios intentos terminan en el mismo ticket.

El límite de líneas afecta únicamente a Service subsystem logs; Default subsystem logs se incluyen completos, siempre que los datos sigan disponibles. No comprobar un CTR cifrado con el comando tar -tzf mostrado más adelante: verificar la finalización de la descarga, un tamaño razonable, el dispositivo y la hora de la prueba, y adjuntarlo de forma segura al caso de soporte. Si falla la generación o la descarga, documentar el error y guardar primero los logs individuales afectados, en lugar de borrar logs.

⚠️ El CTR no es un volcado completo de datos en bruto. Los logs de los subsistemas de servicio contienen como máximo 10.000 líneas de forma predeterminada; este límite solo se aplica al CTR. Para obtener logs más antiguos o completos, hay que descargar individualmente los Troubleshooting Logs afectados o guardar los archivos mediante la Advanced Shell.

Comprobar el límite de líneas del CTR en Device Console

El límite de líneas de los logs de subsistemas de servicio incluidos en el CTR se puede consultar y definir de forma independiente de los logs en bruto. En el menú principal de la CLI, abrir 4. Device Console. SFOS 22 y SFOS 23 permiten entre 250 y 10000 líneas y utilizan 10000 de forma predeterminada:

system diagnostics show ctr-log-lines
system diagnostics ctr-log-lines 5000

Normalmente no es necesario cambiar el valor predeterminado. 5000 solo muestra la sintaxis para crear deliberadamente un CTR más pequeño: el intervalo es fijo, pero el valor depende del caso de soporte. Antes de cambiarlo, registrar el valor actual con show; después de generar el CTR, restaurarlo con el mismo comando de configuración. El ajuste solo afecta a futuros archivos CTR, no a los logs en bruto completos, y no recupera datos ya eliminados o sobrescritos.

Descargar Troubleshooting Logs individuales

Si el módulo ya es conocido, una exportación de logs dirigida suele ser mejor que un conjunto de datos muy amplio.

1. Abrir Diagnostics > Tools.
2. En Troubleshooting logs, seleccionar los archivos de log relevantes.
3. Seleccionar Download.
4. Entregar el archivo comprimido generado junto con la hora del error, el caso de prueba y la firewall afectada.

Este camino encaja cuando, por ejemplo, solo se necesita strongswan.log, charon.log, sslvpn.log, reverseproxy.log, applog.log u otro servicio claramente afectado. A diferencia del CTR, estas descargas individuales no están sujetas al límite de líneas. Qué archivo corresponde a cada módulo está descrito en Solución de problemas de Sophos Firewall: Servicios y registros.

Abrir Advanced Shell

Iniciar sesión en el Sophos Firewall y abrir la Advanced Shell:

1. En el menú principal de la CLI, seleccionar 5. Device Management.
2. A continuación, abrir 3. Advanced Shell.
3. Confirmar el acceso si el firewall muestra una consulta adicional.

Después de iniciar sesión, se encuentra en la Shell del firewall. Desde allí se pueden archivar los archivos de registro.

Guardar un breve extracto del log en tiempo real

En Advanced Shell se pueden seguir las nuevas entradas durante una prueba acotada:

cd /log
tail -f /log/charon.log

charon.log es un ejemplo concreto de IPsec; para otros problemas, elegir el archivo existente adecuado en la guía de logs de servicios. Anotar inicio, final y zona horaria de la prueba, reproducir el error y copiar la salida a un archivo de texto protegido en el ordenador del administrador. Ctrl+C detiene la visualización, no el servicio del firewall. tail -f muestra las últimas líneas existentes y las nuevas entradas, no una exportación completa. Si faltan entradas, comprobar primero nodo, nombre del archivo, hora y servicio; descargar el archivo individual completo si hace falta. Subir el extracto y su contexto al caso de soporte.

Recopilar logs específicos antes de guardar

Si el problema es reproducible, volver a provocarlo, si es posible, justo antes de archivar los logs. Así las entradas relevantes estarán lo más actualizadas posible.

En problemas más complejos, los logs normales a veces no bastan. En este caso puede ser útil activar un Debug Log para el servicio afectado antes de archivar. Debug debe ejecutarse solo de forma dirigida y breve, y desactivarse de nuevo después de recopilar los datos, porque los archivos de log pueden crecer rápidamente. Cómo hacerlo se describe en la sección Activar Debug Log de forma dirigida.

Qué archivo de registro pertenece a qué módulo de firewall se resume en Solución de problemas de Sophos Firewall: Servicios y registros. Esta visión general es útil si se desea verificar específicamente si para un problema son más relevantes los registros de VPN, IPS, Web, correo, GUI o sistema.

Si no es un problema de servicio, sino el flujo de paquetes el que no está claro, un archivo de registro por sí solo a menudo no es suficiente. Para pruebas cortas, Packet Capture en WebAdmin es adecuado. Para archivos PCAP, capturas más largas o análisis de soporte, tcpdump en Sophos Firewall es la herramienta adecuada.

Recopilar debug con una salida controlada

Debug está desactivado de forma predeterminada. Antes de modificarlo, confirmar igualmente con administradores y soporte si ya hay una recopilación en curso; documentar nodo, espacio libre y una ventana de prueba breve. Trabajar con un solo subsistema compatible cada vez. Los datos de debug están disponibles mediante descargas individuales, CTR y CLI. Para el ejemplo de servicio documentado, ejecutar en 4. Device Console:

Para otros servicios compatibles, la sintaxis es system diagnostics subsystems <subsystem> debug on y system diagnostics subsystems <subsystem> debug off. Sustituir <subsystem> por un nombre CLI confirmado en el build concreto, no por un nombre de archivo de log. Si ya hay una recopilación debug para otro caso de soporte, no cambiar su estado sin acordarlo.

system diagnostics subsystems Pktcapd debug on

Ejecutar únicamente la prueba prevista, descargar el log o el CTR terminado y desactivar debug en la misma Device Console:

system diagnostics subsystems Pktcapd debug off

Registrar las salidas de activación y desactivación y sus horas; realizar una breve prueba posterior para comprobar que no aparecen nuevas entradas de debug y que el crecimiento de los logs y el consumo de espacio vuelven a ser normales. Si se rechaza el comando, no adivinar nombres: comprobar la sintaxis del build y contactar con soporte. Desactivar debug no elimina los archivos recopilados.

Para el controlador del sistema, la guía de logs indica el mismo comando, system diagnostics subsystems CSC debug, para activar y desactivar debug, sin on ni off. No usar este conmutador como consulta de estado ni ejecutarlo dos veces a ciegas. Si no están claros el estado inicial o la forma de volver atrás, no modificar CSC debug; seguir el procedimiento controlado para CSC con soporte. Los nombres de los archivos de log no son los nombres de los subsistemas de la CLI.

La guía de diagnóstico SFOS 22/23 enumera los siguientes Default logs para debug; este grupo también está exento del límite de líneas del CTR:

syslog.log, postgres.log, reportdb.log, applog.log, access_server.log, awarrenhttp.log, awed.log, charon.log, csc.log, garner.log, heartbeatd.log, ips.log, iview.log, msync.log, nSXLd.log, networkd.log, red.log, reverseproxy.log, smtpd_main.log, sslvpn.log, tomcat.log, u2d.log, up2date_av.log, npu-startup.log.prev, npu_syslog.log, syslog-ng.log, xgs-healthmond.log, xgs-host.log, xgs-npu-fw.log, xgs-pport-wait.log.

Los Service logs enumerados son:

awarrenhttp_access.log, httplogd.log, bwm.log, awarrensmtp.log, pktcapd.log, warren.log.

La lista describe los archivos compatibles con debug, no todos los logs ni su presencia garantizada en todas las plataformas. Comprobar los archivos NPU y XGS en el contexto de la XGS Appliance concreta. Mantener mayúsculas y minúsculas: pktcapd.log no es el parámetro de comando Pktcapd.

Guardar las pruebas antes de purgar logs

Una purga no es necesaria para crear un CTR ni descargar archivos individuales. La guía de diagnóstico solo presenta el vaciado de un subsistema antes de reproducir el problema como un paso opcional. Primero aclarar los requisitos de conservación, las pruebas y las necesidades de soporte, y guardar los archivos necesarios fuera del firewall. A diferencia de eliminar los archivos propios más adelante, una purga borra el historial de diagnóstico; no se puede deshacer.

Los comandos globales de Device Console son system diagnostics purge-old-logs para todos los logs .gz comprimidos y system diagnostics purge-all-logs para todo el contenido de los logs. Según la ayuda CLI, la purga completa deja archivos vacíos. Las acciones globales también afectan a otros subsistemas y casos de soporte en curso.

Conflicto de sintaxis para un subsistema concreto: La ayuda de administración SFOS 22/23 indica system diagnostics <subsystem> purge-log y system diagnostics <subsystem> purge-old-log; la ayuda CLI documenta en cambio system diagnostics subsystems <subsystem> purge-log y system diagnostics subsystems <subsystem> purge-old-log. Antes de una purga autorizada en 4. Device Console, comprobar sintaxis completa y nombres mediante la ayuda CLI o el autocompletado con Tab, y aclarar el conflicto con soporte. No probar ambas variantes.

Detenerse si no están claros la sintaxis, el origen de los archivos o la recopilación en curso, y seguir el procedimiento de análisis de espacio y purga controlada. Tras una acción acordada, comprobar espacio libre, nuevas entradas normales y estado de los servicios; un menor consumo de espacio no demuestra que se haya resuelto la causa. No borrar manualmente logs del sistema con rm ni comodines.

Guardar logs en bruto mediante Advanced Shell

Si el CTR no basta o se necesitan todos los logs en bruto disponibles en ese momento para un análisis interno, el directorio /log puede archivarse manualmente. Este método desde la shell no sustituye al CTR oficial ni a la descarga individual en Troubleshooting logs.

Antes de archivar, se debe verificar si hay suficiente espacio libre en /var:

Antes de usar este método complementario por shell, comprobar los directorios existentes y el espacio libre. Si /log es un enlace simbólico, el comando tar siguiente puede archivar solo el enlace en lugar de los logs: no continuar con un archivo aparentemente terminado; utilizar la descarga individual oficial o acordar el método con soporte. Un directorio que sigue recibiendo escrituras tampoco es una copia de seguridad consistente. Resolver primero rutas ausentes, errores de lectura o problemas de espacio; no borrar logs del sistema para liberar espacio.

ls -ld /log
df -h /var

Luego, crear un archivo comprimido con los archivos del directorio /log:

tar -cvzf /var/Sophos-Firewall-Logs.tar.gz -C / log

El comando crea el archivo:

/var/Sophos-Firewall-Logs.tar.gz

Los componentes más importantes del comando:

• tar crea un archivo.
• -c crea un nuevo archivo.
• -v muestra los archivos procesados.
• -z comprime el archivo con gzip.
• -f especifica el nombre del archivo comprimido.
• -C / cambia al directorio raíz para el proceso de archivo.
• log es el directorio con los archivos de registro de Sophos Firewall.

La ventaja de -C / es que el comando funciona independientemente del directorio de trabajo actual. Por lo tanto, no es necesario un cd / previo. Si el archivo ya existe, el comando lo sobrescribirá.

Dependiendo del tamaño y la carga del firewall, el proceso de archivo puede tardar algún tiempo. La salida de tar muestra durante este tiempo qué archivos se están escribiendo en el archivo.

Luego, se puede verificar el tamaño del archivo:

ls -lh /var/Sophos-Firewall-Logs.tar.gz

Además, se debe verificar brevemente si el archivo es legible y realmente contiene el directorio de registros:

tar -tzf /var/Sophos-Firewall-Logs.tar.gz

La salida debe mostrar rutas bajo log/. Si el comando informa un error o el archivo es inusualmente pequeño, no se debe transferir el archivo. Primero verificar el espacio libre, los permisos de escritura y la ejecución previa de tar.

Copiar el archivo de logs a un servidor Linux

Si un servidor Linux es accesible por SSH, el archivo se puede transferir con scp.

Ejemplo:

scp /var/Sophos-Firewall-Logs.tar.gz root@192.0.2.10:/root/

Se deben ajustar la dirección IP, el usuario y la ruta de destino a su entorno.

Después de la transferencia, el archivo estará en el servidor de destino en:

/root/Sophos-Firewall-Logs.tar.gz

Desde allí se puede distribuir internamente o poner a disposición del soporte de Sophos o Avanet.

Guardar datos de diagnóstico IPsec por separado

En problemas de VPN o IPsec, los datos de conexión de /tmp/ipsec/connections/ también pueden ser útiles. Las guías SFOS 22/23 revisadas no describen este método manual como exportación estándar. Utilizarlo solo para análisis internos o cuando soporte lo solicite expresamente y comprobar primero que el directorio existe.

Para ello, crear un archivo separado:

ls -ld /tmp/ipsec/connections
tar -cvzf /var/Sophos-Firewall-IPsec-Connections.tar.gz -C /tmp/ipsec connections

También aquí se puede verificar brevemente el archivo generado:

ls -lh /var/Sophos-Firewall-IPsec-Connections.tar.gz

Este archivo también se puede copiar a un servidor de destino con scp:

scp /var/Sophos-Firewall-IPsec-Connections.tar.gz root@192.0.2.10:/root/

Especialmente en caso de errores de IPsec, es útil proporcionar este archivo junto con los registros normales del firewall, para que el estado del túnel, la información de conexión y las entradas de registro se puedan evaluar conjuntamente.

Lo que no sustituye un archivo de soporte

Un CTR y un archivo /log son instantáneas de la firewall local. Ayudan a analizar errores de servicios y del sistema, pero no proporcionan automáticamente un historial a largo plazo ni demuestran que un paquete concreto haya atravesado la firewall. Para historial y búsqueda se utiliza Central Firewall Reporting o Syslog y SIEM. Los cambios de configuración se rastrean de forma más directa con los Audit Trail Logs.

Tratar las capturas de paquetes por separado

Los archivos de registro y las capturas de paquetes son pruebas diferentes. El archivo de registro muestra mensajes de servicio, errores, estados de VPN y eventos del sistema. Una captura de paquetes o tcpdump muestra si los paquetes realmente llegan, se reenvían o si faltan respuestas.

Para casos de soporte, no se deben enviar capturas de paquetes sin filtrar. Es mejor:

1. Anotar el caso de prueba con IP de origen, IP de destino, puerto, protocolo y hora.
2. Primero verificar Log Viewer y WebAdmin Packet Capture si es suficiente.
3. Solo si es necesario, crear una captura tcpdump específica como PCAP.
4. Transferir el archivo PCAP de manera segura.
5. Eliminar el archivo PCAP del firewall después de una transferencia exitosa.

El archivo PCAP no pertenece al archivo /log, sino que se crea y transfiere por separado. Esto mantiene claro qué archivo contiene registros de servicio y qué archivo contiene paquetes de red.

Seguridad, protección de datos y limpieza

Los archivos de registro pueden contener información sensible, como:

• Direcciones IP públicas e internas
• Nombres de usuario
• Nombres de host
• Información de VPN
• Mensajes de error con detalles técnicos
• Indicaciones sobre estructuras de red internas

Por lo tanto, los archivos de registro solo deben transferirse a través de canales seguros y solo proporcionarse a personas u organizaciones involucradas en el análisis. Si los registros se envían a un socio externo, primero debe aclararse internamente si la transferencia está permitida según las políticas de privacidad y seguridad propias.

En los clústeres HA, los logs y los informes no se sincronizan automáticamente entre los dispositivos Primary y Auxiliary. Cada dispositivo contiene los logs y los informes del tráfico que procesa. Para problemas de HA o periodos que incluyan una conmutación por error, hay que anotar de qué nodo procede el archivo y si también se necesitan logs del segundo nodo.

Eliminar archivos temporales

Después de transferir el archivo, comprobarlo en el sistema de destino y eliminarlo del firewall para liberar el espacio temporal. Los siguientes comandos solo eliminan los nombres fijos creados en esta guía:

rm /var/Sophos-Firewall-Logs.tar.gz

Si también se creó un archivo IPsec separado, este también debe eliminarse:

rm /var/Sophos-Firewall-IPsec-Connections.tar.gz

Antes de eliminar, se debe verificar si los archivos llegaron con éxito al sistema de destino.

Lista de verificación para casos de soporte

• Problema descrito brevemente: ¿Qué no funciona, desde cuándo, con qué frecuencia?
• Hora exacta con zona horaria anotada.
• IP de origen, IP de destino, usuario, servicio o nombre del túnel afectados anotados.
• Módulo relevante verificado en el Log Viewer.
• Si es necesario: Depuración activada solo brevemente y desactivada nuevamente.
• CTR creado en Diagnostics > Tools si se necesita Sophos Support o un system snapshot.
• Si es necesario, Troubleshooting Logs individuales o archivo completo de /log creado.
• En caso de problemas de IPsec, datos de diagnóstico de IPsec guardados adicionalmente.
• En caso de problemas de flujo de paquetes, Packet Capture o tcpdump creado por separado.
• Comprobados solo los archivos gzip manuales con tar -tzf para confirmar logs reales; en el CTR cifrado, verificados descarga, dispositivo y hora.
• En HA, verificado de qué nodo proceden los logs.
• Archivo y PCAP transferidos solo a través de canales seguros.
• Archivos temporales eliminados del firewall después de una transferencia exitosa.

FAQ