Ir al contenido
Avanet

Usar tcpdump en Sophos Firewall de forma segura

tcpdump es la herramienta adecuada cuando se necesita ver con más detalle qué paquetes realmente llegan al Sophos Firewall, a través de qué interfaz pasan y si surge un problema antes, en o detrás del firewall. Complementa Log Viewer, WebAdmin Packet Capture y Service-Logs, pero no los reemplaza.

Para análisis rápidos en el navegador, usar Sophos Firewall Packet Capture en WebAdmin suele ser más cómodo. Para capturas más largas, filtros muy precisos, archivos PCAP o casos de soporte, tcpdump a través de SSH suele ser más adecuado.

⚠️ Importante: Las capturas de paquetes pueden contener datos sensibles: direcciones IP internas, hostnames, nombres de usuario, consultas DNS, detalles de certificados o datos útiles sin cifrar. Por lo tanto, deben filtrarse estrechamente, grabarse solo el tiempo necesario, documentarse y transmitirse solo a través de canales seguros. Una captura sin filtrar en any puede generar muchos datos en firewalls productivos.

Selección de herramienta y requisitos previos

¿Qué artículo es el adecuado?

tcpdump no es el primer paso para cada análisis. Dependiendo de la pregunta, otro punto de partida puede ser más rápido:

Esta separación ahorra tiempo y reduce el riesgo. tcpdump proporciona datos de paquetes sólidos, pero no decisiones de políticas específicas de Sophos. Rule ID, NAT ID, Drop Reason, Web Policy, IPS o inspección SSL/TLS deben verificarse en paralelo en el Log Viewer, en el WebAdmin Packet Capture o en los archivos de registro correspondientes.

Requisitos previos

Para esta guía se necesita:

  • Acceso administrativo al Sophos Firewall.
  • Acceso SSH al firewall o acceso a la Advanced Shell.
  • La IP de origen, IP de destino, puerto de destino y el protocolo afectado.
  • Suficiente espacio libre en disco si se va a escribir un archivo PCAP.
  • Wireshark u otra herramienta de análisis en el cliente administrador si se va a evaluar un archivo PCAP.

Cómo preparar SSH de manera segura se detalla en Conectar Sophos Firewall por SSH. Para fundamentos generales de CLI, también es útil Solución de problemas de CLI en Sophos Firewall: comandos importantes.

Cuándo tcpdump es el siguiente paso correcto

tcpdump no debería ser automáticamente el primer paso. Si solo se quiere saber qué regla de firewall, regla NAT, política web o regla de inspección SSL/TLS ha decidido, el Log Viewer es más rápido y más legible. Si se quiere ver en el navegador si llegan, se reenvían o se descartan paquetes individuales, a menudo basta con Packet Capture en WebAdmin.

tcpdump es especialmente útil cuando se cumple alguno de estos puntos:

  • La captura debe evaluarse como un archivo PCAP en Wireshark o por soporte.
  • La captura de WebAdmin es demasiado corta, confusa o el buffer se llena.
  • La prueba debe ejecutarse durante una ventana de mantenimiento, una llamada telefónica o un error de usuario reproducible.
  • Se necesitan filtros CLI precisos, por ejemplo, para VoIP, DNS, IPsec, varios hosts o rangos de puertos.
  • El tráfico relevante debe compararse primero en any y luego en una interfaz concreta.

Es importante la expectativa: tcpdump muestra paquetes, pero no decisiones específicas de Sophos como Rule ID, NAT ID, Drop Reason o Web Policy. Esta información debe verificarse en paralelo en el Log Viewer, WebAdmin Packet Capture o archivos de registro correspondientes.

Advanced Shell o Device Console?

tcpdump puede aparecer en dos contextos CLI en Sophos Firewall. La Sophos Device Console incluye su propio comando tcpdump con sintaxis Sophos y opciones como filedump. La Advanced Shell ofrece además el tcpdump más parecido a Linux, que en casos de soporte suele ser más práctico porque permite trabajar con procesos, scp, /tmp y otras herramientas de shell.

