Cómo capturar y analizar un ataque DDoS con Wireshark (y tcpdump)

Primero la respuesta: el flujo de trabajo

Analizar un ataque contra tu propia infraestructura es una tarea de cinco pasos, y cada paso existe para responder una pregunta: de qué vector de ataque se trata, para que se pueda aplicar la mitigación correcta. (Para saber cuáles son los vectores y cómo se detiene cada uno, consulta nuestro artículo complementario, Los ataques DDoS explicados.)

1. Captura una muestra con tcpdump: longitud de snapshot pequeña, tamaño acotado, nunca la GUI de Wireshark en la máquina víctima.
2. Saca la captura del servidor y ábrela en Wireshark en tu estación de trabajo.
3. Trata con los menús de Statistics: Protocol Hierarchy te indica qué es el tráfico, Conversations te indica quién está implicado, I/O Graphs te indica cuándo y con qué intensidad.
4. Confirma el vector con filtros de visualización: cada familia de ataque tiene una firma reconocible.
5. Convierte los hallazgos en acción: una regla de firewall donde el filtrado en el host ayuda, y un informe concreto y accionable a tu proveedor donde no es el caso.

Una aclaración de alcance antes de las herramientas: esta es una guía de forense defensivo, sobre analizar ataques que golpean infraestructura que tú operas, con capturas que tienes derecho a realizar. Si quieres practicar antes de necesitarlo (buena idea: en mitad de un ataque es mal momento para aprender Wireshark), hay capturas de ataques públicas para entrenar, listadas al final.

Paso 1: capturar bajo carga sin empeorar las cosas

El instinto de abrir Wireshark en el servidor atacado es doblemente erróneo: la GUI, al diseccionar millones de paquetes por segundo, termina el trabajo de agotamiento de recursos que empezó el atacante, y una captura ingenua escribe paquetes completos a disco al ritmo del ataque, gigabytes por minuto. La herramienta correcta en la víctima es tcpdump (o dumpcap, el motor de captura de Wireshark, si está instalado), configurada para que salga barata:

# 30-second sample, headers only, no DNS lookups, bounded packet count
tcpdump -i eth0 -n -s 128 -c 500000 -w /tmp/attack-sample.pcap

Por qué cada flag se gana su lugar:

• -s 128 limita los bytes capturados por paquete. Para identificar el vector necesitas cabeceras, no payloads; las cabeceras Ethernet + IP + TCP/UDP más un poco de margen caben sin problema en 128 bytes. Esto pesa más de lo que parece: la longitud de snapshot por defecto del tcpdump moderno es de 262,144 bytes, así que un snaplen explícitamente pequeño es lo que mantiene el archivo pequeño y el coste por paquete bajo.
• -n desactiva la resolución de nombres. Resolver miles de IP atacantes vía DNS (posiblemente mientras tu enlace está saturado) es autosabotaje.
• -c 500000 se detiene tras medio millón de paquetes, pase lo que pase. Una captura acotada no puede llenar tu disco.
• -w file escribe los paquetes en bruto para su análisis posterior en lugar de decodificarlos en la terminal (decodificar cuesta CPU; la terminal cuesta el ancho de banda de tu sesión SSH).

Si el ataque se sostiene y quieres visibilidad continua en lugar de una sola muestra, usa un buffer circular para que el uso de disco se mantenga constante sin importar cuánto dure:

# rotate at 100 MB, keep at most 10 files (~1 GB ceiling), overwrite oldest
tcpdump -i eth0 -n -s 128 -w /tmp/attack-ring.pcap -C 100 -W 10

Dos notas prácticas. Primero, añade un filtro de captura para reducir el ruido cuando ya conoces el objetivo, por ejemplo tcpdump ... dst host 203.0.113.10 (sustituye por tu propia dirección; los ejemplos de esta guía usan rangos de documentación). Segundo, a tasas de paquetes extremas incluso tcpdump descarta paquetes; informa de cuántos al salir. Para la identificación del vector eso no es problema: una muestra es todo lo que necesitas, y la verdad estadística sobrevive a las pérdidas. (Si necesitas una captura completa a tasas altas, eso es terreno especializado: dumpcap con un buffer grande, o tecnologías de muestreo como sFlow a nivel de switch, pero no hace falta para el triaje.)

