Comment capturer et analyser une attaque DDoS avec Wireshark (et tcpdump)

D'abord la réponse : le workflow

Analyser une attaque contre votre propre infrastructure est un travail en cinq étapes, et chaque étape existe pour répondre à une question : de quel vecteur d'attaque s'agit-il, afin que la bonne mitigation puisse être appliquée. (Pour savoir ce que sont les vecteurs et comment chacun est stoppé, consultez notre article complémentaire, Les attaques DDoS expliquées.)

1. Capturez un échantillon avec tcpdump : longueur de snapshot réduite, taille bornée, jamais l'interface graphique de Wireshark sur la machine victime.
2. Récupérez la capture depuis le serveur et ouvrez-la dans Wireshark sur votre poste de travail.
3. Triez avec les menus Statistics : Protocol Hierarchy vous indique quel est ce trafic, Conversations vous indique qui est impliqué, I/O Graphs vous indique quand et avec quelle intensité.
4. Confirmez le vecteur avec des filtres d'affichage : chaque famille d'attaque a une signature reconnaissable.
5. Transformez les constats en action : une règle de pare-feu là où le filtrage sur l'hôte aide, et un rapport précis et exploitable à votre fournisseur là où ce n'est pas le cas.

Une précision de périmètre avant les outils : ce guide relève de la forensique défensive, l'analyse d'attaques touchant une infrastructure que vous exploitez, à l'aide de captures que vous êtes en droit de réaliser. Si vous voulez vous entraîner avant d'en avoir besoin (bonne idée : en pleine attaque est un mauvais moment pour apprendre Wireshark), des captures d'attaques publiques permettent de s'entraîner, listées à la fin.

Étape 1 : capturer sous charge sans aggraver la situation

Le réflexe d'ouvrir Wireshark sur le serveur attaqué est doublement mauvais : l'interface graphique qui dissèque des millions de paquets par seconde achève l'épuisement de ressources que l'attaquant a entamé, et une capture naïve écrit des paquets complets sur le disque au débit de l'attaque, des gigaoctets par minute. Le bon outil sur la victime est tcpdump (ou dumpcap, le moteur de capture de Wireshark, s'il est installé), configuré pour rester léger :

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

Pourquoi chaque option se justifie :

• -s 128 plafonne le nombre d'octets capturés par paquet. Pour identifier un vecteur, vous avez besoin des en-têtes, pas des payloads ; les en-têtes Ethernet + IP + TCP/UDP plus une petite marge tiennent largement dans 128 octets. Cela pèse plus qu'il n'y paraît : la longueur de snapshot par défaut du tcpdump moderne est de 262,144 octets, c'est donc un snaplen explicitement réduit qui garde le fichier petit et le coût par paquet bas.
• -n désactive la résolution de noms. Résoudre des milliers d'IP attaquantes via DNS (potentiellement pendant que votre lien est saturé) revient à se saboter soi-même.
• -c 500000 s'arrête après un demi-million de paquets, quoi qu'il arrive. Une capture bornée ne peut pas remplir votre disque.
• -w file écrit les paquets bruts pour une analyse ultérieure au lieu de les décoder vers le terminal (le décodage coûte du CPU ; le terminal coûte la bande passante de votre session SSH).

Si l'attaque persiste et que vous voulez une visibilité continue plutôt qu'un seul échantillon, utilisez un buffer circulaire pour que l'usage disque reste constant, quelle que soit la durée :

# 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

Deux remarques pratiques. D'abord, ajoutez un filtre de capture pour réduire le bruit quand vous connaissez déjà la cible, par exemple tcpdump ... dst host 203.0.113.10 (remplacez par votre propre adresse ; les exemples de ce guide utilisent des plages de documentation). Ensuite, à des débits de paquets extrêmes, même tcpdump perd des paquets ; il indique combien à la sortie. Pour l'identification du vecteur, ce n'est pas un problème : un échantillon suffit, et la vérité statistique survit aux pertes. (Si vous avez besoin d'une capture complète à haut débit, c'est un territoire spécialisé : dumpcap avec un grand buffer, ou des technologies d'échantillonnage comme sFlow au niveau du switch, mais ce n'est pas requis pour le triage.)

