TShark, tcpdump y forense de red: cómo saber qué pasó en tu servidor

Son las nueve de la mañana y tu web se comportó de forma rara esta madrugada: picos de tráfico, un formulario que envió correos que nadie escribió, un log de acceso con peticiones que no encajan. La pregunta del millón no es «¿qué hago ahora?» sino «¿qué pasó exactamente, y puedo demostrarlo?«. Los logs de aplicación cuentan una parte; el resto — quién habló con quién, qué viajó por el cable, si salieron datos y hacia dónde — solo lo sabe el tráfico de red. Y para leer ese tráfico después de un incidente —lo que llamamos forense de red— existe una caja de herramientas veterana, gratuita y sorprendentemente poderosa: tcpdump, TShark y Wireshark.

Este artículo no va de teoría de redes: va de la práctica del análisis forense y la auditoría de sucesos en servidores y aplicaciones web, como parte de una estrategia de seguridad informática integral. Cuándo capturar con tcpdump en un servidor de producción sin tumbarlo, cómo exprimir un fichero pcap con TShark desde la línea de comandos, cuándo pasar a Wireshark para el análisis visual, y — lo más importante para que el trabajo sirva de algo — cómo preservar la evidencia para que se sostenga en un informe. Es el complemento reactivo de la detección continua que vimos al comparar Suricata, Snort y Zeek como IDS: aquellos vigilan en tiempo real; estos reconstruyen lo que ya ocurrió.

1. Auditoría y forense de red: qué buscamos y por qué

Cuando hablamos de forense de red nos referimos a reconstruir, a partir del tráfico capturado, la secuencia real de eventos de un incidente: el análisis de una intrusión, una fuga de datos, un abuso de una aplicación o simplemente un comportamiento anómalo que hay que explicar. Se diferencia del forense de disco en que la evidencia es efímera — el paquete que no capturaste ya no existe — y de la monitorización continua en que suele ser una investigación puntual y dirigida.

Las preguntas que este trabajo responde son muy concretas: ¿desde qué IPs vino el ataque y en qué orden? ¿Qué peticiones exactas se hicieron contra el endpoint vulnerable? ¿Se estableció una conexión de salida hacia un servidor de control? ¿Salieron datos, cuántos y hacia dónde? ¿La sesión iba cifrada o en claro? Responderlas con evidencia — no con suposiciones — es lo que distingue una auditoría seria de un «creemos que fue esto». Y en un mundo donde marcos como ISO 27001 y el ENS exigen capacidad de respuesta a incidentes, tener esta competencia (o un proveedor que la tenga) ha dejado de ser opcional.

2. Las tres herramientas y su base de trabajo

tcpdump, TShark y Wireshark no compiten: son tres formas de tocar el mismo material — los paquetes — pensadas para tres momentos distintos del trabajo.

2.1 tcpdump: el bisturí que ya está en el servidor

tcpdump es el capturador universal: viene preinstalado o a un apt install de distancia en prácticamente cualquier Linux o BSD, consume muy poco y se maneja entero por SSH. Su base de trabajo son los filtros BPF (Berkeley Packet Filter), que deciden qué paquetes se capturan a nivel de kernel — es decir, antes de gastar recursos. Su límite es deliberado: captura y filtra por cabeceras (IPs, puertos, flags), pero no entiende protocolos de aplicación. La filosofía clásica es «captura con tcpdump en el servidor, analiza el pcap en otro sitio».

La captura mínima de un incidente sobre un servidor web tiene esta pinta:

# Capturar tráfico web hacia/desde una IP sospechosa, guardando a fichero
tcpdump -i eth0 -w /var/tmp/incidente.pcap -s 0 host 203.0.113.45 and port 80 or port 443

# Limitar tamaño para no llenar el disco: 100 ficheros rotados de 50 MB
tcpdump -i eth0 -w /var/tmp/inc-%Y%m%d-%H%M.pcap -C 50 -W 100 -Z root 'tcp port 443'

Dos detalles que separan al profesional del aficionado: -s 0 captura el paquete completo (no solo la cabecera), imprescindible si luego quieres ver contenido; y la rotación por tamaño evita el error clásico de llenar el disco de producción a media investigación.

2.2 TShark: la potencia de Wireshark sin la ventana

TShark es la versión de consola de Wireshark: usa exactamente el mismo motor de captura y los mismos disectores de protocolo, pero vuelca el resultado a la terminal o a ficheros. Eso le da lo que a tcpdump le falta — entiende HTTP, DNS, TLS, SMB y cientos de protocolos más — sin necesitar entorno gráfico, lo que lo hace perfecto para analizar directamente en un servidor headless o para automatizar. Su base de trabajo son los filtros de visualización de Wireshark (mucho más ricos que BPF: http.request.method == "POST", dns.qry.name contains "exfil"), la extracción de campos concretos y las estadísticas.

Ejemplos que resuelven preguntas forenses reales sobre un pcap ya capturado:

# Todas las peticiones HTTP con su método, host y URI
tshark -r incidente.pcap -Y "http.request" -T fields -e ip.src -e http.request.method -e http.host -e http.request.uri

