Résumé
Le 14 octobre 2020, entre 02 h 41 et 02 h 52 UTC, chaque instance à AMS-01 était injoignable. Une attaque de type volumétrique visant une seule adresse client a atteint un pic de 340 Gbit/s et a saturé les uplinks du site. Nous l'avons résolue en demandant à l'amont de rejeter tout le trafic vers l'adresse cible, ce qui a rétabli le site et a laissé ce client hors ligne pendant cinquante minutes de plus. Aucune donnée n'a été perdue et aucune instance n'a été endommagée. Le site n'avait aucune capacité de scrubbing à l'époque, et il s'agissait d'une décision d'achat plutôt que d'un accident.
Chronologie
Toutes les heures sont en UTC, le 14 octobre 2020.
| Heure | Événement |
|---|---|
| 02:41:04 | Le trafic vers une seule adresse client passe d'environ 200 Mbit/s à 90 Gbit/s en moins de vingt secondes. |
| 02:41:30 | Les deux uplinks du site saturent. La perte de paquets devient totale sur tous les préfixes du site, pas seulement sur la cible. |
| 02:42 | L'alerte automatisée se déclenche sur l'accessibilité depuis trois sondes externes. |
| 02:44 | L'ingénieur d'astreinte se connecte. L'attaque est visible sur les graphiques des ports et nulle part ailleurs, car notre collecte de flux était échantillonnée à un débit qui ne pouvait pas suivre. |
| 02:46 | Pic mesuré à 340 Gbit/s. La composition est de l'UDP réfléchi, principalement du DNS et du NTP, provenant de dizaines de milliers de sources. |
| 02:47 | Décision de demander à l'amont de rejeter tout le trafic vers l'adresse cible. C'était le seul outil dont nous disposions. |
| 02:49 | Le rejet se propage chez le premier amont. |
| 02:51 | Le deuxième amont l'applique. L'utilisation de l'uplink retombe sous la capacité. |
| 02:52:10 | Le site est entièrement accessible. Panne totale visible par le client : onze minutes et six secondes. |
| 03:20 | Le client affecté est contacté et une nouvelle adresse lui est proposée. |
| 03:42 | Le client est déplacé vers une nouvelle adresse ; son service revient. |
Cause racine
La cause immédiate était une attaque que nous ne pouvions pas absorber. Ce qui l'a réellement causée, c'est que nous vendions de l'hébergement dans une ville où des attaques de cette taille étaient courantes, avec deux cents gigabits d'uplink et aucun filtrage, et que nous traitions un accord de rejet en amont comme un plan.
Ce n'est pas de la malchance. C'était une décision, prise en 2019 en faveur de dépenser l'argent dans le matériel, et elle était fausse.
Deux défauts secondaires ont aggravé la situation. Notre collecte de flux était échantillonnée à un débit qui ne nous donnait aucun détail utile pendant un événement réel, donc les quatre premières minutes ont été passées à lire les compteurs d'interface. Et le rejet était manuel, nécessitant qu'un humain soit éveillé, authentifié et confiant, ce qui est trois exigences de trop à trois heures du matin.
Ce que cela a coûté au client
Soyons francs : nous avons résolu notre problème en éteignant leur service. Une route de rejet est une décision qu'un client sera injoignable pour que tout le monde ne le soit pas. C'était la bonne décision avec les outils que nous avions, c'était quand même leur panne plutôt que la nôtre, et ils n'avaient acheté aucun produit chez nous qui promettait autre chose.
Ils sont restés. Nous ne leur avons pas facturé octobre.
Ce que nous avons changé
- Scrubbing toujours actif en périphérie, acheté en moins de trois semaines, commençant à 1,2 Tbit/s de capacité. Le filtrage est en permanence dans le chemin, donc il n'y a pas de délai de détection ni de bouton à appuyer à 02 h 47. C'est désormais standard sur chaque site, jusqu'à 12 Tbit/s sur les plus grands.
- Uplink d'AMS-01 augmenté, d'abord à 200 Gbit/s de capacité supplémentaire puis aux 400 Gbit/s que le site gère aujourd'hui.
- Télémétrie de flux non échantillonnée sur chaque périphérie de site, conservée à des fins opérationnelles pendant sept jours. Ce sont des métadonnées de trafic pour nos propres ports ; ce n'est pas le trafic des instances ni le contenu de quoi que ce soit.
- La route de rejet est devenue automatique, avec un seuil documenté, une politique annoncée, et un courriel au client affecté dans les soixante secondes au lieu de trente-neuf minutes.
- Les attaques sont publiées sur la page de statut, avec la taille et la durée, que quelqu'un les ait remarquées ou non.
Ce que nous n'avons pas changé, et pourquoi
Nous n'avons pas commencé à facturer le filtrage. Le scrubbing de base est inclus dans chaque plan sur chaque site et l'a toujours été depuis le jour où nous l'avons acheté. Une attaque n'est pas un service que la victime a demandé. Le filtrage de couche 7 avec des règles personnalisées existe en option car il nécessite un humain de notre côté, et c'est une chose différente d'un flot volumétrique.
Nous n'avons pas supprimé la route de rejet. Douze térabits par seconde est un chiffre, pas l'infini, et prétendre que nous n'aurons plus jamais besoin de l'instrument brutal serait malhonnête. Ce qui a changé, c'est qu'il est désormais le dernier recours documenté plutôt que la seule étape.
Nous n'avons pas imposé de plafonds de trafic par client. Limiter chaque client à une fraction sûre de l'uplink aurait empêché cela mais aurait aussi étranglé chaque pic légitime. Le filtrage doit être en périphérie, sur l'attaque, pas sur le client.
Nous n'avons pas déplacé le client vers un produit différent. Ils faisaient tourner ce pour quoi ils avaient payé, sur le plan qui leur convenait, et ce n'était pas leur faute si quelqu'un pointait un botnet sur eux.