Étape 2 : sortir la capture de la machine

L'analyse se déroule sur votre poste de travail, pas sur le serveur blessé :

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

Ouvrez-la dans Wireshark ; la version stable actuelle est la série 4.6. Si le fichier est énorme malgré vos limites, les propres recommandations de performance de Wireshark s'appliquent : au-delà de quelques centaines de mégaoctets, les fichiers deviennent lents, découpez donc d'abord un morceau (editcap -c 1000000 big.pcap slice.pcap découpe par nombre de paquets ; editcap est fourni avec Wireshark).

Étape 3 : triage, trois fenêtres Statistics

Ne commencez pas en faisant défiler les paquets ; commencez par les vues agrégées. Trois fenêtres, dans l'ordre :

Protocol Hierarchy (Statistics → Protocol Hierarchy)

Un coup d'œil répond à « quel est ce trafic ? » : l'arborescence des protocoles avec les pourcentages en paquets et en octets. La capture d'un serveur web sain est dominée par TCP/TLS. Une capture d'attaque est en général grotesquement déséquilibrée : 95 % d'UDP alors que vous n'en servez pas, ou un mur de paquets TCP nus sans protocole de couche applicative par-dessus (la signature d'une flood de paquets de handshake qui ne deviennent jamais des connexions).

Conversations (Statistics → Conversations)

Le tableau qui-parle-à-qui, triable par paquets, octets et durée. Ce qu'il faut en lire :

• Dispersion des sources. Dix mille adresses sources envoyant chacune quelques centaines de paquets vers une seule destination, c'est une flood distribuée (ou du spoofing ; l'étape 4 fait la distinction). Une poignée de sources envoyant des millions de paquets, c'est quelque chose que vous pouvez null-router dès aujourd'hui.
• Triez par paquets, pas par octets, pour les attaques en débit de paquets : un SYN flood est énorme en nombre de paquets et modeste en octets.
• La répartition entre l'onglet UDP et l'onglet TCP détermine souvent la famille à elle seule.

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

Le trafic dans le temps. Réglez l'axe Y sur packets/sec (les attaques qui comptent sont généralement des anomalies de débit de paquets, et les graphiques en octets sous-estiment les floods à petits paquets), et ajoutez des courbes avec des filtres pour comparer des classes de trafic. Par exemple, une courbe pour tcp.flags.syn == 1 && tcp.flags.ack == 0 face à une courbe pour tout le trafic montre exactement quand un SYN flood a commencé et s'il est constant ou pulsé. Des rafales d'attaque de quelques secondes à quelques minutes sont la norme, pas l'exception ; la plupart des attaques réelles sont courtes.

Étape 4 : confirmer le vecteur avec des filtres d'affichage

Voici maintenant les signatures spécifiques. Saisissez-les dans la barre de filtre d'affichage de Wireshark sur votre capture.

SYN flood

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

C'est chaque SYN initial. Dans un trafic légitime, les SYN représentent une infime part du total et chacun est suivi d'un handshake qui se termine. Dans un SYN flood, ce filtre correspond à une part énorme de la capture, et les suites n'arrivent jamais. Contre-vérifications :

• Comparez les comptages avec tcp.flags.syn == 1 && tcp.flags.ack == 1 (les SYN-ACK du serveur) et avec le trafic des connexions établies. Des milliers de SYN, aucune conversation aboutie → flood confirmée.
• Sources usurpées ou réelles ? Observez ip.ttl sur toute la flood : les vrais clients de botnet arrivent avec la dispersion naturelle de TTL que l'on attendrait de chemins réseau variés ; les outils de spoofing naïfs émettent souvent des TTL uniformes ou selon un motif trop régulier, des window sizes identiques et des numéros de séquence sans variété organique. Les sources qui ne répondent jamais à votre SYN-ACK sont cohérentes avec du spoofing ; les sources qui terminent le handshake puis attaquent sont des machines réelles.

