GitHub en 2018: l’attaque memcached qui a mis à l’épreuve l’anti

Résumé

Le 28 février 2018, GitHub a subi une attaque DDoS par réflexion-amplification utilisant des serveurs memcached accessibles en UDP. Selon le compte rendu de l’entreprise, le trafic a culminé à 1,35 Tbit/s et 126,9 millions de paquets par seconde. GitHub.com a été indisponible de 17 h 21 à 17 h 26 UTC, puis disponible de façon intermittente jusqu’à 17 h 30. GitHub a précisé que la confidentialité et l’intégrité des données n’avaient pas été menacées. [1]
À 17 h 21, la surveillance réseau a détecté une anomalie dans le rapport entre trafic entrant et trafic sortant. À 17 h 26, les équipes ont lancé une commande retirant les annonces BGP de l’AS36459 des fournisseurs de transit habituels et annonçant les préfixes exclusivement par les liaisons vers Akamai. La convergence des routes et l’application de listes de contrôle au bord du réseau d’Akamai ont permis à GitHub de constater un rétablissement complet à 17 h 30. [1]
Le changement BGP n’a pas filtré les paquets malveillants. Il a modifié le chemin par lequel Internet atteignait les préfixes de GitHub afin que le trafic arrive sur une infrastructure capable d’absorber et de filtrer le déluge. Le routage, le filtrage et la restitution du trafic légitime constituent trois fonctions distinctes, même lorsqu’elles s’enchaînent en quelques minutes.
L’attaque n’était pas un simple flux direct envoyé par un parc de machines vers GitHub. Des requêtes UDP portant une adresse source usurpée étaient envoyées à des instances memcached publiques. Ces serveurs répondaient à l’adresse de la victime avec des volumes bien supérieurs à ceux des requêtes. Cloudflare a estimé que le protocole pouvait, dans certaines conditions, produire une amplification d’environ 51 200 pour un; ce chiffre décrit un potentiel technique, et non le facteur moyen mesuré pendant l’incident de GitHub. [3]
Deux faiblesses indépendantes ont rendu la réflexion possible: des services memcached exposés à des réseaux non fiables et la possibilité d’émettre des paquets avec une adresse source forgée. Les mainteneurs du logiciel, les administrateurs de serveurs, les hébergeurs et les réseaux d’accès disposaient chacun de leviers différents. Aucun d’eux ne maîtrisait seul l’ensemble de la chaîne.
Les BCP 38 et BCP 84 décrivent des contrôles de validation des adresses sources adaptés respectivement aux cas courants et aux environnements multihébergés. Ils peuvent réduire les possibilités d’usurpation, mais ne ferment pas les services memcached exposés, ne remplacent pas la capacité de mitigation et ne garantissent pas un déploiement universel. Les mesures de CAIDA et les recommandations de MANRS illustrent à la fois l’utilité de ces contrôles et leur difficulté économique. [9][10][14][15]
La responsabilité opérationnelle doit être répartie selon les pouvoirs réels. GitHub contrôlait la détection, sa capacité directe, ses annonces de routes et la décision de basculer. Akamai contrôlait la capacité de mitigation et le filtrage à sa frontière. Les mainteneurs de memcached contrôlaient les valeurs par défaut et la documentation. Les exploitants des instances contrôlaient l’exposition et les pare-feu. Les réseaux d’accès contrôlaient la validation des sources à leurs frontières.
La principale leçon n’est donc ni qu’il suffit d’acheter davantage de bande passante, ni qu’une seule bonne pratique aurait éliminé tout risque. Elle tient à la possibilité de démontrer la continuité: détecter l’anomalie, déplacer l’autorité de routage de manière bornée, vérifier le filtrage, préserver les usages légitimes, réduire la population de réflecteurs et documenter ce qui reste inconnu.

Neuf minutes qui rendent les contrôles observables

Le compte rendu publié par GitHub fournit une chronologie inhabituellement précise pour un incident DDoS. Le 28 février 2018, GitHub.com a été indisponible entre 17 h 21 et 17 h 26 UTC. Le service est ensuite resté accessible de manière intermittente jusqu’à 17 h 30. Cette distinction importe: une indisponibilité complète et une dégradation intermittente ne décrivent ni le même impact utilisateur, ni le même état des infrastructures. GitHub a également indiqué qu’à aucun moment la confidentialité ou l’intégrité des données n’avait été mise en danger.

L’incident concernait la disponibilité du service, pas une compromission démontrée des contenus hébergés. [1]

À 17 h 21, les systèmes de surveillance ont observé une anomalie dans le rapport entre trafic entrant et sortant et ont alerté l’ingénieur d’astreinte ainsi que d’autres membres de l’équipe. GitHub a signalé qu’un de ses sites recevait alors plus de 100 Gbit/s de trafic entrant sur ses liaisons de transit. Ce signal ne disait pas encore, à lui seul, quels paquets étaient malveillants. Il établissait cependant qu’un changement brutal, incompatible avec les conditions normales du service, exigeait une décision opérationnelle. [1]

À 17 h 26, cette décision a pris la forme d’une commande exécutée à travers l’outillage opérationnel de GitHub. Les annonces BGP de l’AS36459 ont été retirées des fournisseurs de transit habituels, tandis que les préfixes concernés étaient annoncés exclusivement par les liaisons établies avec Akamai. Les réseaux extérieurs ont alors recalculé leurs chemins en fonction des nouvelles annonces disponibles. À mesure que les routes convergeaient, une part croissante du trafic destiné à GitHub atteignait l’infrastructure de mitigation. [1]

GitHub attribue le rétablissement constaté à 17 h 30 à cette convergence, combinée aux listes de contrôle appliquées à la frontière d’Akamai. Les niveaux de trafic sur les liaisons de transit et les codes de réponse des répartiteurs de charge ont servi d’indicateurs de reprise. À 17 h 34, GitHub a également retiré les routes annoncées vers les points d’échange Internet afin de déplacer environ 40 Gbit/s supplémentaires hors de son propre bord de réseau. Cette étape de suivi montre que l’état « rétabli » n’a pas mis fin à l’exploitation de l’incident: la maîtrise du chemin devait encore être consolidée. [1]

