Cloudflare a gagné au cours de la dernière décennie la réputation d'être l'un des géants technologiques les plus redoutés par les attaquants d'Internet. Son infrastructure mondiale agit comme un bouclier anti-DDOS capable d'arrêter des vagues de trafic malveillantes qui laisseraient toute autre infrastructure en ligne à genoux. C'est, en fait, la société qui se vante d'avoir contenu des attaques de plus de 11 térabits par seconde et des milliards de demandes par seconde.
En outre, pour des entités telles que Laliga, qui a tenté de lutter contre la diffusion non autorisée des émissions sportives en temps réel, Cloudflare est devenu un cauchemar qui ne va pas avec eux le blocus de ces émissions, ce qui en a fait la cible de toutes ses fléchettes juridiques et médiatiques.
Cependant, le 12 septembre, le chasseur est devenu son propre barrage: la société s'est spécialisée dans les cyberattaques à soi-même en raison d'une erreur de programmation dans son panneau de contrôle. Le résultat: plus d'une heure de baisse de ses API internes et de son tableau de bord, outil clé pour des millions de clients dans le monde.
Comment pouvez-vous «vous auto-attirer» une entreprise comme CloudFlare?
L'ironie de l'événement n'est pas passée inaperçue: CloudFlare a expliqué dans un rapport détaillé que l'incident a commencé avec le déploiement d'une nouvelle version de son tableau de bord (le panneau de gestion utilisé par les clients). Et dans le code de réaction de cette interface, il y avait une erreur dans l'utilisation du crochet useEEFFECT.
Ainsi, au lieu d'exécuter une pétition à l'API du service du locataire (le service en charge d'autoriser les demandes) qu'une seule fois, le bogue l'a fait répéter en boucle chaque fois que l'état de la demande modifiait. En pratique, cela signifiait des milliers d'appels redondants en quelques secondes.
Le moment ne pouvait pas être pire: presque en parallèle, l'équipe d'ingénierie avait déployé une nouvelle version de l'API du service de locataire lui-même. La combinaison des deux facteurs a déclenché ce que dans le jargon est connu sous le nom de «troupeau de trombe»: une bousculade de demandes légitimes mais incontrôlées qui ont saturé au service, incapable de récupérer seule.
L'utilisation problématique de «useeffect»
L'épicentre de cette tempête était une ancienne connaissance de la communauté des développeurs React: The Hook Utiliser EFFECT. Cette fonction, conçue pour gérer les effets secondaires, peut devenir un piège si vos dépendances sont incorrectement incorporées. Dans ce cas, un objet qui réagit traité comme «nouveau» a été inclus dans chaque changement d'état, ce qui a provoqué l'exécution de l'effet à plusieurs reprises dans un cycle infini.
La propre documentation officielle de React avertit ce type d'erreurs, et dans des forums tels que Reddit, le cas de Cloudflare a ravivé le débat sur la question de savoir si l'industrie dépend excessive Utiliser EFFECT pour les tâches qui devraient être résolues d'une autre manière.
Chronologie d'une chute annoncée
Les «auto-ddos» ont eu lieu sur trois heures de vertige:
- 16:32 UTC: La nouvelle version du tableau de bord avec le bug est lancée.
- 17:50 UTC: Déploiement de la nouvelle API du service de locataire.
- 17:57 UTC: Le service est dépassé. Le tableau de bord devient inopérant et les API commencent à renvoyer des erreurs 5xx.
- 18:17 UTC: Après avoir ajouté plus de ressources, la disponibilité des API s'élève à 98%, mais le tableau de bord est toujours tombé.
- 18:58 UTC: CloudFlare publie un patch pour éliminer les itinéraires avec des erreurs … mais aggrave la situation.
- 19:12 UTC: Les modifications sont inversées et tout revient à la normale.
Bien sûr, tout au long de l'incident, le réseau de données CloudFlare a continué à fonctionner: le trafic de sites Web et de services protégés n'a jamais été affecté: seule la plate-forme de gestion était hors combat.
Via | Cloudflare