Amplification / réflexion UDP

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

Le trafic d'attaque réfléchi arrive depuis le port bien connu du service détourné, DNS (53), NTP (123), CLDAP (389), memcached (11211), SSDP (1900), CharGEN (19), parce que c'est véritablement ce service, répondant à des requêtes que l'attaquant a envoyées en votre nom. Signes corroborants :

• Des paquets volumineux, souvent fragmentés : l'amplification signifie que les réponses sont grosses ; vérifiez Statistics → Packet Lengths pour repérer une distribution concentrée en haut de l'échelle, et ip.flags.mf == 1 || ip.frag_offset > 0 pour les fragments.
• Pour DNS en particulier : du trafic dns.flags.response == 1 sans requête correspondante chez vous, et des types de requête propices à l'amplification visibles dans les réponses (dns.qry.type == 255, la classique requête ANY).
• Les « sources » ici sont des réflecteurs : des victimes elles-mêmes, pas des attaquants. Les bloquer une par une, c'est jouer à la taupe ; l'action exploitable est « dropper le port source UDP N vers mon adresse, en amont », exactement le type de règle que la mitigation de votre fournisseur (ou un pare-feu en périphérie de réseau) applique bien.

ICMP flood

Protocol Hierarchy rend celle-ci évidente d'elle-même ; confirmez avec icmp.type == 8 (echo requests) à des débits absurdes venant de nombreuses sources.

Floods HTTP(S), et la réserve liée au chiffrement

Pour du HTTP en clair, vous pouvez creuser en profondeur dans Wireshark : les débits de http.request par source dans Conversations, des URI identiques répétées (http.request.uri contains "/search"), des User-Agents archaïques ou absents. Mais la plupart des floods ciblent aujourd'hui HTTPS, et une capture de paquets ne peut pas voir à l'intérieur de TLS sans les clés de session du serveur. Soyez honnête sur cette limite : la capture permet quand même d'établir que c'est une attaque de couche applicative. Une tempête de connexions TLS de courte durée se voit comme tls.handshake.type == 1 (ClientHellos) à des débits anormaux par source, mais ce qui est demandé provient des logs d'accès de votre serveur web, pas du pcap. Analysez les floods L7 avec les deux : la capture prouve le schéma de connexion, les logs montrent les URI et les en-têtes.

Étape 5 : des constats à la mitigation

Le but de l'analyse est la phrase qu'elle vous permet d'écrire. Comparez :

« On subit un DDoS, aidez-nous. »