Une seconde pointe, d’environ 400 Gbit/s, est survenue peu après 18 heures sans provoquer le même résultat que la première. Ce constat ne prouve pas une immunité permanente. Le volume était différent, le chemin de mitigation avait changé et les conditions d’exploitation n’étaient plus identiques. Il fournit néanmoins un élément de continuité: pendant cette phase, un nouveau pic substantiel n’a pas recréé l’indisponibilité initiale. [1]

Les chiffres de 1,35 Tbit/s et 126,9 millions de paquets par seconde décrivent deux contraintes distinctes. Le débit binaire mesure la pression exercée sur la capacité des liens. Le débit de paquets renseigne sur le nombre de décisions de transfert ou de filtrage imposées aux équipements. Une infrastructure peut disposer d’une marge apparente en bits par seconde tout en approchant une limite de traitement des paquets. À l’inverse, de gros paquets peuvent saturer un lien sans épuiser la capacité de traitement d’un routeur. Publier les deux mesures évite de réduire la capacité réseau à un chiffre unique.

La chronologie est donc plus importante que le seul record de trafic. Elle relie un signal mesurable à une autorité humaine, une commande de routage, une convergence distribuée, un filtrage externe et des indicateurs applicatifs de reprise. Elle permet d’examiner ce qui s’est effectivement produit, sans supposer que GitHub avait la maîtrise de tous les serveurs réflecteurs, de tous les réseaux sources ou de toutes les décisions prises chez son prestataire.

Une attaque par réflexion, et non un déluge direct ordinaire

Memcached est un cache mémoire distribué conçu pour fournir rapidement des données à des applications. Son usage normal se situe à l’intérieur d’un environnement contrôlé, entre des composants qui se connaissent. Le mécanisme exploité en 2018 reposait sur des instances dont l’interface UDP restait accessible depuis l’Internet public. Ces instances acceptaient une requête sans authentification suffisante de l’émetteur et produisaient une réponse beaucoup plus volumineuse. [3][6][7][8]

L’émetteur inscrivait dans le paquet l’adresse IP de GitHub à la place de sa propre adresse. Le serveur memcached recevait donc une requête qui paraissait provenir de la victime, puis renvoyait la réponse à celle-ci. Le réflecteur n’avait pas besoin de connaître l’adresse réelle de l’émetteur. Cette redirection distingue la réflexion d’une attaque directe dans laquelle les systèmes entités ouvrent eux-mêmes des flux vers la cible avec leurs véritables adresses.

L’amplification ajoutait un second avantage pour l’attaquant. Une requête relativement petite pouvait déclencher une réponse nettement plus grande. Cloudflare a décrit un potentiel d’environ 51 200 pour un dans son analyse du protocole. [3] Il faut conserver la portée exacte de cette valeur. Elle ne constitue pas une constante applicable à chaque instance, car le résultat dépend du contenu du cache, de la requête, de la segmentation des réponses et de la méthode de mesure. Elle ne représente pas non plus un facteur moyen que GitHub aurait observé pendant l’incident.

Le sens opérationnel de ce ratio reste considérable: la capacité de sortie des serveurs exposés s’ajoutait à celle de l’émetteur. L’auteur de l’attaque n’avait pas besoin de disposer directement de 1,35 Tbit/s. Des ressources réseau appartenant à d’autres organisations ont répondu à des requêtes falsifiées et ont transporté leurs réponses jusqu’à GitHub. Le coût du trafic a ainsi été déplacé vers les réflecteurs, leurs hébergeurs, leurs fournisseurs de transit et la victime.

Deux conditions devaient coexister. Il fallait d’abord un service public capable de générer une réponse amplifiée. Il fallait ensuite qu’un paquet portant une adresse source usurpée puisse quitter le réseau de l’émetteur. Supprimer la première condition retire le réflecteur concerné du dispositif. Supprimer la seconde empêche l’émetteur de diriger la réponse vers une victime qui n’a jamais envoyé la requête. Les contrôles sont complémentaires, mais ils se trouvent à des endroits différents.

La documentation du projet memcached indique que l’UDP est désactivé par défaut depuis la version 1.5.6 et avertit les exploitants qu’un serveur ne doit pas être exposé à des réseaux non fiables. [7][8] Une valeur par défaut plus sûre réduit la probabilité qu’une installation récente devienne involontairement un réflecteur. Elle ne corrige pas à distance les anciennes versions, ne ferme pas les règles de pare-feu existantes et ne prouve pas que toutes les instances ont été mises à niveau.

Pour l’administrateur d’un serveur, les moyens de contrôle sont plus directs: désactiver l’UDP lorsqu’il n’est pas nécessaire, limiter l’écoute aux interfaces privées, filtrer le port 11211, inventorier les services exposés et appliquer les mises à jour. Pour l’hébergeur, le contrôle peut prendre la forme d’une détection des expositions à risque, d’une notification au client et d’une procédure d’intervention proportionnée. Pour le réseau d’accès, le levier se situe encore ailleurs: empêcher qu’un client n’émette un paquet avec une adresse source qu’il n’est pas autorisé à utiliser.

Cette séparation évite une conclusion commode mais erronée. GitHub était la cible et ne configurait pas les réflecteurs. Les mainteneurs de memcached pouvaient améliorer le produit, mais ne contrôlaient pas chaque déploiement. Un hébergeur pouvait restreindre une exposition sans pouvoir empêcher l’usurpation dans un autre réseau. Un fournisseur d’accès pouvait bloquer les sources falsifiées tout en hébergeant, chez un autre client, un service mal configuré qui demeurait vulnérable à des usages non réfléchis. La chaîne ne se résume pas à une faute unique.

La validation des adresses sources intervient avant la réflexion

