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.

Ejecutar un reinicio completo solo como acción planificada

Un reinicio completo no es un comando de diagnóstico. Primero se guardan los logs relevantes, la hora del sistema, el uptime, los roles HA y el estado actual del fallo. Si solo están afectados WebAdmin o un servicio, se comprueba si basta con un reinicio específico de WebAdmin o un reinicio del servicio.

SFOS 22 documenta la siguiente sintaxis en Device Console:

system restart [all]

Los corchetes no forman parte del comando, sino que identifican el argumento opcional all. Primero se comprueba la forma ofrecida por la versión instalada con system restart ?. El comando reinicia el firewall e interrumpe sesiones, túneles VPN y el acceso de administración. Después de ejecutarlo no existe un rollback en la CLI, por lo que la ventana de mantenimiento, el acceso por consola y una ruta de retorno de administración probada deben estar preparados antes de confirmar.

Según Sophos, system restart provoca un failover en un clúster HA. Esto no garantiza conexiones sin interrupciones. El peer, la sincronización, los roles y el enlace HA deben estar estables previamente. Tras el reinicio se comprueban ambos nodos, roles, sincronización, uptime, WAN, routing, DNS, VPN, servicios publicados y un flujo real de aplicación. Un arranque correcto no demuestra que la causa original esté resuelta.

Apagar solo con una ruta de encendido preparada

Para un apagado controlado se utiliza exactamente este comando en Device Console:

system shutdown

Sophos no documenta opciones para este comando. Por tanto, no se añade all, un nombre de nodo ni un supuesto modificador HA a la sintaxis. Antes de confirmar se guardan los logs y la configuración, se informa a los equipos dependientes y se aclara cómo volver a encender el appliance mediante acceso físico, administración remota o la plataforma de virtualización. La página de shutdown no garantiza ningún comportamiento HA; por ello, un nodo del clúster solo se apaga siguiendo el procedimiento de mantenimiento HA previsto y después se comprueba expresamente el peer.

¿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 con acceso completo a los componentes del sistema. Este artículo la limita a los comandos de diagnóstico documentados por Sophos: cd /log, tail, grep, less y service -S.

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.

Device Console agrupa parámetros globales de inspección de paquetes, TCP, UDP, acceso WAN y rutas especiales bajo advanced-firewall. Sus efectos y un procedimiento seguro de cambio se explican en Comprobar Advanced Firewall Settings de forma segura.

La prueba DNS muestra bien por qué importa el entorno de consola. En Device Console, el comando documentado oficialmente es:

dnslookup host example.com

example.com es un valor de documentación seguro; para una prueba real se sustituye por el FQDN afectado. La respuesta solo confirma la resolución desde el firewall. Ante un fallo del cliente, también se comprueban su servidor DNS, la respuesta y la ruta de red.

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:

El default documentado es Disable. Con enable, todos los puertos aceptan conexiones entrantes y se elimina temporalmente la restricción normal de alcance de Device Access. La autenticación de cada servicio sigue siendo un control independiente, pero no convierte esta exposición amplia en algo inocuo.

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 principales archivos de log se encuentran en /log. Sophos documenta primero el cambio a este directorio en Advanced Shell:

cd /log

Comandos básicos útiles:

• Seguir un log en directo: tail -f ips.log. La salida continua solo se mantiene durante la ventana de prueba documentada.
• Leer un archivo de log: less ips.log. Así se muestran las líneas por secciones.
• Buscar un término: grep error ips.log. Adaptar el término y el archivo al fallo.

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.

tcpdump y drop-packet-capture continúan hasta que se detienen con Ctrl+C. Antes de iniciarlos se deben definir el filtro y la ventana de prueba, observar la salida y detener la captura inmediatamente después. Estos comandos no cambian la configuración, pero su carga depende del volumen de tráfico, la amplitud del filtro y el tiempo de ejecución.

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.

Comprobaciones de red en WebAdmin sin CLI

En Diagnostics > Tools se pueden responder las mismas preguntas básicas sin acceso a la consola. Ping permite seleccionar IPv4 o IPv6, la interfaz de salida y el tamaño del paquete. Sophos utiliza 32 bytes de forma predeterminada y admite valores de 1 a 65.507 bytes. Un ping correcto confirma la conectividad ICMP desde la interfaz seleccionada del firewall, pero no que funcione un servicio de aplicación.

Traceroute también admite IPv4, IPv6 o un FQDN y una interfaz de salida elegida de forma consciente. La ausencia de respuesta de algunos saltos no demuestra una interrupción si responden saltos posteriores o el destino. Para analizar una ruta se consideran conjuntamente la conectividad del destino, el último salto que responde y el flujo de paquetes medido en paralelo.