Paso 2: sacar la captura de la máquina

El análisis ocurre en tu estación de trabajo, no en el servidor herido:

scp server:/tmp/attack-sample.pcap .

Ábrela en Wireshark; la versión estable actual es la serie 4.6. Si el archivo es enorme a pesar de tus límites, se aplica la propia guía de rendimiento de Wireshark: los archivos que superan unos pocos cientos de megabytes se vuelven lentos, así que corta primero un fragmento (editcap -c 1000000 big.pcap slice.pcap divide por número de paquetes; editcap se incluye con Wireshark).

Paso 3: triaje, tres ventanas de Statistics

No empieces desplazándote por los paquetes; empieza por las vistas agregadas. Tres ventanas, en orden:

Protocol Hierarchy (Statistics → Protocol Hierarchy)

Un vistazo responde a "¿qué es este tráfico?": el árbol de protocolos con porcentajes de paquetes y bytes. La captura de un servidor web sano está dominada por TCP/TLS. Una captura de ataque suele estar grotescamente sesgada: 95 % de UDP donde no sirves nada de eso, o un muro de paquetes TCP desnudos sin protocolo de capa de aplicación encima (la firma de una flood de paquetes de handshake que nunca llegan a ser conexiones).

Conversations (Statistics → Conversations)

La tabla de quién-habla-con-quién, ordenable por paquetes, bytes y duración. Qué leer en ella:

• Dispersión de fuentes. Diez mil direcciones origen que envían cada una unos pocos cientos de paquetes a un mismo destino es una flood distribuida (o spoofing; el paso 4 distingue entre ambos). Un puñado de fuentes que envían millones de paquetes es algo que puedes bloquear hoy mismo con una null route.
• Ordena por paquetes, no por bytes, en ataques de tasa de paquetes: un SYN flood es enorme en número de paquetes y modesto en bytes.
• La diferencia entre la pestaña UDP y la pestaña TCP suele decidir la familia por sí sola.

I/O Graphs (Statistics → I/O Graphs)

Tráfico a lo largo del tiempo. Ajusta el eje Y a packets/sec (los ataques que importan suelen ser anomalías de tasa de paquetes, y las gráficas en bytes infravaloran las floods de paquetes pequeños), y añade líneas de gráfica con filtros para comparar clases de tráfico. Por ejemplo, una línea para tcp.flags.syn == 1 && tcp.flags.ack == 0 frente a otra para todo el tráfico muestra exactamente cuándo empezó un SYN flood y si es constante o a pulsos. Las ráfagas de ataque de segundos a unos pocos minutos son la norma, no la excepción; la mayoría de los ataques reales son cortos.

Paso 4: confirmar el vector con filtros de visualización

Ahora las firmas específicas. Escríbelas en la barra de filtro de visualización de Wireshark sobre tu captura.

SYN flood

tcp.flags.syn == 1 && tcp.flags.ack == 0

Eso es cada SYN inicial. En tráfico legítimo, los SYN son una fracción mínima del total y a cada uno le sigue un handshake que se completa. En un SYN flood, este filtro coincide con una parte enorme de la captura, y las continuaciones nunca llegan. Verificaciones cruzadas:

• Compara los recuentos con tcp.flags.syn == 1 && tcp.flags.ack == 1 (los SYN-ACK del servidor) y con el tráfico de conexiones establecidas. Miles de SYN, ninguna conversación completada → flood confirmada.
• ¿Fuentes suplantadas o reales? Observa ip.ttl a lo largo de la flood: los clientes reales de una botnet llegan con la dispersión natural de TTL que cabría esperar de rutas de red diversas; las herramientas de spoofing ingenuas suelen emitir TTL uniformes o con un patrón demasiado regular, tamaños de ventana idénticos y números de secuencia sin variedad orgánica. Las fuentes que nunca responden a tu SYN-ACK son coherentes con spoofing; las fuentes que completan el handshake y luego atacan son máquinas reales.