Une attaque réfléchie repose sur une information mensongère dans l’en-tête IP. Le paquet de requête porte l’adresse de la victime comme source. Le serveur qui reçoit ce paquet n’a généralement aucun moyen de retrouver, à partir de cet en-tête, l’émetteur réel. Il traite la demande puis envoie sa réponse vers l’adresse falsifiée. Le point de contrôle le plus efficace contre ce mensonge se trouve près du réseau où le paquet est émis, avant qu’il ne traverse plusieurs domaines autonomes.

Le RFC 2827, généralement associé à la BCP 38, décrit un filtrage destiné à empêcher qu’un client situé derrière un point d’agrégation n’envoie des paquets dont l’adresse source ne correspond pas aux préfixes légitimement utilisés par ce client. [9] Du point de vue du fournisseur, le paquet arrive depuis l’accès client; le contrôle vérifie si la source revendiquée est plausible sur cette interface. Une adresse extérieure à l’ensemble autorisé peut alors être rejetée avant que le paquet n’atteigne un réflecteur.

Ce principe paraît simple dans une topologie élémentaire: un client dispose d’un préfixe connu et d’une seule connexion. Il devient plus délicat lorsqu’une organisation est multihébergée, utilise plusieurs chemins ou reçoit et émet le trafic de manière asymétrique. Le RFC 3704, associé à la BCP 84, examine ces situations et les limites d’une vérification trop stricte fondée uniquement sur le chemin inverse. [10] Une politique mal adaptée peut bloquer des paquets légitimes; une politique absente laisse partir les sources forgées.

La qualité du contrôle dépend donc de la qualité des données opérationnelles. Les préfixes autorisés doivent être exacts. Les changements d’affectation doivent être reflétés dans les filtres. Les exceptions doivent être documentées. Les rejets doivent pouvoir être observés et examinés. Une règle installée puis oubliée peut devenir incorrecte. Une règle trop large peut accepter des sources que le client ne devrait pas employer. La validation des adresses sources est une pratique continue, pas une case de configuration définitivement cochée.

Le projet Spoofer de CAIDA mesure si des réseaux permettent l’émission de paquets portant des adresses sources falsifiées. [14] Ce type de mesure rend visible une propriété qui resterait autrement abstraite. Il peut montrer qu’un accès autorise ou refuse certains essais d’usurpation. Il ne permet cependant pas, sans données correspondantes, d’identifier rétroactivement le réseau qui aurait transporté les requêtes de l’attaque contre GitHub.

MANRS présente également l’anti-usurpation comme une action concrète attendue des opérateurs réseau et fournit des indications de mise en œuvre. [15] Ces références transforment un objectif général — empêcher l’usage trompeur des adresses — en pratiques vérifiables. Elles ne constituent pas un verdict contre un système autonome particulier. Le dossier public de GitHub ne fournit ni la liste complète des réseaux ayant hébergé les réflecteurs, ni celle des réseaux à partir desquels les requêtes falsifiées ont réellement été émises.

La prudence d’attribution est essentielle. Une adresse de réflecteur révèle l’emplacement apparent du serveur qui a répondu, pas nécessairement celui de l’émetteur initial. Un réseau visible sur un chemin peut être un transporteur intermédiaire. Une mesure de capacité d’usurpation effectuée à une autre date ne prouve pas qu’un paquet précis a traversé ce réseau le 28 février 2018. Demander aux opérateurs de conserver des preuves est légitime; transformer des indices généraux en accusation ne l’est pas.

La validation des sources possède aussi une limite fonctionnelle nette. Elle vise les paquets dont l’adresse source est falsifiée. Elle n’arrête pas un flux direct émis avec une adresse réelle par une machine compromise. Elle ne ferme pas une interface memcached publique. Elle n’offre pas de capacité d’absorption à GitHub et ne garantit pas que les routes vers Akamai convergeront. La présenter comme une solution complète aux DDoS masquerait les autres dépendances décisives.

Son intérêt tient précisément à sa place dans la chaîne. Lorsqu’elle est déployée au bon bord de réseau, elle protège des tiers que l’opérateur ne connaît peut-être pas et avec lesquels il n’a aucun contrat. Le bénéfice est mondial, tandis que le coût d’ingénierie, de support et de maintenance reste local. Cette asymétrie explique en partie pourquoi un contrôle techniquement connu peut demeurer inégalement appliqué.

Le problème économique de l’anti-usurpation

Un réseau qui déploie correctement la validation des adresses sources réduit surtout le risque que ses clients servent de point de départ à des attaques contre d’autres organisations. Ses propres abonnés ne constatent pas nécessairement un avantage immédiat. Ils peuvent, en revanche, remarquer rapidement une erreur de filtrage qui bloque une architecture asymétrique ou une nouvelle affectation de préfixe. Les coûts visibles sont internes; une grande partie des bénéfices est distribuée ailleurs.

Cette structure affaiblit le signal commercial. Une victime d’attaque ne sait pas toujours quel réseau aurait pu empêcher les premières requêtes usurpées. Elle ne peut donc pas récompenser facilement les opérateurs rigoureux ni faire pression sur ceux dont les contrôles sont insuffisants. Le fournisseur, de son côté, peut avoir du mal à justifier du temps d’exploitation pour un risque qui ne produit pas d’incident apparent chez ses propres clients.

Les mesures comparables, les exigences d’interconnexion et les engagements publics peuvent modifier cette équation. Un opérateur capable de démontrer que ses accès ne permettent pas l’émission de sources arbitraires apporte une propriété de sécurité utile à ses pairs et à ses clients. Encore faut-il que la preuve soit récente, représentative des différentes topologies et accompagnée d’une procédure de correction. Un pourcentage global de déploiement ne remplace pas l’état réel d’une interface donnée.

Les contacts d’abus jouent ici un rôle opérationnel. Lorsqu’une victime ou un chercheur identifie un service exposé, il faut pouvoir joindre rapidement l’organisation qui contrôle le serveur ou l’accès concerné. Une adresse de contact obsolète, une chaîne d’escalade imprécise ou l’absence de télémétrie rallonge la durée d’exposition. La prévention n’est donc pas seulement une question de filtres; elle dépend aussi de la capacité à relier une ressource réseau à un responsable joignable.

