Solución de problemas de CLI en Sophos Firewall: comandos importantes

Al solucionar problemas en Sophos Firewall, Log Viewer suele bastar para una primera delimitación. Cuando un servicio no arranca correctamente, las conexiones VPN son inestables, algunos paquetes no llegan o el soporte necesita datos detallados, la CLI cobra importancia.

Esta guía presenta los comandos más importantes para el trabajo diario: dónde ejecutarlos, qué muestran y cuándo conviene pasar a un artículo específico. Para acceder de forma segura por SSH, primero se debe consultar Conectar con Sophos Firewall mediante SSH. Una clave pública, la verificación de la clave del host y una autorización de Device Access limitada son más importantes que poder iniciar sesión rápidamente desde cualquier lugar.

⚠️ Importante: Los comandos de CLI y Advanced Shell solo deben ejecutarse desde redes de administración de confianza y con un objetivo claro. En especial, el debug, tcpdump, las operaciones con archivos y los comandos de servicios pueden afectar al espacio disponible, al rendimiento o a las conexiones activas.

Primero WebAdmin y después la CLI

La CLI no siempre es el punto de partida más rápido. Para comprobar la coincidencia de reglas, NAT o conexiones concretas, Log Viewer, Policy Test y Packet Capture en WebAdmin suelen ofrecer antes un resultado claro.

Puntos de partida recomendados:

• ¿Qué regla de firewall se aplica? Utilizar primero Log Viewer, Policy Test y Packet Capture. La CLI solo es necesaria si Log Viewer ofrece pocos detalles o se necesitan logs en tiempo real.
• ¿Llegan los paquetes al firewall? Utilizar primero Packet Capture en WebAdmin. La CLI resulta útil cuando se necesita una captura muy específica o un archivo PCAP para soporte.
• ¿Tiene problemas un servicio? Comprobar primero el dashboard, Log Viewer y los logs del servicio. La CLI es importante cuando se debe revisar directamente el estado del servicio, el debug o los archivos de log.
• ¿Se ha cambiado algo? Consultar primero Audit Trail Logs. Después, la CLI ayuda a comparar una diferencia de configuración con logs o copias de seguridad.

El objetivo no es entrar en Advanced Shell lo antes posible. Es preferible seguir un proceso reproducible: comprobar primero los eventos visibles y abrir después el archivo de log o la captura adecuados.

Documentar los resultados de la CLI de forma útil

La salida de la CLI solo resulta útil si posteriormente queda claro a qué prueba pertenece. Los mensajes de error copiados sin intervalo de tiempo, direcciones IP o función afectada suelen provocar preguntas adicionales y análisis duplicados.

Normalmente basta con una nota breve por prueba:

• Intervalo de tiempo: inicio, fin y zona horaria de la prueba.
• Flujo de prueba: Source IP, Destination IP o FQDN, puerto, usuario o peer VPN.
• Herramienta: Device Console, Advanced Shell, Log Viewer o Packet Capture.
• Comando o filtro: comando ejecutado, término de búsqueda de grep o filtro de captura utilizado.
• Resultado: coincidencia, mensaje de error, entrada de log ausente, paquete visible o paquete no visible.
• Siguiente conclusión: por ejemplo, problema de regla, problema de DNS, ruta de retorno, fallo de servicio o caso de soporte.

Antes de enviar los datos a Sophos Support, Avanet o un partner externo, se debe comprobar si la salida contiene información sensible: direcciones IP públicas, nombres de host internos, nombres de usuario, parámetros VPN, números de serie, tokens, direcciones de correo electrónico o nombres de clientes. Para un análisis técnico no es necesario distribuir los datos de forma indiscriminada; lo importante es el fragmento mínimo que demuestra el resultado.

Antes del primer comando

La solución de problemas mediante CLI es mucho más fiable cuando el contexto está definido antes del primer comando. De lo contrario, aparecen rápidamente fragmentos de log sin referencia temporal, capturas demasiado amplias o logs de debug que después no se pueden asociar con claridad.

Antes de realizar pruebas mediante CLI en producción se debe anotar lo siguiente:

• Hora del problema: permite buscar los logs específicamente en el intervalo de prueba.
• Source IP, Destination IP y puerto: grep, tcpdump y Packet Capture se mantienen acotados y legibles.
• Usuario o peer afectado: facilita la asignación de autenticación, VPN y User Matching.
• Módulo esperado: se busca primero en el archivo de log adecuado, no en todos los logs.
• Acción prevista: evita que el debug, la comprobación de un servicio o una captura queden activos accidentalmente.
• Criterio de reversión o cancelación: la prueba se detiene si aumenta la carga, se agota el espacio o aparecen efectos secundarios.
• Copia de seguridad actual si se harán cambios: permite proteger mejor los reinicios de servicios o los cambios de configuración.