Esta distinción es importante:

  • Device Console: Adecuada para el comando Sophos CLI tcpdump. Antes de ejecutarlo conviene comprobar la sintaxis con Tab o ?. Según Sophos, una salida creada con filedump se guarda en /tmp.
  • Advanced Shell: Adecuada para flujos clásicos de shell con tcpdump, ps, df, grep, scp, acceso a archivos y parada consciente de procesos en ejecución.

Este artículo utiliza deliberadamente la Advanced Shell porque los archivos PCAP, procesos en segundo plano, scp y limpieza posterior encajan allí de forma más comprensible. Si se usa tcpdump en la Device Console, se aplican las mismas reglas básicas: filtros estrechos, ventana corta de captura, comprobar espacio libre y comparar el resultado con Log Viewer o WebAdmin Packet Capture.

Si no está claro en qué consola se encuentra, la visión general Solución de problemas de Sophos Firewall: Servicios y registros puede ayudar.

Preparar la captura

Delimitar antes de comenzar

Antes de una captura, se deben anotar los parámetros de análisis:

  • IP de origen: por ejemplo 172.16.10.25.
  • IP de destino: por ejemplo 198.51.100.20.
  • Protocolo: por ejemplo TCP.
  • Puerto de destino: por ejemplo 443.
  • Interfaz esperada: LAN, WAN o interfaz VPN.
  • Momento de la prueba: hora exacta con zona horaria.
  • Resultado esperado: conexión permitida, bloqueada, DNAT, SNAT, VPN o Drop.
  • Comprobación paralela: Log Viewer, Packet Capture, Service-Log o ticket de soporte.

Cuanto más estrecho sea el filtro, mejor será el resultado. Una captura sin filtro generalmente solo es útil en firewalls muy tranquilos.

La prueba debe ser reproducible. Si varias personas cambian configuraciones al mismo tiempo o varios clientes prueban, la captura se vuelve difícil de interpretar. Es mejor un solo cliente de prueba, un marco de tiempo estrecho y una pregunta clara: ¿Llega el paquete? ¿Sale? ¿Vuelve la respuesta? ¿Qué regla, regla NAT o policy se ve en paralelo?

Para pruebas de reglas, también es útil Probar reglas de Sophos Firewall con Log Viewer y Packet Capture. Si el enfoque está en Drop, Violation, Rule ID o NAT ID, Analizar paquetes descartados en Sophos Firewall es el artículo de seguimiento más adecuado.

Ejecutar tcpdump

Ejecutar tcpdump en vivo

Para una primera verificación en vivo, a menudo basta con un filtro de host:

tcpdump -i any -nn host 198.51.100.20

Los parámetros:

  • -i any: capturar en todas las interfaces.
  • -nn: no realizar resolución de nombres DNS o de puertos.
  • host 198.51.100.20: mostrar solo paquetes de o hacia esta IP.

Para una prueba web, es útil un filtro de puerto adicional:

tcpdump -i any -nn 'host 198.51.100.20 and port 443'

Las expresiones de filtro con and, or o not deben colocarse entre comillas simples. Esto mantiene la expresión unida y evita que la Shell la descomponga.

Ejemplos comunes de filtros

  • Host específico: tcpdump -i any -nn 'host 198.51.100.20'
  • IP de origen específica: tcpdump -i any -nn 'src host 172.16.10.25'
  • IP de destino específica: tcpdump -i any -nn 'dst host 198.51.100.20'
  • Red específica: tcpdump -i any -nn 'net 172.16.10.0/24'
  • Puerto específico: tcpdump -i any -nn 'port 443'
  • Host y puerto: tcpdump -i any -nn 'host 198.51.100.20 and port 443'
  • ICMP / Ping: tcpdump -i any -nn 'proto ICMP'
  • DNS: tcpdump -i any -nn 'port 53'
  • Todos los puertos excepto SSH: tcpdump -i any -nn 'host 198.51.100.20 and port not 22'