# ¿Qué dominios se resolvieron? (caza de C2 y exfiltración por DNS)
tshark -r incidente.pcap -Y "dns.flags.response == 0" -T fields -e dns.qry.name | sort | uniq -c | sort -rn

# Ranking de conversaciones por volumen: ¿quién se llevó más datos?
tshark -r incidente.pcap -q -z conv,ip

# Extraer los ficheros transferidos por HTTP para analizarlos
tshark -r incidente.pcap --export-objects http,/var/tmp/objetos/

Esa última línea es oro puro en una investigación: reconstruye y saca a disco los ficheros que viajaron por HTTP — el webshell que subieron, el binario que se descargó — listos para pasarles un antivirus o un análisis.

2.3 Wireshark: el laboratorio para el análisis profundo

Cuando ya has acotado el pcap a lo relevante, Wireshark es donde se hace la disección fina: seguir una conversación TCP completa (Follow Stream) para leer un diálogo HTTP como si fuera un chat, ver gráficas de flujo, usar el sistema de «expert info» que marca anomalías, y armar el relato visual que acaba en el informe. La regla práctica: no se instala en el servidor de producción (es pesado y gráfico); el pcap se copia a la estación del analista y se abre allí.

3. Un caso real: peticiones sospechosas contra un WordPress

Aterricemos con un incidente típico. Los logs de acceso de un WordPress muestran, de madrugada, cientos de POST a /xmlrpc.php y algún acceso extraño a /wp-admin. ¿Ataque de fuerza bruta? ¿Alguien entró? El log de aplicación no basta: necesitamos el tráfico. El flujo de trabajo sería:

1. Capturar (si el ataque sigue vivo) con tcpdump filtrando por el puerto 443 y, si es posible, por las IPs que aparecen en el log. Si ya pasó, recuperar el pcap de la captura rotatoria si existía — de ahí la importancia de la preparación forense que veremos luego.
2. Filtrar con TShark las peticiones a /xmlrpc.php y contar cuántas por IP: si son miles desde pocas IPs con respuestas 200 esporádicas, es fuerza bruta con algún acierto. El comando de ranking de conversaciones dice enseguida si alguna IP recibió mucho más tráfico de vuelta del normal — señal de que consiguió algo.
3. Seguir la sesión sospechosa en Wireshark: si tras un login exitoso hubo subida de un fichero PHP (un webshell), el Follow Stream lo muestra, y --export-objects lo recupera para confirmarlo.
4. Documentar: IPs, timestamps, número de intentos, momento del primer acceso exitoso, fichero subido y su hash. Eso es una auditoría; «nos atacaron por xmlrpc» es una anécdota.

La lección de fondo conecta con lo que ya contamos en la guía de seguridad de WordPress para empresas: la mitad del valor está en poder reconstruir el incidente, no solo en pararlo.

4. Preservar la evidencia: sin esto, el análisis no vale como prueba

Aquí es donde la mayoría de investigaciones caseras se estropean. Un pcap analizado sin cuidado sirve para entender qué pasó, pero no para sostener una reclamación, un parte a la aseguradora o una denuncia. Las reglas mínimas de la cadena de custodia:

• Calcula el hash del pcap nada más capturarlo (sha256sum incidente.pcap) y anótalo. Cualquier análisis posterior se hace sobre copias; el original no se toca. Si el hash coincide al final, nadie puede alegar que la evidencia se manipuló.
• Hora fiable. Los timestamps de los paquetes solo valen si el reloj del servidor estaba sincronizado por NTP. Verifícalo y documéntalo: un forense con relojes descuadrados es un forense sin línea temporal.
• Trabaja sobre copias de solo lectura y registra quién tocó qué y cuándo. En incidentes con posible recorrido legal, cuanto antes entre un perito acreditado, mejor — el trabajo técnico que describimos aquí es la base, pero la validez judicial tiene sus formalidades.
• Cuidado con los datos personales. Un pcap puede contener credenciales, datos de clientes o información sensible en claro. Se custodia con el mismo celo que cualquier dato personal bajo RGPD: acceso restringido, cifrado en reposo, retención acotada.

5. El reto del tráfico cifrado (y por qué los logs siguen importando)

Hoy casi todo va por HTTPS, y eso significa que un pcap de tráfico TLS te muestra el sobre pero no la carta: ves con quién se habló, cuándo, cuánto volumen y qué certificado se negoció — metadatos valiosísimos para detectar C2 o exfiltración — pero no el contenido. Descifrarlo solo es posible en tus propios servicios y con preparación previa (claves de sesión exportadas, terminación TLS en un proxy que registre). Por eso el forense de red no vive solo: se combina con los logs del servidor y de la aplicación, que sí ven el contenido ya descifrado. El pcap dice «esta IP abrió 400 conexiones a las 3:14»; el log de acceso dice «y pidió estas 400 URLs». Juntos cierran el caso.