La responsabilité raisonnable consiste à demander des éléments proportionnés: quels préfixes étaient autorisés, quel contrôle était appliqué, comment les exceptions étaient gérées, quand le dernier test a été effectué et comment une alerte d’abus a été traitée. Elle ne consiste pas à supposer qu’un opérateur connaissait nécessairement l’usage de chaque paquet ni à conclure à une responsabilité juridique à partir d’une simple possibilité technique.

Détecter l’anomalie avant que le routage ne puisse aider

Le basculement vers Akamai n’aurait servi à rien si GitHub n’avait pas d’abord identifié qu’un événement anormal dépassait ses conditions d’exploitation ordinaires. L’entreprise a déclaré que son système de surveillance avait détecté un déséquilibre inhabituel entre le trafic entrant et le trafic sortant. [1] Ce choix d’indicateur est pertinent pour une attaque par réflexion: un volume massif arrive sans correspondre à l’activité sortante ou aux réponses applicatives normalement attendues.

Un rapport anormal ne fournit toutefois pas un diagnostic complet. Il peut résulter d’une attaque, d’un afflux légitime, d’une erreur de mesure, d’une panne en aval ou d’un changement de comportement des utilisateurs. Il faut rapprocher plusieurs plans d’observation: débit et nombre de paquets aux interfaces, protocoles et ports dans les données de flux, concentration des destinations, état des routeurs et des répartiteurs, taux de réussite des requêtes applicatives, latence régionale et signalements des utilisateurs.

Chaque vue répond à une question différente. Le débit montre la pression sur un lien, mais pas l’intention des paquets. Une signature correspondant à des réponses UDP depuis le port 11211 éclaire le vecteur, sans prouver que chaque datagramme est malveillant. Les codes de réponse des répartiteurs indiquent si le service fonctionne, mais peuvent masquer une dégradation limitée à certaines régions. La visibilité BGP confirme le déplacement de la route, mais ne mesure pas la qualité du filtrage.

Le seuil de déclenchement d’une mitigation est lui-même un choix de responsabilité. Un seuil trop tardif laisse le service atteindre sa limite avant la convergence des routes. Un seuil trop sensible peut détourner du trafic légitime à chaque pointe momentanée, augmenter les coûts, provoquer une instabilité de routage ou exposer les utilisateurs aux défaillances du chemin de secours. Le seuil doit donc être fondé sur des mesures connues, assorti d’une possibilité de dérogation et réexaminé après incident.

GitHub a annoncé vouloir réduire sa dépendance à l’intervention humaine en utilisant davantage son infrastructure de surveillance pour activer les prestataires de mitigation. [1] L’objectif est compréhensible: cinq minutes représentent un délai long pour un service mondial. Mais accélérer l’action ne suffit pas. Une détection automatique doit savoir quels préfixes elle peut déplacer, vers quel prestataire, dans quelles conditions et avec quels moyens de retour arrière.

L’élément décisif n’est pas de choisir abstraitement entre humain et automatisation. Il faut définir une autorité bornée. Le système peut recommander un basculement lorsque plusieurs signaux concordent, exécuter automatiquement une action limitée sur des préfixes préapprouvés et exiger une confirmation pour une situation inconnue. Dans tous les cas, l’opérateur doit pouvoir interrompre l’action et vérifier, depuis des points d’observation externes, que les annonces voulues sont réellement visibles.

Le BGP déplace la joignabilité; il ne nettoie pas les paquets

L’AS36459 identifie le domaine de routage utilisé par GitHub dans le compte rendu. [1] Un numéro de système autonome n’est pas une simple étiquette administrative: il désigne un ensemble qui peut annoncer des préfixes IP et échanger des routes avec d’autres réseaux. Lorsqu’un opérateur modifie les voisins par lesquels un préfixe est annoncé, il modifie les chemins que les réseaux extérieurs peuvent choisir pour atteindre les adresses correspondantes.

À 17 h 26, GitHub a retiré ses annonces des fournisseurs de transit habituels et a annoncé ses routes exclusivement par ses liaisons vers Akamai. [1] Cette action a déplacé la destination logique du trafic entrant. Elle n’a inspecté ni rejeté aucun paquet. Les paquets sont devenus filtrables parce qu’ils arrivaient désormais à une frontière où Akamai disposait de capacité et de règles de mitigation.

La distinction est fondamentale. Le BGP répond à la question: « Par quel réseau le trafic destiné à ce préfixe doit-il passer ? » Le filtrage répond à une autre question: « Quels paquets doivent être rejetés ou autorisés ? » La restitution du trafic légitime en pose une troisième: « Comment les paquets conservés rejoignent-ils le service sans créer un nouveau goulot d’étranglement ? » Confondre ces fonctions conduit à créditer le routage d’un effet qu’il n’a pas.

La convergence n’est pas instantanée. GitHub peut envoyer une annonce ou un retrait à ses voisins, mais ne peut pas ordonner à tous les routeurs d’Internet de mettre à jour leur table au même moment. Chaque réseau traite le changement, applique sa propre politique, choisit un chemin et propage ce qu’il retient. Pendant cette période, certains utilisateurs peuvent encore suivre un ancien trajet tandis que d’autres atteignent déjà le réseau de mitigation.

Le compte rendu permet d’affirmer que la combinaison du changement de route et du filtrage a produit un rétablissement en quelques minutes. Il ne révèle pas les longueurs exactes des préfixes, les communautés BGP utilisées, les préférences locales, l’architecture de retour ni les règles internes d’Akamai. L’analyse doit s’arrêter à cette limite. Les faits publics établissent la séquence opérationnelle, pas le schéma complet d’une configuration privée.

Un basculement de cette nature comporte plusieurs risques. L’oubli d’un préfixe peut laisser une partie du service inaccessible. Une annonce plus spécifique ou plus agrégée peut interagir de façon inattendue avec les routes existantes. Une autorisation absente chez le prestataire peut faire rejeter l’annonce. Une fuite de route peut détourner le trafic. Une capacité de retour insuffisante peut transformer la sortie du centre de mitigation en nouveau point de congestion.