« Depuis 14 h 02 UTC, nous recevons ~3.5 M pps de réflexion NTP (port source UDP 123, paquets d'environ 1,200 octets, nombreux fragments) sur 203.0.113.10. Pouvez-vous dropper UDP src 123 vers cette adresse en périphérie ? »

La seconde permet d'obtenir un filtre amont précis en quelques minutes. Orientez vos constats selon ce que vous avez appris :

• Volumétrique (amplification, floods UDP) : toujours en amont ; les paquets ont déjà traversé votre uplink, donc les règles sur l'hôte ne peuvent plus aider. Transmettez la signature du vecteur à votre fournisseur ou appliquez-la dans un pare-feu de périphérie en self-service si vous en avez un.
• SYN floods : vérifiez que les SYN cookies sont actifs (sysctl net.ipv4.tcp_syncookies), limitez le débit des nouvelles connexions, et transmettez la signature en amont si le volume dépasse ce que l'hôte absorbe confortablement.
• Floods L7 : votre reverse proxy et votre WAF : limites de requêtes par source, mise en cache, challenges pour le motif fautif repéré dans les logs d'accès.

Sur l'hôte, nftables exprime les règles d'urgence de façon compacte (voir notre base de règles de pare-feu et iptables vs nftables pour les fondamentaux) :

# 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

Ensuite, conservez la capture, les filtres qui ont identifié le vecteur et la règle qui l'a stoppé. Les attaques se reproduisent ; le deuxième incident devrait prendre cinq minutes.

S'entraîner avant d'en avoir besoin

En plein incident est le mauvais moment pour apprendre ce workflow. Des jeux de données publics permettent de s'entraîner légalement :

• StopDDoS packet captures : des pcaps DDoS anonymisés, réels et de laboratoire, couvrant exactement les vecteurs ci-dessus : réflexion DNS/NTP/CLDAP/memcached, floods SYN et UDP. Le meilleur jeu d'entraînement pour cet article ; ouvrez-en un et exécutez la séquence de triage.
• CIC-DDoS2019 : un jeu de données académique (University of New Brunswick) avec des pcaps bruts d'environ 13 types d'attaques étiquetés mêlés à du trafic bénin ; plus lourd, adapté à une étude plus approfondie.
• Les captures d'exemple du wiki Wireshark incluent du trafic d'attaque historique (attaques par fragmentation, trafic de vers), plus ancien, mais correct pour s'entraîner au workflow Statistics.

Questions fréquentes

Wireshark peut-il stopper une attaque DDoS ?

Non. Wireshark est un microscope, pas un bouclier. Son rôle dans un incident est le diagnostic : vous indiquer à quel vecteur vous avez affaire pour que la mitigation réelle (scrubbing en amont, filtres en périphérie, rate limits, règles WAF) puisse être appliquée correctement. L'arrêt se produit dans la couche de mitigation de votre fournisseur et dans votre pare-feu, comme le montre notre guide de protection DDoS.

Faut-il utiliser tcpdump ou Wireshark ?

Les deux, dans cet ordre : tcpdump (ou dumpcap) capture sur le serveur (c'est léger, headless, et sûr à faire tourner sur une machine sous pression) et Wireshark analyse le fichier obtenu sur votre poste de travail, là où ses dissecteurs et ses outils statistiques excellent. Faire tourner l'interface graphique de Wireshark sur un serveur de production attaqué est la seule réponse clairement mauvaise : elle consomme exactement le CPU et la mémoire que l'attaque cherche à épuiser.

Combien de temps doit durer la capture ?

Plus courte que ce que l'intuition suggère : trente secondes de trafic d'attaque suffisent normalement largement à identifier un vecteur, parce que les floods sont statistiquement monotones : des millions de paquets quasi identiques. Bornez chaque capture (-c pour le nombre, ou -C/-W pour des buffers circulaires) afin qu'elle ne puisse pas remplir le disque, et préférez plusieurs échantillons courts à un seul fichier gigantesque ; un pcap de plusieurs gigaoctets vous procure surtout une session Wireshark poussive, pas davantage d'analyse.

L'attaque passe par HTTPS. La capture est-elle inutile ?

Pas inutile, juste limitée. La capture révèle quand même l'histoire au niveau connexion : distribution des sources, débits de connexion, floods de handshake TLS, timing des paquets, de quoi confirmer une « flood de couche applicative » et profiler les clients. Ce qu'elle ne peut pas montrer, ce sont les requêtes en clair à l'intérieur de TLS ; associez donc le pcap aux logs d'accès de votre serveur web, qui enregistrent la ligne de requête déchiffrée, les en-têtes et le timing de chaque requête réellement traitée par le serveur.

Déploiement chez Serverside

Le meilleur moment pour cette analyse est celui où votre serveur reste joignable, et c'est précisément à cela que sert la mitigation permanente. Chaque serveur dédié de notre réseau se trouve derrière une mitigation DDoS permanente sur l'ASN 55285 : les attaques sont nettoyées automatiquement en périphérie, et le pare-feu de périphérie en self-service vous permet d'appliquer exactement le type de règles de drop spécifiques à un vecteur que ce guide vous apprend à établir, en amont de votre port, là où le trafic volumétrique doit être stoppé. Provisioning en moins d'une minute, et accès console KVM pour les fois où vous voulez travailler sur une machine hors bande.

Complétez la série avec Les attaques DDoS expliquées : formes et protection, des règles de pare-feu par défaut sensées et iptables vs nftables.