Amplificación / reflexión UDP

udp.srcport in {53, 123, 389, 11211, 1900, 19}

El tráfico de ataque reflejado llega desde el puerto conocido del servicio abusado, DNS (53), NTP (123), CLDAP (389), memcached (11211), SSDP (1900), CharGEN (19), porque realmente es ese servicio, respondiendo a consultas que el atacante envió en tu nombre. Señales que lo corroboran:

• Paquetes grandes, a menudo fragmentados: la amplificación implica que las respuestas son grandes; revisa Statistics → Packet Lengths en busca de una distribución concentrada en el extremo alto, y ip.flags.mf == 1 || ip.frag_offset > 0 para los fragmentos.
• Para DNS en concreto: tráfico dns.flags.response == 1 para el que no tienes consultas que lo justifiquen, y tipos de consulta propicios para la amplificación visibles en las respuestas (dns.qry.type == 255, la clásica consulta ANY).
• Las "fuentes" aquí son reflectores: víctimas ellas mismas, no atacantes. Bloquearlas una por una es un juego del gato y el ratón; el resultado accionable es "descartar el puerto origen UDP N hacia mi dirección, en upstream", precisamente el tipo de regla que la mitigación de tu proveedor (o un firewall de borde de red) aplica bien.

ICMP flood

Protocol Hierarchy hace evidente este por sí solo; confírmalo con icmp.type == 8 (echo requests) a tasas absurdas desde muchas fuentes.

Floods HTTP(S), y la salvedad del cifrado

Para HTTP en texto plano puedes profundizar en Wireshark: tasas de http.request por fuente en Conversations, URI idénticas y repetidas (http.request.uri contains "/search"), User-Agents arcaicos o ausentes. Pero la mayoría de las floods hoy en día apuntan a HTTPS, y una captura de paquetes no puede ver dentro de TLS sin las claves de sesión del servidor. Sé honesto sobre ese límite: a partir de la captura aún puedes establecer que se trata de un ataque de capa de aplicación. Una tormenta de conexiones TLS de corta duración se ve como tls.handshake.type == 1 (ClientHellos) a tasas anómalas por fuente, pero qué están pidiendo se ve en los access logs de tu servidor web, no en el pcap. Analiza las floods L7 con ambos: la captura demuestra el patrón de conexión, los logs muestran las URI y las cabeceras.

Paso 5: de los hallazgos a la mitigación

El sentido del análisis es la frase que te permite escribir. Compara:

"Nos están haciendo DDoS, ayuda por favor."

"Desde las 14:02 UTC estamos recibiendo ~3.5 M pps de reflexión NTP (puerto origen UDP 123, paquetes de ~1,200 bytes, muchos fragmentos) en 203.0.113.10. ¿Podéis descartar UDP src 123 hacia esa dirección en el borde?"

La segunda consigue que se aplique un filtro upstream preciso en minutos. Encauza tus hallazgos según lo que hayas aprendido:

• Volumétrico (amplificación, floods UDP): siempre en upstream; los paquetes ya cruzaron tu uplink, así que las reglas en el host ya no ayudan. Entrega la firma del vector a tu proveedor o aplícala en un firewall de borde self-service si dispones de uno.
• SYN floods: confirma que las SYN cookies están activas (sysctl net.ipv4.tcp_syncookies), limita la tasa de conexiones nuevas, y pasa la firma a upstream si el volumen supera lo que el host absorbe con comodidad.
• Floods L7: tu reverse proxy y tu WAF: límites de peticiones por fuente, caching, challenges para el patrón responsable identificado en los access logs.

En el host, nftables expresa las reglas de emergencia de forma compacta (consulta nuestra base de reglas de firewall e iptables vs nftables para los fundamentos):

# emergency: drop NTP-reflection traffic on the host (better: at the edge)
nft add rule inet filter input udp sport 123 drop

