Le résumé, d'abord
Dimanche 21 octobre 2024, à 02 h 17 UTC, notre supervision a déclenché une alerte sur le point de présence de Rotterdam : une IP unique — celle d'un VPS client hébergeant un serveur de jeu et son API — recevait un flux anormal. En moins de trois minutes, le débit entrant sur cette IP a dépassé 100 Gbps. Le pic, atteint à 04 h 40, s'est stabilisé à 800 Gbps et 412 millions de paquets par seconde, issus de plus de 41 000 IP sources réparties sur une cinquantaine de pays.
Le VPS ciblé est resté joignable pendant toute la durée de l'attaque. Les 3 400 autres VPS actifs sur le même POP n'ont subi aucune dégradation mesurable — ni sur le reste de notre réseau. Ce résultat n'est pas de la chance : c'est le produit direct des décisions décrites dans notre article sur AS216455, publié en avril, et d'un budget mitigation que nous assumons ouvertement. Le détail, ci-dessous, est celui que nous aimerions lire chez nos propres fournisseurs.
« Un post-mortem qui dit "tout s'est bien passé" sans montrer les chiffres n'est pas un post-mortem. C'est une publicité. » — note d'intro du rapport interne
Chronologie de la nuit
Tous les horaires sont en UTC et proviennent de nos systèmes (horloge NTP stratum 1). La fenêtre totale : 02 h 17 → 07 h 12.
| Heure | Événement | Détail |
|---|---|---|
| 02 h 17 | Détection automatique | Alerte seuil : 40 Gbps entrants sur une IP unique. Baseline de 28 jours dépassée à +2 300 %. |
| 02 h 21 | Bascule en scrubbing | Annonce BGP de la /32 ciblée vers notre centre de scrubbing n°1. Le flux sale est redirigé et filtré ; le trafic légitime en ressort nettoyé. |
| 02 h 26 | Signalement aux transits | Communities de blackhole et de scrubbing appliquées côté transits ; demande de filtrage UDP sur les ports d'amplification identifiés (NTP, CLDAP, chargen). |
| 02 h 31 | Anycast dilution | L'IP ciblée est déjà annoncée par nos cinq POP : le volume se répartit géographiquement. Pic local à Rotterdam réduit de 38 %. |
| 03 h 05 | Pivot de l'attaquant | Changement de vecteur : flood SYN + ACK, puis HTTP GET sur l'API du jeu. Activation du SYN proxy et des règles L7 dynamiques (challenge JS sur endpoints non-API). |
| 04 h 40 | Pic : 800 Gbps | Apogée mesurée sur le scrubbing (agrégat des transits). La capacité de scrubbing totale reste à 62 % — jamais saturée. |
| 06 h 12 | Décroissance | Le flux retombe sous 20 Gbps. Les règles temporaires restent actives en mode observation. |
| 07 h 12 | Fin d'incident | Retour à la baseline. Ticket automatique envoyé au client avec le rapport complet et trois recommandations de durcissement. |
La pile de mitigation, couche par couche
Notre protection anti-DDoS n'est pas un produit unique acheté en carton, mais quatre couches indépendantes qui se recouvrent :
1. Scrubbing à capacité fixe
Deux centres de scrubbing sous contrat, activés par annonce BGP d'une /32 plus précise que notre annonce globale (le « prefix hijack » bienveillant, standard de l'industrie). Tout ce qui dépasse le profil normal d'une IP est aspiré, nettoyé (suppression des paquets amplifiés, des SYN non conformes, des fragments invalides) et renvoyé en tunnel. C'est cette couche qui a absorbé l'essentiel des 800 Gbps.
2. Anycast : répartir pour ne jamais souffrir
Chaque IP de service est annoncée simultanément depuis nos cinq points de présence. Une attaque massive qui frappe Rotterdam frappe aussi Bucarest, Reykjavik, Zurich et Moscou : le volume se dilue géographiquement — et l'attaquant doit payer un débit qu'il ne peut plus concentrer. Cette couche a réduit le pic local de 38 % sans aucune intervention humaine.
3. Filtrage statique en périphérie
ACL d'entrée sur chaque transit : blocage des protocoles d'amplification connus (SSDP, chargen, NTP monlist, CLDAP) qui ne servent aucun usage légitime chez un hébergeur VPS. Règle n°1 du métier : si un protocole n'a aucune raison d'exister sur votre réseau, bloquez-le avant même la première attaque.
4. Couche 7 : la partie qui demande encore des humains
Soyons honnêtes : le scrubbing gère parfaitement les volumes bruts, mais un HTTP GET bien formé qui imite un joueur réel ne se distingue pas par sa forme. La couche 7 repose sur des règles dynamiques (challenges JavaScript sur les pages, rate-limit par session sur l'API, filtrage géographique ciblé) que notre supervision propose et qu'un opérateur valide. Ce soir-là, la validation a pris 90 secondes. C'est 90 secondes de trop à notre goût — voir les leçons.
L'impact réel, mesuré — pas estimé
Trois chiffres résument l'incident pour nos clients :
- Le VPS ciblé : dégradation perceptible de 02 h 31 à 02 h 54 (latence moyenne +180 ms sur le jeu, aucune coupure). Le service n'a jamais été indisponible ; les joueurs ont déploré un lag, rien de plus.
- Les autres clients du même POP : une gêne de 2 minutes à 04 h 41 (perte de paquets mesurée 0,4 % sur le segment partagé lors du pic absolu), automatiquement compensée par la dilution anycast. Aucun ticket reçu, aucune alerte client déclenchée hors du VPS ciblé.
- Le trimestre : notre engagement est de 99,95 % de disponibilité par VPS. Le T4 2024 en cours se situe à 99,97 % sur le POP de Rotterdam malgré cette nuit — l'attaque n'a pas compromis un seul SLA.
Pourquoi l'attaquant visait ce VPS ? Nous ne le saurons jamais, et nous ne posons pas la question à nos clients : le motif d'une attaque ne conditionne jamais notre défense. Notre AUP s'applique en revanche strictement : si une enquête formelle établissait que le service ciblé enfreint nos règles (phishing, malware, spam), nous traiterions l'abus dans l'heure, attaque ou pas. Résilience ne veut pas dire impunité — et cette nuit-là, rien de tel n'a été allégué ni constaté.
Cinq leçons que nous appliquons déjà
- Validation L7 automatisée. Les règles proposées par la supervision sont désormais appliquées automatiquement sous 30 Gbps confirmés pendant 60 secondes, avec annulation automatique à la décroissance. Temps cible : zéro seconde d'attente humaine pour les vecteurs connus.
- Capacité de scrubbing portée à 1,2 Tbps. Nous restons à 62 % au pic de 800 Gbps ; la marge se paie, la saturation se paie plus cher. Contrat renégocié, montée en capacité effective début novembre.
- Runbook jeu/API publié. Challenges JS sur le front, rate-limit token-bucket sur l'API, whitelist des plages des fournisseurs de stats : les trois règles qui ont marché sont documentées et envoyées à tout client de serveur de jeu.
- Communication d'incident en 15 minutes. Même quand tout se passe bien : la page statut affiche désormais tout dépassement > 50 Gbps dès sa confirmation, sans attendre la fin.
- Exercice trimestriel. Nous rejouons cette attaque (amplifications + pivot L7) sur un VPS de test chaque trimestre, la nuit, avec mesures. Le rapport Q1 2025 sera publié ici.