Post-mortem : l'attaque DDoS 420 Gbps du 11 mars 2026
Décryptage complet de l'attaque DDoS volumétrique qu'on a subie début mars. Vecteur, mitigation, timeline, leçons pour l'infra. Transparents même quand ça tape fort.
Le 11 mars 2026 entre 19h34 et 20h12 heure de Paris, notre infrastructure a encaissé une attaque DDoS volumétrique de 420 Gbps de peak. Aucun service n'a été impacté côté client — mais on veut être transparents sur ce qui s'est passé, comment on l'a géré, et ce qu'on a appris.
Ce post-mortem fait partie de notre engagement de transparence : à chaque incident majeur, on publie un rapport complet. Pas de minimisation, pas de langue de bois.
Résumé exécutif
- Vecteur : amplification DNS + UDP flood combinés
- Peak : 420 Gbps sur l'uplink principal (2×10 Gbps LACP)
- Durée : 38 minutes
- Impact client : aucun — mitigation Arbor transparente
- Cible : un serveur FiveM roleplay hébergé chez nous (probablement guerre de communautés)
- Actions : monitoring renforcé, ajout d'une règle de filtrage spécifique amplification DNS
Timeline
19h34:12 — Premier pic détecté par Arbor Sightline. Seuil à 10 Gbps dépassé, alerte générée.
19h34:47 — Mitigation automatique activée. Les routes BGP vers la cible sont redirigées vers les scrubbing centers Arbor.
19h35 — Astreinte notifiée via PagerDuty. Ops de garde (moi) connecté au NOC en 90 secondes.
19h38 — Le trafic propre passe, le malicieux est nettoyé en amont. On observe les métriques de mitigation : taux de trafic nettoyé > 99.8%.
19h52 — Peak maximum : 420 Gbps mesurés côté upstream. 416 Gbps absorbés par le scrubbing, 4 Gbps restants arrivent côté XProvider mais sont filtrés par nos règles L4 avant de toucher le serveur cible.
19h56 — Tentative de shift de vecteur : l'attaquant passe d'amplification DNS pure à un mix UDP flood + TCP SYN flood. Arbor ajuste les profils de mitigation automatiquement en ~30 secondes.
20h11 — Le trafic retombe sous les seuils normaux. Attaque terminée.
20h12 — Mitigation désactivée, traffic direct restauré. Aucun paquet perdu côté client pendant toute la fenêtre.
Analyse du vecteur
L'attaque utilisait deux vecteurs combinés :
1. Amplification DNS (~70% du volume)
Des requêtes DNS ANY spoofées vers des résolveurs récursifs ouverts, avec notre IP cible en source. La réponse (plusieurs Ko) est renvoyée à la cible, multipliant la charge. Classique mais toujours efficace quand il y a assez de résolveurs mal configurés sur le net.
2. UDP flood sur port jeu (~30% du volume)
Flood de paquets UDP forgés vers le port du serveur FiveM cible (port 30120 par défaut). Ce vecteur est plus insidieux car le trafic est dans le profil du serveur — c'est du UDP sur le bon port — et nécessite une analyse L7 pour distinguer le légitime du malveillant.
Pourquoi ça n'a pas fait tomber le service
Notre mitigation repose sur 3 couches empilées :
Couche 1 — BGP blackhole + scrubbing Arbor (externe)
Dès qu'un seuil est franchi, le trafic est détourné vers les scrubbing centers Arbor en amont de nos DCs. Le trafic sain est réinjecté, le malicieux est dropped. Capacité d'absorption : plusieurs Tbps selon notre contrat.
Couche 2 — Filtrage L4 sur nos edge routers (Cisco Nexus)
Règles eBPF custom qui filtrent les patterns UDP malformés, les paquets trop petits pour être légitimes, les rate-limits par source IP. Absorbe les fuites de la couche 1.
Couche 3 — Gaming-aware L7 (nos propres serveurs)
Validation applicative par protocole. Pour FiveM : vérification du handshake, des séquences de packets, du timing. Les paquets forgés sont détectés et droppés avant impact CPU.
Pendant l'attaque, la couche 1 a absorbé 99.1% du volume, la couche 2 a nettoyé 0.8%, la couche 3 a traité le dernier 0.1%. Le serveur cible n'a jamais vu plus de 40 Mbps de trafic malveillant parvenir à ses ports applicatifs.
Ce qui aurait pu se passer côté concurrence
Pour contexte : une attaque de 420 Gbps dépasse largement la capacité de nombreux hébergeurs low-cost. Un hébergeur sans Arbor pro ou équivalent aurait :
- Vu le serveur cible tomber en 5-10 secondes
- Soit proposé au client de prendre une offre « anti-DDoS premium » à 30-50 €/mois pour les prochaines fois
- Soit, pire, terminé son contrat pour « usage abusif »
Chez nous, la protection est incluse, et on ne facture pas post-attaque.
Leçons apprises
1. Les profils de mitigation auto-adaptatifs valent leur prix
Le shift de vecteur à 19h56 aurait traditionnellement nécessité un ops qui ajuste les règles à la main. Le profil Arbor a ajusté en 30 secondes parce qu'il apprend en continu. On va pousser plus de monitors dans cette logique.
2. Notre visibilité L7 FiveM est bonne mais améliorable
On a identifié le vecteur UDP spécifique FiveM en ~4 min. C'est rapide mais on peut descendre à 60 secondes en enrichissant nos signatures. Action planifiée pour avril.
3. La communication aux clients a été trop tardive
Bien que l'attaque n'ait pas impacté le service, on aurait dû poster un warning sur #status Discord à 19h35, pas à 20h14 (post-incident). Engagement pris : post automatique dès qu'une mitigation DDoS > 100 Gbps est déclenchée.
Actions correctives
- [x] Règle de filtrage amplification DNS renforcée (déployée le 12/03)
- [x] Seuil d'alerte ops baissé de 10 à 5 Gbps (déployé le 13/03)
- [x] Post #status automatique pour mitigations > 100 Gbps (déployé le 20/03)
- [ ] Enrichissement signatures L7 FiveM (prévu avril 2026)
- [ ] Drill DDoS trimestriel avec simulation blue-team (Q2 2026)
Conclusion
420 Gbps, c'est une attaque sérieuse mais pas exceptionnelle — les équipes d'Arbor nous disent qu'ils voient du 1 Tbps+ régulièrement en 2026. Notre infrastructure est dimensionnée pour encaisser ce genre de volume sans que les clients ne s'en aperçoivent, et cet incident le confirme.
Pour les curieux techniques, on publie chaque mois un résumé des métriques DDoS mitigées sur notre compte Twitter. Questions ? Discord.