# throttle new connections per source during a connection flood
nft add rule inet filter input tcp dport 443 ct state new limit rate over 50/second drop

Y después, guarda la captura, los filtros que identificaron el vector y la regla que lo detuvo. Los ataques se repiten; el segundo incidente debería llevarte cinco minutos.

Practicar antes de necesitarlo

En mitad de un incidente es el momento equivocado para aprender este flujo de trabajo. Los datasets públicos te permiten ensayar legalmente:

• StopDDoS packet captures: pcaps de DDoS anonimizados, reales y de laboratorio, que cubren exactamente los vectores anteriores: reflexión DNS/NTP/CLDAP/memcached, floods SYN y UDP. El mejor conjunto de práctica para este artículo; abre uno y ejecuta la secuencia de triaje.
• CIC-DDoS2019: un dataset académico (University of New Brunswick) con pcaps en bruto de ~13 tipos de ataque etiquetados mezclados con tráfico benigno; más pesado, apto para un estudio más profundo.
• Las capturas de ejemplo de la wiki de Wireshark incluyen algo de tráfico de ataque histórico (ataques de fragmentación, tráfico de gusanos), más antiguo, pero adecuado para practicar el flujo de Statistics.

Preguntas frecuentes

¿Puede Wireshark detener un ataque DDoS?

No. Wireshark es un microscopio, no un escudo. Su función en un incidente es el diagnóstico: decirte a qué vector te enfrentas para que la mitigación real (scrubbing en upstream, filtros de borde, rate limits, reglas WAF) pueda apuntarse correctamente. La detención ocurre en la capa de mitigación de tu proveedor y en tu firewall, como se explica en nuestra guía de protección DDoS.

¿Debo usar tcpdump o Wireshark?

Ambos, en secuencia: tcpdump (o dumpcap) captura en el servidor (es ligero, headless y seguro de ejecutar en una máquina bajo presión) y Wireshark analiza el archivo resultante en tu estación de trabajo, donde brillan sus dissectors y herramientas estadísticas. Ejecutar la GUI de Wireshark en un servidor de producción bajo ataque es la única respuesta claramente equivocada: consume exactamente la CPU y la memoria que el ataque intenta agotar.

¿Cuánto debe durar la captura?

Más corta de lo que sugiere la intuición: treinta segundos de tráfico de ataque suelen ser más que suficientes para identificar un vector, porque las floods son estadísticamente monótonas: millones de paquetes casi idénticos. Acota cada captura (-c para el recuento, o -C/-W para buffers circulares) para que no pueda llenar el disco, y prefiere varias muestras cortas antes que un único archivo gigantesco; un pcap de varios gigabytes sobre todo te da una sesión de Wireshark lenta, no más información.

El ataque es sobre HTTPS. ¿Capturar no sirve de nada?

No es inútil, solo limitado. La captura sigue revelando la historia a nivel de conexión: distribución de fuentes, tasas de conexión, floods de handshake TLS, timing de paquetes, suficiente para confirmar una "flood de capa de aplicación" y perfilar los clientes. Lo que no puede mostrar son las peticiones en texto plano dentro de TLS, así que combina el pcap con los access logs de tu servidor web, que registran la línea de petición descifrada, las cabeceras y el timing de cada petición que el servidor realmente procesó.

Desplegando en Serverside

El mejor momento para este análisis es mientras tu servidor sigue siendo accesible, que es justo para lo que sirve la mitigación permanente. Cada servidor dedicado de nuestra red está detrás de mitigación DDoS permanente en el ASN 55285: los ataques se limpian automáticamente en el borde, y el firewall de borde self-service te permite aplicar exactamente el tipo de reglas de descarte específicas de vector que esta guía te enseña a derivar, en upstream de tu puerto, que es donde hay que detener el tráfico volumétrico. Aprovisionamiento en menos de un minuto, y acceso a consola KVM para cuando quieras trabajar en una máquina fuera de banda.

Completa la serie con Los ataques DDoS explicados: formas y protección, reglas de firewall por defecto sensatas e iptables vs nftables.