Esto refuerza una idea que repetimos mucho: la preparación forense (forensic readiness) se monta antes del incidente. Logs centralizados con retención suficiente, hora sincronizada, y — en entornos críticos — captura de tráfico rotatoria hacia un almacenamiento aparte. El día del incidente no se improvisa la evidencia; se recoge la que tuviste la disciplina de guardar.

6. Otras herramientas del ecosistema

tcpdump, TShark y Wireshark son el núcleo, pero conviene conocer a sus vecinos: tcpflow reconstruye flujos TCP a ficheros de forma muy directa; ngrep es como grep sobre el tráfico, cómodo para búsquedas rápidas de cadenas; Zeek — que ya tratamos como IDS — genera logs estructurados de conexiones, DNS y TLS perfectos para el forense a posteriori; y las plataformas de captura completa (full packet capture como Arkime/Moloch) indexan grandes volúmenes de pcap para buscar en ellos meses después. Para una pyme, el núcleo gratuito cubre el 90% de los casos; las plataformas grandes entran cuando el volumen y los requisitos regulatorios lo justifican.

7. Errores que arruinan una investigación forense

\n\n

La diferencia entre un análisis que aguanta y uno que se cae no suele estar en el conocimiento de los comandos, sino en evitar unos cuantos errores de proceso que hemos visto una y otra vez:

\n\n

\n
• Actuar sobre el sistema antes de capturar. El impulso de «limpiar» el servidor comprometido — borrar el webshell, reiniciar servicios, banear la IP — destruye evidencia viva: conexiones abiertas, procesos en memoria, tráfico en curso. Regla de oro: primero se preserva (captura, volcado de memoria, copia de logs), después se remedia.

\n

• Capturar sin filtro en un enlace saturado. Un tcpdump a pelo en una interfaz con gigabits de tráfico llena el disco en minutos y, peor, pierde paquetes (drops) que dejan agujeros justo en la parte interesante. Filtrar por BPF no es opcional en producción.

\n

• Confiar en relojes descuadrados. Si el servidor web, el firewall y tu estación de análisis marcan horas distintas, correlacionar sus registros se vuelve un ejercicio de adivinación. NTP en todo, verificado y documentado, es la columna vertebral de cualquier línea temporal.

\n

• Trabajar sobre el original. Abrir el único pcap en una herramienta que podría modificarlo, sin haber calculado antes el hash ni haber hecho copia, es tirar la validez por la ventana. Original intacto, análisis sobre copias.

\n

• No documentar mientras se investiga. Reconstruir tres días después qué comando se lanzó y qué se dedujo es imposible. Un cuaderno de bitácora del incidente — hora, acción, hallazgo — con los comandos exactos convierte el trabajo en un informe reproducible.

\n

\n\n

Todo esto encaja en un proceso de respuesta a incidentes más amplio (identificación, contención, erradicación, recuperación y lecciones aprendidas). El forense de red es la fase de identificación bien hecha: sin ella, la contención es a ciegas y las lecciones aprendidas, humo. Es exactamente la capacidad que los marcos de seguridad esperan que una empresa tenga documentada y ensayada, no improvisada la noche del ataque.

\n\n

Conclusión

Saber qué pasó en tu servidor no es magia ni requiere herramientas caras: requiere método y tres utilidades que llevan décadas siendo el estándar. tcpdump captura ligero allí donde ocurre el incidente; TShark exprime el pcap desde la consola, entendiendo los protocolos y automatizando lo repetitivo; Wireshark disecciona en visual lo que ya has acotado. Y por encima de las tres, la disciplina que convierte un análisis en una prueba: capturar acotado, preservar con hash y hora fiable, trabajar sobre copias y documentarlo todo.

La inversión más rentable, sin embargo, no es aprender los comandos: es preparar la infraestructura para que, el día que pase algo, la evidencia exista. Porque el mejor analista del mundo no puede reconstruir un incidente a partir de un tráfico que nadie capturó.

Preguntas frecuentes sobre forense de red

¿Puedo usar tcpdump en un servidor de producción sin riesgo?

Sí, con cabeza. tcpdump consume poco, pero una captura sin filtrar en un servidor con mucho tráfico puede generar ficheros enormes y algo de carga. Las claves: filtra siempre por BPF (host, puerto, ventana temporal), usa rotación por tamaño para no llenar el disco, y escribe el pcap a un volumen que no sea el del sistema. Capturas acotadas, no «todo por si acaso».

¿tcpdump o TShark? ¿Cuál elijo?

No es o uno u otro: se usan en fases distintas. tcpdump para capturar en el servidor (ligero, siempre disponible por SSH); TShark para analizar el pcap resultante (entiende protocolos, extrae campos, automatiza). El patrón habitual es capturar con tcpdump y analizar con TShark o Wireshark.

Si el tráfico va cifrado con HTTPS, ¿sirve de algo capturarlo?

Sí, aunque no veas el contenido. Los metadatos del tráfico TLS — IPs, tiempos, volumen, certificados, nombres de servidor (SNI) — permiten detectar conexiones a servidores de control, exfiltración por volumen y patrones anómalos. Para el contenido descifrado, se combina con los logs de la propia aplicación, que lo ven en claro. Forense de red y análisis de logs son complementarios.