En problemas de VPN, VLAN o enrutamiento, puede ser útil no limitarse a any, sino a una interfaz concreta. Los nombres de las interfaces deben coincidir con el firewall correspondiente. A menudo es práctico este orden:

  1. Revisar brevemente en any si el host o puerto esperado aparece.
  2. Después capturar en la interfaz de entrada presumida.
  3. Después capturar en la interfaz de salida presumida.
  4. Comparar las tres observaciones con Log Viewer, NAT ID, Rule ID o Drop Reason.

Así se reconoce más rápido si el tráfico no llega al firewall, se detiene en el firewall o la respuesta falta en el camino de vuelta.

Limitar la captura

Una captura debe limitarse para que no se ejecute innecesariamente durante mucho tiempo.

Con -c, tcpdump se detiene después de un número fijo de paquetes:

tcpdump -i any -nn -c 100 'host 198.51.100.20 and port 443'

Para pruebas cortas, esto suele ser más limpio que un proceso en segundo plano. Se inicia la captura, se reproduce el problema y luego se obtiene automáticamente la salida.

Escribir un archivo PCAP

Si la captura se va a analizar más tarde en Wireshark o por soporte, se escribe un archivo PCAP en /tmp.

tcpdump -i any -nn -s 0 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Parámetros importantes:

  • -s 0: capturar paquetes completos.
  • -w /tmp/sophos-capture.pcap: escribir salida en un archivo PCAP.
  • -nn: desactivar resolución de nombres.

-s 0 es útil cuando se necesita una captura completa. Al mismo tiempo, aumenta el riesgo de privacidad, ya que se captura más contenido del paquete. Para preguntas de flujo o encabezado, a menudo basta con una captura en vivo sin archivo PCAP o una captura corta con filtrado estrecho.

Antes de capturas grandes, se debe verificar el espacio libre en disco:

df -h /tmp
df -h /var

Si el problema solo necesita reproducirse brevemente, también se puede agregar -c aquí:

tcpdump -i any -nn -s 0 -c 500 -w /tmp/sophos-capture.pcap 'host 198.51.100.20 and port 443'

Después de iniciar, se debe reproducir inmediatamente la prueba y no dejar que la captura continúe innecesariamente. Un PCAP que contiene cinco minutos de más no solo es más grande, sino que a menudo también contiene más información sensible adicional.

Para casos de soporte, el nombre de archivo debe contener contexto neutro, pero no nombres de clientes, nombres de usuario ni hostnames confidenciales. Son mejores nombres como /tmp/ticket-12345-wan-443.pcap o /tmp/vpn-test-20260629.pcap.

Iniciar y detener un proceso en segundo plano

A veces, una captura debe ejecutarse mientras se realiza otra prueba. Entonces, tcpdump puede iniciarse en segundo plano.

tcpdump -i any -nn -s 0 -w /tmp/voip-test.pcap 'host 192.0.2.50 and portrange 5060-5090' &

Mostrar trabajos en ejecución:

jobs

Terminar trabajo:

kill %1

Si hay varios procesos tcpdump en ejecución o el trabajo ya no es visible en la Shell actual, primero verifique los procesos:

ps | grep tcpdump

Luego termine el proceso correspondiente. killall tcpdump solo debe usarse si está claro que no hay otras capturas importantes en ejecución.

Después de detener, se debe verificar si el archivo PCAP se escribió y tiene un tamaño plausible:

ls -lh /tmp/*.pcap

Si se planifica una captura en segundo plano para una cita de soporte, antes debe estar claro quién la inicia, quién la detiene y dónde queda el archivo después. Una captura olvidada no es un problema raro de troubleshooting, sino un riesgo operativo evitable.

Ejemplo: Analizar VoIP o 3CX

En problemas de VoIP, la señalización SIP y el flujo de medios RTP a menudo deben considerarse por separado. Una sola captura en port 5060 solo muestra una parte del problema.

Para una primera prueba de 3CX, se puede capturar el host PBX:

tcpdump -i any -nn -s 0 -w /tmp/3cx-test.pcap 'host 192.0.2.50'

Si el tráfico es demasiado amplio, se puede restringir más a SIP:

tcpdump -i any -nn -s 0 -w /tmp/3cx-sip.pcap 'host 192.0.2.50 and portrange 5060-5090'

Para problemas de audio, también se debe verificar el rango de puertos RTP realmente utilizado. Esto depende de la central telefónica y su configuración.

En temas de VoIP de Sophos Firewall, también se debe revisar Optimizar configuraciones de VoIP en Sophos Firewall.

Evaluación y limpieza

Descargar y limpiar el archivo PCAP

Un archivo PCAP puede copiarse a un servidor interno mediante scp:

scp /tmp/sophos-capture.pcap adminuser@192.0.2.10:/tmp/

Dependiendo del entorno, también se puede utilizar otro método de transferencia seguro. Se debe evitar FTP con credenciales fijas.

Después de una transferencia exitosa, se debe eliminar el archivo del firewall:

rm /tmp/sophos-capture.pcap

Para archivos de registro completos y casos de soporte, Guardar registros de Sophos Firewall para soporte y análisis es la guía más adecuada.

Contexto para soporte o análisis externo

Un archivo PCAP sin contexto es difícil de evaluar. Para Sophos Support, Avanet o un partner de análisis externo, deberían entregarse al menos estos datos:

  • Ventana temporal: por ejemplo 2026-06-29, 14:05-14:08 Europe/Zurich.
  • Flujo esperado: por ejemplo cliente 172.16.10.25 a servidor 198.51.100.20:443.
  • Función afectada: DNAT, IPsec, SSL VPN, Webfilter, VoIP, DNS o routing.
  • Observación: por ejemplo SYN visible, sin SYN-ACK, Drop en Log Viewer o sin respuesta del destino.
  • Comprobado en paralelo: Rule ID, NAT ID, Packet Capture y Service-Logs relevantes.
  • Cambio antes del error: firmware, cambio de regla, cambio de proveedor, certificado o SD-WAN route.

Antes de entregar la captura, se debe comprobar si el archivo contiene nombres internos, direcciones privadas, IP públicas de clientes o contenido sin cifrar. Si el contenido no puede anonimizarse, destinatarios, canal de transmisión y conservación deben decidirse conscientemente.

Evaluar correctamente tcpdump

Al evaluar, no solo se trata de si los paquetes son visibles. Lo crucial es lo que falta.

  • No se ven paquetes del cliente: el problema está antes del firewall. Revisar cliente, VLAN, gateway, switch o routing hacia el firewall.
  • Los paquetes entran, pero no salen: revisar regla de firewall, NAT, routing, función de seguridad o policy.
  • Los paquetes salen, pero no llega respuesta: revisar sistema de destino, ruta de retorno, firewall opuesto, NAT o proveedor.
  • Solo SYN, no SYN-ACK: el destino o la ruta de retorno no responde.
  • Solicitud ICMP visible, falta respuesta: revisar ruta de retorno, firewall de destino o contraparte.
  • Consulta DNS visible, no hay respuesta: revisar servidor DNS, ruta, regla o upstream.
  • Paquete visible solo en any, pero no en la interfaz esperada: revisar supuesto de interfaz, zona, ruta o asignación de túnel.
  • Paquete visible en la interfaz de entrada, pero no en la de salida: revisar regla, NAT, ruta, función de seguridad o Drop Reason.

tcpdump muestra el flujo de paquetes. La decisión de política en sí se verifica en paralelo en el Log Viewer. En preguntas de firewall y NAT, a menudo la combinación de Log Viewer, Packet Capture y tcpdump es la más rápida.

Para errores de NAT, también se debe entender que NAT solo traduce el tráfico, pero no lo permite. La base adecuada es Entender NAT en Sophos Firewall: SNAT, DNAT, MASQ, PAT. En túneles IPsec, ayudan en paralelo Solución de problemas de VPN IPsec en Sophos Firewall y los registros VPN correspondientes.

Errores comunes y lista de verificación

Errores típicos

  • Captura sin filtro: demasiados datos, difícil de evaluar. Delimitar siempre por host, red, puerto o protocolo.
  • Captura no detenida: el espacio en disco y el rendimiento pueden sufrir. Usar -c o terminar correctamente el proceso en segundo plano.
  • Solo se evaluó any: un problema de interfaz o túnel queda oculto. Tras el primer hallazgo, comparar específicamente interfaz de entrada y de salida.
  • Solo se verificó la dirección de ida: se pasa por alto el problema de la ruta de retorno. Considerar ambas direcciones.
  • Se eligió la interfaz incorrecta: faltan paquetes relevantes. Primero any, luego delimitar a la interfaz específica.
  • PCAP compartido sin cifrar: los datos sensibles pueden ser expuestos. Usar transferencia segura y grupo mínimo de destinatarios.
  • Archivo dejado después del caso de soporte: consumo innecesario de espacio y riesgo de datos. Eliminar PCAP después de la transferencia.

Lista de verificación

  • IP de origen, IP de destino, puerto y protocolo conocidos.
  • Acceso SSH al firewall configurado de manera segura.
  • Decidido previamente si Log Viewer o WebAdmin Packet Capture serían suficientes.
  • Filtro elegido lo más estrecho posible.
  • Captura limitada con -c o proceso de detención claro.
  • Archivo PCAP escrito solo si es necesario.
  • En preguntas de interfaz, primero comparado any y luego interfaces de entrada y salida.
  • Problema reproducido específicamente durante la captura.
  • Hora de la prueba documentada.
  • Log Viewer verificado en paralelo.
  • Rule ID, NAT ID, Drop Reason o Service-Log anotados si estaban visibles.
  • PCAP transferido de manera segura.
  • Archivo PCAP temporal eliminado del firewall.

FAQ

¿Qué es mejor: WebAdmin Packet Capture o tcpdump?

Para análisis rápidos directamente en el navegador, el WebAdmin Packet Capture es ideal. Para capturas más largas, archivos PCAP, filtros más precisos o casos de soporte, tcpdump es más adecuado.

¿Se debe iniciar tcpdump en any o en una interfaz?

Para una primera delimitación, any es práctico, ya que no se pierden paquetes debido a un filtro de interfaz incorrecto. Una vez que está claro qué interfaz es relevante, se debe filtrar de manera más específica.

¿Por qué se debe usar -nn?

-nn evita la resolución de nombres DNS y de puertos. Esto hace que la salida comience más rápido y sea menos distorsionada por la resolución de nombres.

¿Siempre se debe usar -s 0 en archivos PCAP?

No. -s 0 captura paquetes completos y es útil para análisis detallados. Sin embargo, para muchas verificaciones iniciales, bastan las informaciones de encabezado o una captura en vivo corta. Cuanto más contenido se capture, más importantes son la privacidad y la transferencia segura.

¿Dónde se deben guardar los archivos PCAP?

Para capturas temporales, /tmp es común. El archivo debe eliminarse después de la transferencia.

¿Por qué tcpdump no muestra Rule ID ni NAT ID?

tcpdump muestra paquetes a nivel de sistema operativo e interfaz. Decisiones específicas de Sophos como Rule ID, NAT ID, Web Policy, IPS Policy o Drop Reason se ven en Log Viewer, WebAdmin Packet Capture o en los archivos de log adecuados.