Siempre que sea posible, el primer paso debe ser de solo lectura: revisar Log Viewer, consultar el archivo de log adecuado, leer service -S o iniciar una captura acotada. Los reinicios, el modo debug y las capturas amplias deben realizarse después, dentro de una ventana de prueba controlada.

En clústeres HA también debe estar claro qué dispositivo está activo. Los logs, el debug y las capturas se deben comprobar en el nodo por el que pasa realmente el tráfico relevante.

¿Device Console o Advanced Shell?

Sophos Firewall dispone de dos áreas de consola distintas. Muchos errores se deben a que un comando se introduce en el área equivocada.

Cada área tiene una función diferente:

• Device Console: CLI de Sophos para comandos de red, sistema y diagnóstico. Los comandos habituales incluyen ping, dnslookup, traceroute, tcpdump, drop-packet-capture y show.
• Advanced Shell: shell similar a Linux para archivos, logs, procesos y comprobaciones de servicios. Los comandos habituales incluyen nslookup, cd /log, tail -f, grep, less, df -kh, service -S y conntrack.

Tras iniciar sesión por SSH, el firewall muestra primero el menú de consola. Para abrir Device Console, normalmente se selecciona 4. Device Console. Para abrir Advanced Shell, se utiliza 5. Device Management > 3. Advanced Shell.

La prueba de DNS muestra especialmente bien la diferencia. Los comandos no son intercambiables:

Device Console:

dnslookup host example.com

Advanced Shell:

nslookup example.com

Este mensaje no es el resultado de una prueba de DNS. Si aparece /bin/sh: dnslookup: not found en Advanced Shell, dnslookup no está disponible allí. En su lugar, debe utilizarse nslookup; su salida muestra a continuación si la resolución DNS funciona.

La ayuda oficial de la CLI de Sophos admite Tab y ? para comprobar la sintaxis. Esto resulta útil en Device Console porque no todos los comandos tienen la misma estructura.

Especialmente en Device Console, no se deben ejecutar comandos incompletos ni basados en suposiciones. Sophos advierte de que un comando incompleto puede bloquear access_server. Por ello, primero se muestra la sintaxis con Tab o ? y después se ejecuta conscientemente el comando completo.

Los cambios directos de configuración realizados en Advanced Shell no son persistentes ni se incluyen en las copias de seguridad. Por eso, esta guía solo la utiliza para comandos de diagnóstico.

Un comando especial de emergencia es system appliance_access enable. Este comando anula la configuración de Device Access y permite acceder a todos los servicios locales del firewall, incluidos servicios heredados como Telnet. Importante: mientras este modo está activo, el firewall deja de reenviar tráfico saliente a internet. No es un paso normal de solución de problemas, sino una medida para emergencias breves. Antes de activarlo, se debe comprobar el estado:

system appliance_access show

Después de la prueba, se debe desactivar el modo de emergencia y volver a comprobar el estado:

system appliance_access disable
system appliance_access show

Si un comando no se reconoce, se debe comprobar primero el área de consola. Es más probable que se esté utilizando el área equivocada a que el comando esté defectuoso.

Consultar logs en Advanced Shell

Los archivos de log más importantes se encuentran en /log. Para una primera orientación, se cambia a este directorio y se muestra la lista de archivos.

cd /log
ls -lah

Comandos básicos útiles:

• Seguir un log en tiempo real: tail -f /log/strongswan.log. Útil para errores VPN reproducibles.
• Leer un archivo de log: less /log/ips.log. Dentro de less se puede buscar con /termino.
• Buscar errores: grep -i "error" /log/ips.log. -i ignora mayúsculas y minúsculas.
• Mostrar coincidencias con número de línea: grep -n "192.0.2.10" /log/firewall_rule.log. Útil en archivos largos.
• Mostrar las últimas líneas: tail -n 100 /log/syslog.log. Ofrece una vista rápida sin modo en tiempo real.

La relación entre módulos y archivos de log se resume en Sophos Firewall: servicios y logs para la solución de problemas.

Al consultar logs en tiempo real, la prueba debe mantenerse breve y se debe anotar la hora. Esto es especialmente importante si después se entrega un archivo de logs a Sophos Support o Avanet.

Device Console para comprobaciones rápidas de red

Device Console es adecuada para realizar pruebas rápidas desde la perspectiva del firewall. Permite comprobar si DNS, el routing o la conectividad funcionan en principio.

