Panne Cloudflare : l’explication de ses causes et de ses remèdes

Le contexte technique

Ces serveurs proxys forment un réseau CDN (Content Delivery Network). Ce sont des machines installées dans des datacenters de proximité qui répliquent les contenus les plus demandés des grands services sur Internet. Ainsi, ces contenus sont présentés plus rapidement aux utilisateurs que s’ils avaient dû parcourir des centaines de kilomètres de fibres jusqu’aux services d’origine.

Lorsque les contenus répliqués ne suffisent pas, les serveurs proxys retransmettent la requête de l’utilisateur vers le service d’origine. Cela dit, le CDN de CloudFlare a une dimension de cybersécurité. Il protège les services web d’origine contre les cyberattaques par déni de service (DDoS), en faisant office d’antichambre pour les requêtes qui leur sont destinées.

Cette antichambre est même particulièrement pointue, car elle est capable d’identifier une variété toujours plus grande de requêtes automatisées. Celles-ci ne sont pas nécessairement malveillantes. Certaines sont des sondes – des bots – envoyées par des moteurs de recherche Internet pour indexer les contenus des services web. Chaque cas est traité par un jeu de règles.

Ce jeu de règles est un fichier qui est mis à jour toutes les cinq minutes depuis le datacenter principal de Cloudflare aux USA et qui est distribué dans la foulée à tous ses serveurs proxys dans le monde.

La panne

La panne des serveurs proxys de CloudFlare reposait sur la distribution de versions corrompues de ce fichier de règles. La corruption était en l’occurrence que le fichier avait - juste - une taille deux fois trop importante. Cette simple anomalie a suffi pour rendre les proxys inopérants, ceux-ci se bloquant sur l’affichage d’un message d’erreur, visible dans le navigateur de chaque utilisateur. Dans le jargon de Cloudflare, il s’agit d’une erreur HTTP 5xx.

Ce blocage ne dure normalement que le temps de recevoir une nouvelle version corrigée du fichier de règles. Hélas, les ingénieurs de Cloudflare mettront près de trois heures à identifier la source du problème et à comprendre qu’il suffisait de réparer la manière dont était généré ledit fichier. « Nous avions initialement pensé qu’il s’agissait d’une cyberattaque de type DDoS de très grande envergure », s’excuse le fournisseur dans son billet de blog.

La panne a commencé à 11h20 UTC (12h20 en France), sa cause a été résolue à 14h30 UTC (15h30) et il faudra encore attendre jusqu’à 17h06 UTC (18h06) pour que 100% des proxys Cloudflare se remettent à fonctionner normalement.

L’origine du problème

À l’origine du problème, il y a la volonté de Cloudflare d’améliorer la sécurité sur son cluster de serveurs qui centralise les données nécessaires à la génération automatique du fichier distribué. Ce cluster ne sert pas qu’à cela. Il contient plusieurs bases de données ClickHouse, elles-mêmes fragmentées en plusieurs tableaux de données. Le fichier à distribuer aux proxys est constitué d’un amalgame de données issues de différents tableaux, tous gérés par une base de données appelée r0.

Jusque-là, les différentes applications de Cloudflare utilisaient toutes le même compte utilisateur pour interroger toutes les bases et tous leurs tableaux sous-jacents. En l’occurrence, ce compte ne donnait accès qu’à une base de données générale appelée default et celle-ci pointait, entre autres, vers les données contenues dans r0.

Mais, ce mardi 18 novembre, à 11h05 UTC, Cloudflare a décidé d’attribuer un compte utilisateur différent à chaque application. Celle qui génère le fichier de règles accéderait désormais directement à la base r0 sans devoir passer par la base default. « L’enjeu était d’éviter qu’une mauvaise requête d’une application affecte les autres applications », se justifie le fournisseur dans son billet de blog.

Sauf que la requête habituelle de génération du fichier de règles n’a pas été modifiée pour tirer explicitement ses informations de r0. Résultat, son exécution a généré un fichier avec les données issues de r0 et les données portant le même nom dans la base default. D’où un fichier deux fois trop grand, qui contient toutes les règles en double.