L’asymétrie des chemins peut également perturber des équipements qui maintiennent un état de connexion. Les services DNS, les systèmes d’authentification ou d’autres dépendances peuvent demeurer indisponibles alors que le préfixe principal redevient joignable. Une vérification limitée au fait qu’une route apparaît dans une table locale ne suffit donc pas. Il faut contrôler la visibilité externe et le comportement réel de l’application.

Un transfert préparé doit produire des preuves avant l’urgence. L’opérateur doit connaître les préfixes concernés, les sessions utilisables, les filtres et limites applicables, la procédure d’autorisation chez le prestataire, la capacité de retour et le mécanisme de retrait après l’attaque. Les exercices doivent tester une réussite complète, mais aussi un préfixe manquant, une liaison de retour saturée, une région qui ne converge pas ou un prestataire qui ne peut pas accepter toute la charge.

Le basculement crée enfin une dépendance assumée. Dès que le trafic emprunte exclusivement le réseau d’Akamai, la continuité de GitHub dépend aussi de la capacité, des systèmes de contrôle, des filtres et de la connectivité de ce prestataire. Une telle dépendance peut accroître la résilience lorsqu’elle est choisie, testée et observable. Elle devient fragile lorsque le client ne peut pas vérifier que le chemin est prêt ni revenir proprement à son routage normal.

La capacité brute n’est pas synonyme de résilience

GitHub avait plus que doublé sa capacité de transit au cours de l’année précédente et développait des relations d’interconnexion sur plusieurs points d’échange. [1] Ces investissements lui avaient permis d’absorber certaines attaques volumétriques sans impact apparent pour les utilisateurs. Pourtant, le trafic du 28 février a justifié le recours à un réseau disposant d’une capacité de bord plus importante.

Il serait erroné d’en conclure que la capacité directe ne sert à rien. Elle absorbe la croissance normale, les pointes locales et les attaques moins importantes. Elle fournit aussi le temps nécessaire pour détecter un événement et activer un autre chemin. Plusieurs liaisons réduisent le risque qu’une congestion isolée coupe tout le service. La capacité devient toutefois insuffisante lorsqu’elle n’est pas disponible au bon endroit ou qu’elle ne peut pas être mobilisée par une action de routage sûre.

Une capacité agrégée élevée dans un réseau dorsal ne protège pas nécessairement une liaison de site plus étroite. Une infrastructure de mitigation puissante ne sert à rien si les routes ne peuvent pas lui être transférées. Un prestataire mondial n’aide pas si les préfixes du client ne sont pas autorisés ou si le canal de retour ne peut transporter le trafic légitime. Plusieurs pairs ne créent pas une véritable diversité s’ils partagent le même bâtiment, la même fibre ou la même limite de filtrage.

Les 126,9 millions de paquets par seconde publiés par GitHub rappellent que la bande passante n’est qu’une dimension. [1] Des paquets de petite taille peuvent exercer une forte pression sur les tables, les files, les interruptions ou les opérations de filtrage, même avant la saturation du débit nominal d’un lien. Une affirmation de capacité responsable doit préciser la ressource mesurée, le point de mesure et la durée du pic.

Le lieu de mesure compte également. Un volume observé à la frontière d’un prestataire n’est pas nécessairement celui qui atteint l’origine. Une somme calculée sur plusieurs sites ne décrit pas la pression exercée sur chaque liaison. Un pic très bref et une charge soutenue de plusieurs minutes posent des problèmes différents. Les valeurs de GitHub sont utiles et attribuées, mais elles ne permettent pas de déduire la limite exacte de chaque équipement.

La résilience ne consiste donc pas à promettre une capacité infinie. Elle consiste à connaître les limites directes, à détecter leur approche, à disposer d’un chemin de secours vérifié et à préserver les fonctions essentielles pendant le changement. Le chiffre le plus élevé attire l’attention; la continuité dépend de la manière dont les ressources sont reliées, commandées et observées.

Le résultat à prouver est la livraison du trafic légitime

Une mitigation DDoS n’est pas réussie simplement parce qu’un grand volume de paquets a été rejeté. Elle doit aussi permettre aux utilisateurs légitimes d’atteindre le service. Le filtrage produit donc deux résultats inséparables: réduire le trafic indésirable et conserver suffisamment de trafic valide pour que l’application fonctionne.

Les méthodes de filtrage peuvent s’appuyer sur la forme des paquets, les protocoles, les ports, les débits, des comportements connus ou du contexte applicatif. Chacune peut générer des faux positifs. Une règle ciblant précisément des réponses memcached peut être adaptée au vecteur observé. Un blocage très large de l’UDP peut perturber d’autres services. Une limitation de débit peut protéger l’origine tout en pénalisant des utilisateurs situés derrière une adresse partagée.

GitHub a déclaré que les listes de contrôle appliquées à la frontière d’Akamai avaient contribué au rétablissement. [1] Le rapport ne détaille pas ces règles et ne mesure pas leur taux de faux positifs. Il permet d’attribuer un résultat global au chemin de mitigation, pas de prétendre que chaque requête légitime a réussi dans toutes les régions.

La livraison dépend aussi du trajet entre le prestataire et l’infrastructure du client. Une liaison privée ou un tunnel sous-dimensionné peut devenir le nouveau goulot d’étranglement. Un chemin non protégé vers l’origine peut permettre de contourner la mitigation. Des routes aller et retour différentes peuvent perturber les contrôles avec état. Ces risques doivent être testés avant l’incident, même lorsque leur architecture exacte reste confidentielle.

Une preuve de reprise doit combiner plusieurs observations: visibilité des routes depuis des réseaux indépendants, activité de filtrage chez le prestataire, niveaux de charge acceptables aux interfaces de l’origine, réussite de transactions applicatives, latence, erreurs et accessibilité depuis plusieurs régions. Le premier signal vert ne suffit pas, car un attaquant peut changer de vecteur ou déclencher une seconde vague.