Comprobaciones rápidas:

• Comprobar un host: ping 192.0.2.10 count 4 comprueba la conectividad ICMP.
• Comprobar DNS en Device Console: dnslookup host example.com comprueba la resolución de nombres desde la perspectiva del firewall.
• Comprobar la ruta: traceroute 192.0.2.10 muestra el recorrido hasta el destino.
• Consultar el estado de las interfaces: show interfaces muestra información sobre las interfaces.
• Iniciar Drop Capture: drop-packet-capture 'host 192.0.2.10' muestra los paquetes descartados por las reglas de firewall.
• Iniciar una captura de paquetes: tcpdump 'host 192.0.2.10 and port 443' comprueba si los paquetes son visibles en el firewall.

Para IPv6 están disponibles los comandos equivalentes ping6, dnslookup6 y traceroute6.

drop-packet-capture resulta especialmente útil cuando no está claro si el firewall descarta paquetes de forma activa. Sin embargo, no sustituye un análisis de la aplicación. Si un servidor responde pero la aplicación sigue sin funcionar, también se deben revisar Log Viewer, NAT, Packet Capture o los logs de la aplicación.

Para capturas más largas y archivos PCAP resulta más adecuado el artículo Sophos Firewall: recopilar logs con TCPDump para su análisis. También se debe planificar el tamaño máximo del archivo, dónde se guardará y cómo se transferirá de forma segura.

Comprobar conexiones y flujo de paquetes en Advanced Shell

Si Log Viewer y Device Console todavía no ofrecen una respuesta clara, algunos comandos de Advanced Shell ayudan a analizar el flujo de paquetes.

Comprobar conexiones

Antes de utilizar herramientas de Advanced Shell, conviene filtrar el flujo en Current activities > Live connections y Diagnostics > Connection list. Estas vistas documentadas de WebAdmin muestran Rule ID, NAT ID, interfaces, usuario, gateway y direcciones traducidas sin modificar la sesión.

En Device Console, system diagnostics utilities connections es una herramienta de diagnóstico de conexiones documentada oficialmente. Las opciones disponibles y la salida se deben comprobar previamente con ?.

conntrack es una herramienta cercana al soporte en Advanced Shell y muestra las conexiones activas conocidas por la ruta stateful del firewall. Su disponibilidad exacta puede depender de la versión del firmware.

conntrack -L | grep "192.0.2.10"

La ausencia de una coincidencia es solo un indicio, ya que el momento del análisis, la dirección del filtro o FastPath pueden afectar a la visibilidad. Por eso, el resultado se debe comparar con Log Viewer y Packet Capture. Si existe una entrada pero la aplicación no funciona, también se debe comprobar si regresan paquetes de respuesta y si NAT, la política o la aplicación funcionan correctamente.

tcpdump en Advanced Shell

Para comprobaciones rápidas en tiempo real también se puede utilizar tcpdump en Advanced Shell.

tcpdump -i any -nn host 192.0.2.10

En análisis de producción, el filtro debe ser lo más específico posible. Las capturas amplias como tcpdump -i any, sin host, puerto o límite, generan rápidamente mucha salida y no son prácticas en firewalls con carga.

Un punto de partida seguro es una captura breve con host, puerto y límite de paquetes:

tcpdump -i any -nn -c 50 host 192.0.2.10 and port 443

Si se necesitan más datos, primero se debe comprobar el espacio disponible y elegir conscientemente dónde se guardará el PCAP.

Comprobar el espacio disponible y el estado del sistema

Antes de activar debug, generar archivos de logs grandes o realizar capturas prolongadas, se debe comprobar el espacio disponible.

Device Console ofrece las siguientes comprobaciones de sistema de solo lectura y documentadas oficialmente:

system diagnostics show cpu
system diagnostics show memory
system diagnostics show disk
system diagnostics show uptime
system diagnostics show version-info

Para una comprobación adicional en Advanced Shell están disponibles las siguientes herramientas; su disponibilidad puede depender de la versión del firmware:

df -kh
df -h /var

Otras comprobaciones rápidas:

uptime
top
service -S
service -S | grep strongswan

service -S muestra el estado de muchos servicios. Los nombres de algunos servicios no siempre se explican por sí solos. Por eso, el servicio se debe comparar con el archivo de log correspondiente antes de reiniciarlo o activar debug.

Si el espacio disponible ya es escaso, no se debe activar debug ni iniciar una captura prolongada. Primero hay que aclarar qué logs o informes se pueden guardar y eliminar de forma segura.

Activar el log de debug de forma específica