Name lookup consulta un servidor DNS seleccionado. Lookup using all configured servers permite comparar todos los servidores DNS configurados en el firewall y sus tiempos de respuesta. Un único resultado rápido no justifica todavía cambiar la prioridad DNS; también deben ser correctos el contenido de la respuesta, la fiabilidad y la ruta del cliente afectado.

Route lookup muestra por qué interfaz enrutaría el firewall una dirección de destino IPv4 o IPv6. No demuestra la regla de firewall, NAT, la decisión SD-WAN ni un camino de retorno funcional. Para la validación se utilizan después una conexión real, Connection List o Packet Capture.

Comprobar conexiones sin modificar su estado

Filtre las conexiones IPv4 e IPv6 actuales en Current activities > Live connections y Diagnostics > Connection list. Connection list muestra, entre otros datos, interfaces de entrada y salida, origen y destino, Rule ID, NAT ID, direcciones traducidas, estado y contadores Rx/Tx. Es un mejor primer paso que una herramienta no documentada de Advanced Shell.

En Device Console también está documentada esta utilidad de conexiones:

system diagnostics utilities connections

Antes de ejecutarla, compruebe los argumentos disponibles con system diagnostics utilities connections ?. Como Connection list es una instantánea, reproduzca el flujo de prueba mientras actualiza la vista. Si la conexión sigue sin aparecer, realice un Packet Capture acotado; si aparece, continúe con Rule ID, NAT ID, interfaces, traducción y contadores de respuesta.

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

system diagnostics show version-info también muestra el número de serie y el Device ID. Estos identificadores se ocultan antes de compartir salidas o capturas.

Otros destinos de solo lectura son interrupts, syslog, sysmsg, subsystem-info y ctr-log-lines. Responden a preguntas diferentes y no deben tratarse como valores de estado intercambiables:

system diagnostics show interrupts
system diagnostics show syslog
system diagnostics show sysmsg
system diagnostics show subsystem-info
system diagnostics show ctr-log-lines

En XGS Appliances también está disponible system diagnostics selftest para pruebas básicas de la tarjeta de red. El comando no se aplica a otras plataformas y no sustituye una prueba de cable, una medición de rendimiento ni una captura de paquetes. Como Sophos no indica en la página del comando el impacto sobre el tráfico productivo, la prueba solo se ejecuta de forma planificada o por indicación del soporte y se compara con el estado del enlace, los contadores de interfaz y el tráfico real.

En system diagnostics utilities, SFOS agrupa otras herramientas para ARP, ancho de banda, conexiones, DNS, captura de descartes, configuración de red, ping, procesos, rutas y traceroute, incluidas variantes IPv6 cuando Sophos las ofrece. La sintaxis exacta se comprueba en la compilación instalada mediante finalización con Tab. Algunas herramientas solo leen el estado, mientras que otras generan tráfico de prueba o inician una salida continua.

Para una comprobación adicional de solo lectura, Sophos documenta en Advanced Shell:

service -S
service -S | grep ips

La primera variante muestra muchos estados de servicio; la segunda usa el ejemplo de IPS documentado por Sophos. La ausencia de resultados no indica que se deba reiniciar: primero se cotejan el nombre del servicio y el archivo de log con la lista actual de Sophos.

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.

Recopilar logs de debug solo con una salida confirmada

SFOS 22 activa el modo debug en Device Console, no en WebAdmin. Para una prueba controlada con el ejemplo Pktcapd documentado por Sophos, se anotan el espacio libre y la hora de la prueba y se ejecuta:

system diagnostics subsystems Pktcapd debug on

Se reproduce el problema una vez y después se descarga el archivo de log o un Consolidated Troubleshooting Report (CTR) en Diagnostics > Tools > Troubleshooting logs. Debug aumenta el tamaño de los logs y permanece activo hasta desactivarlo. Por eso se ejecuta la reversión documentada inmediatamente después de la descarga:

system diagnostics subsystems Pktcapd debug off

Se documentan ambos comandos y su salida CLI. Si se rechaza un comando, no se improvisa otro de subsistema o servicio: se comprueba la sintaxis con ? y se contacta con Sophos Support. El debug en Advanced Shell se omite deliberadamente porque la sintaxis genérica de servicios no ofrece un comando universal de desactivación para todos los modos.

Para reinicios de servicios y sus efectos, consulte Cómo reiniciar servicios de Sophos Firewall. Reiniciar servicios VPN, IPS, web o de autenticación puede interrumpir sesiones o inicios de sesión activos.

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 en comandos shell, se descargan logs individuales o un CTR en Diagnostics > Tools > Troubleshooting logs y se entregan mediante el portal de soporte acordado. Siga Cómo recopilar 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 han usado de forma específica dnslookup, ping, traceroute, drop-packet-capture o tcpdump en Device Console.
• Debug se ha activado solo brevemente en Diagnostics > Tools > Troubleshooting logs, después se ha desactivado y se ha verificado el estado normal.
• 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