Dans le cas de GitHub, la surveillance du trafic de transit et des codes de réponse des répartiteurs de charge a servi à déclarer le rétablissement à 17 h 30. [1] La pointe ultérieure de 400 Gbit/s, qui n’a pas reproduit l’interruption initiale, apporte une observation supplémentaire. Elle ne résout pas tous les risques futurs, mais montre que l’état opérationnel avait changé d’une façon mesurable.

Répartir la responsabilité selon le contrôle réel

La première sphère de contrôle était celle de GitHub. L’entreprise gérait sa surveillance de bord, sa capacité directe, ses relations de transit et d’interconnexion ainsi que l’autorité nécessaire pour modifier les annonces de l’AS36459. Elle devait reconnaître la dégradation, décider du basculement, vérifier les nouvelles routes et mesurer le retour du service. Son compte rendu public documente une partie importante de cette chaîne, tout en laissant privés les seuils et les détails de politique.

La deuxième sphère appartenait à Akamai. Le prestataire devait accepter les annonces prévues, disposer d’une capacité suffisante, appliquer un filtrage pertinent et restituer le trafic conservé. La reprise décrite par GitHub soutient la conclusion que ce chemin a fonctionné pendant l’incident. Elle ne révèle ni les méthodes internes exactes, ni les conditions contractuelles, ni tous les résultats régionaux.

La troisième sphère concernait le logiciel. Les mainteneurs de memcached pouvaient réduire les configurations dangereuses par défaut et publier des avertissements clairs. La désactivation par défaut de l’UDP à partir de la version 1.5.6 constitue une réduction concrète du risque. [7] Elle ne signifie pas que les mainteneurs étaient responsables de chaque installation existante, pas plus qu’elle ne prouve que tous les anciens serveurs ont été corrigés.

La quatrième sphère revenait aux exploitants des instances. Ils contrôlaient l’interface d’écoute, l’activation de l’UDP, les règles de pare-feu, les mises à niveau et l’exposition aux réseaux non fiables. Un cache destiné à des applications internes n’avait généralement pas besoin de répondre à des hôtes arbitraires sur Internet. L’inventaire de cette exposition et sa suppression relevaient donc d’un contrôle local.

Les hébergeurs occupaient une position intermédiaire. Ils pouvaient détecter certains services exposés, informer les clients, maintenir des contacts d’abus et intervenir lorsque leur infrastructure causait un dommage manifeste, sous réserve des contrats et du droit applicable. Cette possibilité ne justifie pas un blocage silencieux de tous les services UDP. Elle exige plutôt une politique explicite, une observation suffisante et une réponse proportionnée.

La cinquième sphère était celle des réseaux d’accès et des frontières clientes. Ces réseaux pouvaient vérifier qu’un paquet quittant un client utilisait une adresse source autorisée. Leur responsabilité différait de celle de l’opérateur du réflecteur. Un réseau pouvait empêcher toute usurpation sortante sans fermer un serveur memcached exposé ailleurs. Inversement, un hébergeur pouvait sécuriser tous ses caches tout en restant incapable d’empêcher une usurpation provenant d’un autre réseau.

Les fournisseurs de transit et les points d’échange transportaient le trafic et les informations de joignabilité selon leurs politiques. Ils n’étaient pas automatiquement en mesure de déterminer l’intention de chaque paquet. Ils devaient néanmoins disposer de pratiques de routage, de capacité, de contacts et d’escalade compatibles avec la continuité de leurs clients.

L’auteur de l’attaque contrôlait le choix de la cible et la génération des requêtes, mais le dossier public ne permet pas de l’identifier. Il ne fournit pas non plus une liste définitive des propriétaires de réflecteurs ou des réseaux d’émission. Une analyse de responsabilité opérationnelle peut décrire les contrôles disponibles sans inventer une identité, une intention, une négligence constatée ou une conclusion juridique.

Cette cartographie empêche une conclusion binaire. GitHub pouvait avoir préparé un transfert efficace alors que l’écosystème restait vulnérable à l’usurpation. Memcached pouvait adopter un réglage plus sûr tandis que des versions anciennes demeuraient publiques. Akamai pouvait filtrer le vecteur observé sans garantir que toute attaque future serait absorbée. Le progrès dans une sphère mérite d’être reconnu sans déclarer que la chaîne entière est résolue.

Automatiser le basculement sans dissimuler l’autorité

L’intérêt exprimé par GitHub pour une activation plus automatisée répond à une contrainte réelle: entre 17 h 21 et 17 h 26, cinq minutes se sont écoulées avant le lancement de la commande de basculement. [1] Pour une plateforme mondiale, ce délai peut représenter un nombre considérable d’échecs et une pression importante sur les équipes. Une action préautorisée peut être plus rapide qu’une succession d’appels, de validations manuelles et de modifications improvisées.

La vitesse ne garantit toutefois pas la sûreté. Un faux positif pourrait envoyer un trafic légitime vers un chemin inutilement coûteux ou moins performant. Une liste de préfixes incomplète pourrait couper une partie du service. Une session indisponible chez le prestataire pourrait recevoir des annonces qu’elle ne peut pas servir. Une erreur dans le système de commande pourrait transformer un incident local en perte globale de joignabilité.

Une conception prudente sépare la détection, la recommandation et l’action. La détection rassemble plusieurs signaux. Une politique peut recommander le basculement lorsque le débit, le type de trafic et les indicateurs applicatifs convergent. L’action automatique peut être réservée à des préfixes, des voisins et des conditions préapprouvés. Les situations nouvelles ou ambiguës peuvent rester soumises à une confirmation humaine.

Les protections de routage doivent être explicites. La liste des préfixes doit être actuelle. Les sessions et les autorisations du prestataire doivent être testées. Les filtres et limites de préfixes doivent contenir les erreurs. Les annonces doivent être observées depuis l’extérieur, car l’état d’un routeur local ne garantit pas que le chemin attendu est sélectionné ailleurs.

L’automatisation doit aussi prévoir la sortie. Retirer trop tôt les routes de mitigation peut exposer le service à une nouvelle vague. Les conserver indéfiniment peut augmenter la latence, le coût ou la dépendance. La politique de retour doit définir une période d’observation stable, un retrait progressif, des mesures de réussite et une possibilité de revenir immédiatement au chemin protégé.