Lorsque le fichier arrive ensuite sur un serveur proxy, celui-ci le met dans une zone proprement délimitée de sa mémoire. « Cette précaution sert à éviter le risque qu’un module occupe par erreur trop de RAM sur le proxy. Accessoirement, préallouer une zone mémoire à une tâche est généralement une bonne idée pour optimiser les performances », s’excuse encode le fournisseur dans son billet de blog.

Comme le fichier en surpoids ne rentre pas dans le carcan prévu par le système d’exploitation du Proxy, ce dernier génère une alerte, laquelle bloque l’exécution du code censé exécuter les règles. Ce blocage est identifié comme une anomalie dans la pile logicielle et, en attendant qu’elle disparaisse, le serveur de gestion des requêtes produit un message d’erreur HTTP 5xx dans la fenêtre du navigateur de l’utilisateur, en lieu et place du service auquel il voulait accéder.   

Comment le problème s’est aggravé

Par-dessus ces problèmes techniques de base, ce sont greffés des problèmes d’échelle. Tout d’abord, celui qui a empêché Cloudflare de correctement identifier la source du problème.

« Ce qui était particulier au début de la panne, c’est que la remontée des taux d’erreurs HTTP 5xx fluctuait entre des pics de signalement et de courts rétablissements. Il s’agit d’un comportement très inhabituel dans le cas d’une erreur interne », dit le billet de blog.  

Explication : comme les bases de données ClickHouse sont sur un cluster de plusieurs serveurs, l’attribution d’un nouveau compte utilisateur ne s’est pas faite instantanément, mais serveur après serveur. Si bien qu’il y a eu un moment, de 11h30 UTC à 13h00 UTC, durant lequel la génération du fichier était tantôt faite par un serveur mis à jour et lisant de manière incorrecte deux bases de données, tantôt par un serveur pas encore à jour, mais lisant correctement une seule base de données.

« Un autre symptôme a achevé de nous faire croire qu’il s’agissait d’une cyberattaque : il se trouve que la page de notre console de monitoring, qui n’est pas exécutée sur notre réseau, était aussi hors service, suggérant une cyberattaque coordonnée. Alors qu’il s’agissait en réalité d’une pure coïncidence », se désole le billet de blog.

Ensuite, les serveurs proxys ne sont pas installés comme un front commun pour répondre aux requêtes, mais déployés en grappes arborescentes. C’est-à-dire que la lecture ou l’absence d’une règle conditionne l’activation de différents firewalls dans un certain ordre. Lorsque le bon fichier de règles finit par arriver, il faut encore du temps pour que les proxys corrigent les erreurs de configuration que leur panne a engendrée.

« Au fur et à mesure qu'une demande transite par le proxy principal, nous exécutons les différents produits de sécurité et de performance disponibles dans notre réseau. Le proxy applique la configuration et les paramètres uniques de chacun de nos clients [les services d’origine, N.D.R.]. Cela va de l'application des règles WAF et de la protection contre le DDoS, au routage du trafic vers différentes plateformes », explique le billet de blog.

Et puis, les serveurs proxys de Cloudflare ne sont pas tous identiques. Certains étaient équipés de la nouvelle version du système, d’autres de l’ancienne. Sur l’ancienne, pas d’erreur HTTP 5xx bloquant les utilisateurs, mais des métriques faussées par l’absence d’un fichier de règles et qui préviennent les services d’origine de bloquer tout le trafic à cause d’une suspicion par défaut de cyberattaque. C’est-à-dire qu’il a fallu aussi que Cloudflare appelle ses clients pour leur demander de redémarrer leurs serveurs.

Pour l’avenir, Cloudflare entend prendre des mesures contre un tel incident. En substance, les proxys n’accepteront plus aussi facilement de remplacer leur ancien fichier de règles par un nouveau.

« Une panne comme aujourd'hui est inacceptable. Nous avons conçu nos systèmes pour qu'ils soient très résistants aux pannes, afin de garantir que le trafic continuera toujours à circuler. Lorsque nous avons eu des pannes dans le passé, cela nous a toujours amenés à construire de nouveaux systèmes plus résilients », conclut le billet de blog.