El log de debug puede ayudar con errores complejos, pero solo debe permanecer activo durante poco tiempo y únicamente para el servicio afectado. El debug genera muchos más datos y puede consumir espacio si permanece activo durante un periodo prolongado.

Para disponer de un proceso de activación y desactivación claramente controlable, se utiliza en Device Console un subsistema compatible. Primero se muestran los nombres disponibles con system diagnostics subsystems ?. Sophos documenta, por ejemplo, el siguiente proceso para Pktcapd:

system diagnostics subsystems Pktcapd debug on
system diagnostics subsystems Pktcapd debug off

Sophos también documenta el siguiente comando de debug de IPS para Advanced Shell:

service ips:debug -ds nosync

Para esta variante de Advanced Shell no se ha documentado un comando independiente con off añadido. Por eso, solo se debe utilizar cuando Sophos Support haya confirmado el método exacto de desactivación para el build instalado.

La imagen muestra en SFOS 20.0.1 cómo el mismo comando conmuta el modo debug de IPS y cómo service -S | grep ips confirma el estado antes y después de la prueba. En versiones actuales, no se debe dar por supuesto este comportamiento de conmutación sin comprobarlo.

Para reiniciar servicios y entender su función, también se puede consultar Reiniciar servicios de Sophos Firewall. En casos de soporte se debe documentar el intervalo exacto del log de debug.

Antes de reiniciar un servicio se debe comprobar qué función se verá afectada y si está procesando tráfico de producción. El reinicio de servicios VPN, IPS, web o de autenticación puede afectar a sesiones activas o inicios de sesión de usuarios.

Proporcionar logs de forma segura

En casos complejos, los fragmentos individuales de log no suelen ser suficientes. Para Sophos Support, Avanet o un análisis externo, un archivo de logs completo suele resultar más útil.

En lugar de escribir credenciales FTP en comandos, los logs se deben transferir por un medio seguro y trazable, por ejemplo mediante scp a un servidor propio o a través de un portal de soporte. El proceso se describe en Guardar logs de Sophos Firewall para soporte y análisis.

Los archivos de log pueden contener información sensible: direcciones IP internas y públicas, nombres de host, nombres de usuario, parámetros VPN y mensajes de error. Antes de compartirlos, debe quedar claro quién recibirá los datos y durante cuánto tiempo se conservarán.

Errores habituales al solucionar problemas mediante CLI

• Comando en el área de consola equivocada: Device Console y Advanced Shell utilizan sintaxis distintas. Comprobar primero el área.
• Dejar activo el debug después del análisis: Los logs crecen innecesariamente y pueden consumir espacio. Desactivar el debug de inmediato.
• tcpdump amplio sin filtro: Mucha salida, carga elevada y datos difíciles de analizar. Limitar el host, puerto, interfaz o número de paquetes.
• Credenciales FTP en el historial de la shell: Las credenciales pueden aparecer en logs, capturas de pantalla o el historial. Utilizar una transferencia segura y credenciales temporales.
• Comprobar un único archivo de log: Muchos problemas afectan a varios módulos. Combinar Log Viewer, los logs de servicio adecuados y Packet Capture.
• No documentar la hora: El soporte debe buscar en intervalos de log innecesariamente amplios. Anotar la hora, la acción de prueba y las direcciones IP implicadas.
• No limpiar después de la prueba: El debug, los archivos temporales o los accesos amplios permanecen activos. Desactivar el debug, revisar los archivos y eliminar las autorizaciones SSH temporales.

Lista de comprobación

• Acceso SSH permitido solo desde redes de administración de confianza.
• Fingerprint SSH y acceso admin comprobados antes del análisis.
• Área de consola correcta seleccionada: Device Console o Advanced Shell.
• Hora del problema, Source IP, Destination IP, puerto y usuario documentados.
• Resultado de la CLI documentado con intervalo de tiempo, comando, filtro y resultado.
• Primero se utilizaron comandos de solo lectura antes de iniciar debug, reinicios de servicios o capturas prolongadas.
• Log Viewer comprobado en primer lugar.
• Archivo de log adecuado identificado en /log.
• tail, grep o less utilizados con un término de búsqueda específico.
• Para problemas de red se utilizó dnslookup en Device Console o nslookup en Advanced Shell, además de ping, traceroute, drop-packet-capture o tcpdump según el caso.
• Debug activado solo brevemente y desactivado con el comando documentado para el subsistema elegido.
• Espacio disponible comprobado antes de debug o PCAP.
• Archivo de logs transferido de forma segura y archivos temporales eliminados.
• Excepciones temporales de Device Access o SSH eliminadas después del caso de soporte.

Preguntas frecuentes