L’autorité humaine ne disparaît pas. Les attaques sont adaptatives: protocole, taille des paquets, destination et rythme peuvent évoluer après l’application d’une règle. Les opérateurs doivent pouvoir changer de stratégie. Cette intervention doit cependant emprunter des commandes testées, limitées et enregistrées, plutôt que dépendre d’une improvisation impossible à reconstruire après coup.

Un système rapide mais opaque peut réduire la durée de l’interruption tout en affaiblissant la responsabilité. Un système responsable doit permettre de dire quel signal a déclenché l’action, quelle route a changé, quel prestataire a accepté le trafic, quels indicateurs ont confirmé le filtrage et pourquoi le retour au chemin normal a été autorisé.

Le compte rendu d’incident est lui-même un contrôle

La publication de GitHub est utile parce qu’elle fournit davantage qu’une assurance générale. Elle contient des horaires UTC, des débits en bits et en paquets, un numéro de système autonome, la nature de la commande de routage, le nom du prestataire et les indicateurs employés pour déclarer la reprise. [1] D’autres opérateurs peuvent confronter ces éléments à leurs propres capacités.

Une transparence responsable possède des limites. Dévoiler en temps réel les règles exactes de filtrage peut aider un adversaire à les contourner. Publier une topologie détaillée, des identifiants internes ou des clauses contractuelles peut créer de nouveaux risques. Les communications privées et les données des clients doivent rester protégées. La responsabilité n’exige pas une exposition intégrale de l’infrastructure.

Elle exige néanmoins assez de précision pour relier le résultat à un contrôle. Une formule comme « l’attaque a été mitigée » ne permet pas de savoir quand elle a été détectée, quelle action a changé, ni comment le retour du service a été vérifié. Un compte rendu borné peut décrire le vecteur, l’échelle mesurée, la fenêtre d’impact, le principal changement de réseau, les signaux de reprise et les travaux correctifs.

L’observation doit être séparée de l’inférence. GitHub a mesuré son trafic et décrit ses décisions. Cloudflare a analysé le potentiel d’amplification de memcached. CISA a recensé memcached parmi les protocoles UDP utilisables pour la réflexion. CAIDA mesure la possibilité d’émettre des sources falsifiées. Ces éléments expliquent ensemble le mécanisme, mais aucun ne fournit à lui seul une attribution complète de l’incident. [1][3][6][14]

Cette séparation protège aussi la qualité des décisions. Un serveur qui répond à une requête usurpée peut être mal configuré, ancien, compromis ou délibérément public; la réponse ne révèle pas automatiquement l’intention de son propriétaire. Un réseau visible dans des données de chemin peut n’être qu’un transit. Une adresse IP sans contexte historique ne suffit pas à déterminer qui contrôlait le système au moment exact de l’attaque.

Les comptes rendus peuvent pourtant accélérer la défense collective. Les exploitants peuvent rechercher le port concerné, revoir les valeurs par défaut, tester la validation des sources, préparer un basculement de routes et améliorer leurs alarmes. Leur utilité augmente lorsque les auteurs distinguent clairement les faits mesurés, les déductions techniques et les inconnues.

Un dossier minimal pour les futurs incidents volumétriques

Un opérateur devrait d’abord conserver une chronologie synchronisée: premier signal anormal, alerte, décision, commande, visibilité externe du changement de route, début du filtrage, première amélioration applicative, rétablissement déclaré et retour au chemin normal. Des horloges incohérentes peuvent rendre impossible l’attribution d’un délai à la détection, à l’autorisation, à la convergence ou au prestataire.

Le dossier doit préciser les dimensions de charge observées: bits par seconde, paquets par seconde, protocoles, ports, destinations, durée des pointes et emplacement des mesures. Il doit distinguer le trafic vu à la frontière de celui qui atteint l’origine après filtrage. Sans cette distinction, un même chiffre peut être attribué à tort à plusieurs composants.

Les éléments de routage doivent inclure les préfixes déplacés, les voisins utilisés, l’heure des annonces et retraits, les résultats observés depuis des points externes et toute exception. Il n’est pas nécessaire de rendre tous ces détails publics. Ils doivent toutefois exister pour que l’organisation puisse expliquer si le délai provenait de sa commande, de la propagation ou d’une autorisation manquante.

Les éléments de mitigation doivent décrire le vecteur classifié, le volume rejeté, les limites atteintes, les faux positifs connus et la qualité du trafic restitué. Les indicateurs applicatifs doivent compléter les compteurs réseau: taux de réussite, latence, erreurs, disponibilité régionale et fonctionnement des dépendances essentielles.

Du côté des réflecteurs, les organisations concernées devraient préserver l’état du service, la version utilisée, l’interface d’écoute, les règles de pare-feu, les journaux disponibles, la date de fermeture et la procédure de notification. L’objectif n’est pas de publier une liste accusatoire, mais de vérifier que l’exposition a réellement été réduite.

Du côté des réseaux sources, les preuves pertinentes comprennent les préfixes autorisés sur chaque accès, la politique de validation, les exceptions, les résultats de tests et les changements effectués après signalement. Une déclaration générale de conformité ne remplace pas une vérification bornée dans le temps.

Enfin, le dossier doit relier chaque action à une autorité. Qui pouvait déplacer les routes ? Qui pouvait demander l’intervention du prestataire ? Qui pouvait modifier un filtre ou désactiver un service ? Qui a déclaré la reprise ? Cette traçabilité ne sert pas uniquement à rechercher une faute; elle permet de réduire les délais et les ambiguïtés lors de l’incident suivant.

Ce que les éléments publics ne démontrent pas

Les sources publiques ne permettent pas d’identifier l’auteur de l’attaque ni son mobile. GitHub n’a pas fourni d’attribution définitive dans son compte rendu. Le fait qu’un mécanisme soit compatible avec d’autres campagnes connues ne suffit pas à établir une identité dans ce dossier.

Elles ne fournissent pas non plus la liste complète des réflecteurs, de leurs propriétaires ou des réseaux à partir desquels les requêtes falsifiées ont été émises. Elles ne démontrent pas qu’un système autonome nommé savait que son infrastructure contribuait à l’attaque. Les mesures générales sur l’usurpation ne peuvent pas être appliquées rétroactivement sans correspondance technique et temporelle.

Le rapport ne révèle pas la politique BGP privée de GitHub, les communautés utilisées, l’architecture de retour, les seuils commerciaux, les engagements de capacité ou les règles détaillées d’Akamai. Il permet d’analyser un transfert de responsabilité opérationnelle, pas de reconstituer une configuration propriétaire.

Le pic de 1,35 Tbit/s ne prouve pas que chaque lien ou chaque équipement a traité ce volume. Le point de mesure et l’agrégation comptent. De même, 126,9 millions de paquets par seconde ne révèlent pas quel composant a constitué la première limite. L’indisponibilité puis la reprise montrent un impact et un changement de résultat, sans identifier tous les goulots d’étranglement internes. [1]

Aucun montant fiable de pertes clients ou de dommages contractuels n’est fourni. L’indisponibilité d’une plateforme de développement peut perturber de nombreuses organisations, mais l’importance potentielle de ces dépendances n’autorise pas l’invention d’un chiffre. Les faits disponibles ne fondent pas davantage une conclusion de négligence ou de responsabilité juridique.

La pointe ultérieure de 400 Gbit/s ne prouve pas que GitHub était définitivement protégé. Elle montre seulement qu’un trafic différent, survenu dans un état opérationnel différent, n’a pas reproduit le premier résultat. Les vecteurs, les capacités et les dépendances évoluent.

Ces limites ne diminuent pas l’analyse; elles la rendent plus solide. Elles recentrent l’examen sur ce qui peut être démontré: le temps de détection, l’autorité de routage, le transfert vers la mitigation, le rôle du filtrage, l’exposition du protocole, la validation des sources et les preuves de reprise.

La continuité démontrable comme norme opérationnelle

Aucun réseau ne peut garantir que toute attaque sera sans effet. Un adversaire peut agréger davantage de ressources, changer de protocole, cibler une dépendance ou passer d’un déluge volumétrique à l’épuisement d’une fonction applicative. Exiger une défense parfaite créerait une norme impossible et encouragerait les déclarations vagues.

Une exigence plus utile est la continuité démontrable dans des conditions définies. L’opérateur doit connaître les limites de ses chemins directs, le temps nécessaire à l’activation de la mitigation, les hypothèses de convergence, la capacité de retour et les sondes applicatives essentielles. Il doit tester le transfert avant l’urgence et consigner les écarts observés.

La même logique s’applique à l’écosystème source. Les réseaux d’accès doivent pouvoir tester si leurs clients peuvent émettre des adresses falsifiées. Les hébergeurs doivent pouvoir identifier des services à haut risque et joindre leurs responsables. Les projets logiciels doivent choisir des valeurs par défaut prudentes et rendre l’exposition réseau explicite.

Cette norme reconnaît les compromis. Un filtrage trop strict peut casser une topologie asymétrique légitime. Une règle DDoS agressive peut exclure de vrais utilisateurs. Un basculement peut augmenter la latence ou la dépendance. Désactiver un protocole peut affecter une application existante. L’exploitation responsable ne nie pas ces coûts: elle les documente et choisit des contrôles bornés.

C’est ici que la responsabilité se distingue du blâme. Le blâme cherche un nom unique après le dommage. La responsabilité opérationnelle demande qui contrôlait une décision, quelles preuves étaient disponibles, quelles limites s’appliquaient, comment l’action a été observée et ce qui a changé ensuite. Plusieurs organisations peuvent être responsables de contrôles distincts sans porter la même part dans l’attaque elle-même.

Le cas GitHub rend cette structure visible. L’exposition de memcached a fourni l’amplification. L’usurpation a redirigé les réponses. La surveillance a détecté le déluge. L’autorité BGP a déplacé la joignabilité. Akamai a filtré le trafic. Les mesures applicatives ont établi le rétablissement. Chaque étape constitue un contrôle distinct que d’autres opérateurs peuvent tester.

Conclusion

L’attaque memcached contre GitHub n’est pas seulement restée dans les mémoires pour son pic de 1,35 Tbit/s. Elle a montré comment l’autorité réseau doit se déplacer sous pression. GitHub a détecté une anomalie, retiré les annonces ordinaires de l’AS36459, annoncé ses préfixes par Akamai et constaté le rétablissement après convergence et filtrage. [1]

Le mécanisme révélait en parallèle une défaillance distribuée. Des services memcached publics ont produit des réponses amplifiées. Des adresses sources falsifiées les ont dirigées vers la victime. Plusieurs réseaux ont transporté le trafic. GitHub et son prestataire ont dû préserver la joignabilité tout en rejetant le déluge.

Aucun contrôle isolé n’explique le résultat. Davantage de transit ne ferme pas les réflecteurs. Un retrait BGP ne classe pas les paquets. L’anti-usurpation ne configure pas les serveurs et ne fournit pas de capacité de mitigation. Une valeur memcached plus sûre ne corrige pas chaque installation ancienne. Un prestataire puissant ne peut agir si le transfert de routes n’est ni préparé ni vérifiable.

La norme pertinente est une chaîne de preuves: savoir quand le dommage a été détecté, qui pouvait déplacer les routes, comment le chemin de mitigation a été contrôlé, quels signaux ont prouvé la reprise et quelles conditions favorisant l’attaque ont ensuite été réduites. GitHub a rendu une part importante de cette chaîne observable sans prétendre résoudre toutes les inconnues.

La résilience réseau devient crédible lorsque les organisations qui détiennent un pouvoir concret peuvent démontrer comment le trafic a été mesuré, comment l’autorité a changé de main, comment les usages légitimes ont été préservés et comment la probabilité d’une répétition a été diminuée.

GitHub en 2018: l’attaque memcached qui a mis à l’épreuve l’anti-usurpation et le basculement vers la mitigation