AccueilActualités informatiqueLa panne de Facebook et ses conséquences inattendues

La panne de Facebook et ses conséquences inattendues

Pour certains utilisateurs, la panne de Facebook du 4 octobre 2021 est passée inaperçue ; elle n’a duré que six heures. Mais pour beaucoup des 3,5 milliards d’utilisateurs de Facebook, ces six heures ont été longues et ont eu des conséquences parfois inattendues.

En une demi-heure, tous les routeurs et serveurs essentiels de l’entreprise ont disparu les uns après les autres, et avec eux le réseau social de Facebook, ses sites web et les services Messenger, WhatsApp et Instagram. Certains spécialistes du réseau ont rapidement pensé qu’il devait s’agir d’une erreur de configuration et sont restés calmes.

Mais pour de nombreux utilisateurs qui se connectent ailleurs sur Internet exclusivement via leurs identifiants Facebook, de nombreux services Internet qui sont en fait indépendants de Facebook étaient inaccessibles. Les entreprises du monde entier qui communiquent habituellement avec leurs clients via Facebook ont subi une perte de revenus.

« C’est une erreur qui nécessite un très haut niveau d’expertise ».

Mark Zuckerberg, fondateur et directeur général de Facebook, a perdu 6 à 7 milliards de dollars (5 à 6 milliards d’euros) lorsque l’action de son groupe s’est effondrée sur les marchés boursiers, selon les estimations du magazine d’information Bloomberg. Par la suite, Zuckerberg ne valait plus que 120 milliards de dollars. Par la suite, les clients voudront peut-être reprocher à Facebook de ne pas diffuser de publicités, sans parler de la perte d’image.

En outre, une grêle de moqueries et de réprimandes s’est abattue sur les experts en sécurité. Par exemple Steve Weis, spécialiste de la sécurité et ancien employé de Facebook, a publié une visualisation du processus de fermeture d’environ une demi-heure avec des sons de saxophone agités de la chanson Yakety Sax, qui accompagnait autrefois de nombreux sketches de Benny Hill. Et Phillip Hallam-Baker, spécialiste de la cryptographie et auteur de spécifications de réseau, a tweeté avec suffisance : « Il s’agit d’une erreur qui requiert un très haut niveau d’expertise ».

Pour certains concurrents, la panne a rincé les clients. De nombreux utilisateurs de Facebook se sont tournés vers d’autres moyens de communication pour les remplacer. Une augmentation considérable du trafic SMS et une augmentation des utilisateurs passant à des messageries telles que Signal et Discord sont documentées.

À la suite de cette panne, les employés de Facebook ont perdu leur accès aux outils internes, y compris ceux qu’ils utilisent pour résoudre ces problèmes. Il s’agit notamment des communications électroniques internes de Facebook et des badges d’accès des employés. Certains rapports suggèrent que le siège de Facebook n’a pas été en mesure d’agir.

Sommaire

Il y a également eu des dommages collatéraux. Cloudflare, l’opérateur du service mondial de résolution accessible sous l’adresse IP 1.1.1.1, a signalé que le nombre de requêtes DNS avait été multiplié par 30. L’explication est évidente : tous les services internet reposent sur la résolution des noms de domaine en adresses IP afin de contacter les serveurs. Si vous lancez Facebook’s Messenger, il demande au résolveur configuré sous quelle adresse IP le serveur correspondant est adressé. S’il ne reçoit pas de réponse dans les quelques secondes qui suivent, il répète sa demande. Selon la programmation, cela peut également se produire à des intervalles de plus en plus courts, ce qui augmente encore la fréquence des demandes, tout comme les utilisateurs impatients qui ne cessent de redémarrer leurs applications, supposant que la panne se trouve dans le smartphone.

Cloudflare affirme avoir bien géré l’augmentation de la charge et avoir répondu à de nombreuses demandes dans un délai raisonnable (10 ms maximum). Mais les petits résolveurs peuvent avoir cédé sous la charge accrue, de sorte qu’ils n’ont pu répondre que lentement aux requêtes DNS vers des destinations arbitraires.

Pour l’équipe de réparation de Facebook, les conséquences ont été pires, car les serveurs DNS internes ont également cessé de répondre. Cela leur a posé des problèmes supplémentaires. Selon le New York Times, certains administrateurs se sont rendus dans un centre de données à Santa Clara, en Californie, pour tenter une « réinitialisation manuelle » des serveurs. Mais ils n’ont même pas pu entrer dans le bâtiment, car Facebook utilise un contrôle d’accès basé sur Internet qui ne fonctionne que lorsque ses propres serveurs DNS sont accessibles.

Facebook gardera vraisemblablement pour lui la manière dont il a finalement réussi à éliminer l’erreur. Mais il semble plus important d’en décrire les causes, car tous les administrateurs de réseaux d’entreprises et de particuliers veulent les éviter.

Facebook est silencieux sur la cause exacte. On peut toutefois supposer qu’elle a commencé par une erreur de fonctionnement, une commande erronée dans un outil de configuration que les opérateurs de réseau et les grands fournisseurs de contenu utilisent pour annoncer et retirer les routes vers leurs réseaux à partir d’autres sous-réseaux de l’internet, selon les besoins (Border Gateway Protocol, BGP). Santosh Janardhan, vice-président chargé de l’infrastructure chez Facebook, écrit dans un billet de blog que la commande n’était en fait destinée qu’à mesurer la capacité du backbone mondial.

Au lieu de cela, le bug dans la commande a glissé à travers. Puis est apparue une erreur inconnue jusqu’alors dans un outil d’audit : celui-ci aurait dû reconnaître l’erreur de fonctionnement et arrêter la commande fatale, mais il lui a laissé le champ libre. Facebook décrit les conséquences comme suit : « Pendant la panne, l’ensemble du réseau fédérateur de Facebook a été arrêté. En conséquence, tous les sites se sont déclarés défectueux et ont retiré leurs annonces BGP. »

Cela devrait correspondre à la première demi-heure pendant laquelle toutes les routes vers les serveurs et routeurs de Facebook ont été supprimées les unes après les autres. Certains administrateurs de réseau ont visualisé ce processus à l’aide d’outils tels que BGPlay de l’administration du réseau européen RIPE, car divers services web enregistrent publiquement les processus de gestion des routes BGP. Il est ainsi facile de comprendre comment la commande a progressivement supprimé toutes les publicités Facebook.

La fermeture des centres de données était déjà un drame, mais à cela s’ajoutait une erreur conceptuelle : contrairement à ce que recommandent les spécialistes, l’entreprise n’utilise que ses propres serveurs DNS pour résoudre ses propres domaines, et uniquement dans son propre réseau (serveurs DNS faisant autorité). Ceux-ci sont configurés de telle sorte qu’ils retirent également leurs annonces BGP si leurs propres centres de données ne répondent pas. Cela ressemble à une mesure de précaution contre les attaques de l’extérieur. Mais le résultat a été qu’aucun résolveur dans le monde ne pouvait résoudre les requêtes DNS pour les domaines Facebook ; les serveurs DNS faisant autorité de Facebook, qui étaient censés fournir les informations aux résolveurs, étaient maintenant absents.

Cela a exacerbé les difficultés de Facebook à reconnaître les connexions en premier lieu, car les outils d’analyse et de réparation reposent également sur une résolution DNS fonctionnelle, tout comme les systèmes de contrôle d’accès susmentionnés. Facebook ne le décrit que superficiellement : « Cela a pris du temps, car ces installations sont conçues dans un souci de haute sécurité physique. Il est difficile d’y pénétrer, et une fois qu’on y est, les serveurs et les routeurs sont conçus pour être difficiles à modifier. »

On aimerait en savoir plus sur cet événement, car par rapport à la description (floue) du niveau de sécurité, une panne de six heures semble plutôt courte. Tout compte fait, Facebook semble s’en être tiré à bon compte. Toutefois, cela peut aussi être dû à une reprise bien pensée des services. Après que les administrateurs aient réussi à réactiver le réseau fédérateur, les centres de données ont dû être réactivés. Mais il s’agit d’un acte délicat : selon Facebook, certains des centres de données consomment des « dizaines de mégawatts » en fonctionnement normal, mais lorsque tous les composants sont allumés en même temps, le courant d’appel peut faire sauter le fusible principal. Ainsi, par exemple, les processus de démarrage peuvent échouer et entraîner des erreurs sur les disques durs. Au moins, Facebook a été préparé à cette situation par des tests de résistance antérieurs et n’a repris ses activités que progressivement.

Grâce à des outils en ligne tels que BGPlay de l’administration européenne des adresses IP RIPE, il est également possible de visualiser rétrospectivement comment les serveurs et les routeurs de Facebook ont progressivement disparu d’Internet.

(Image : RIPE)

Quatre jours plus tard, cependant, une autre panne s’est produite, affectant à nouveau plusieurs des services du groupe. Facebook a réparé cette panne en deux heures, mais n’a pas donné de raisons.

Plus d’informations

  • Alun Davies, RIPE Labs : Facebook en panne dans BGPlay
  • Facebook, Santosh Janardhan : mise à jour concernant la panne du 4 octobre
  • Facebook, Santosh Janardhan : plus de détails sur la panne du 4 octobre.
  • DNSLytics, Résumé pour as32934 : BGP ads from Facebook
  • Visualisation de BGPlay : retrait de route entre 15:43UTC et 15:54UTC, vitesse ~10x.
  • Moquerie de Steve Weis (spécialiste de la sécurité et ancien employé de Facebook)
  • Pratique sur les routes BGP : David Bombal, scripts Python, dont bgp-dos-reset-neighbors.py et bgp-remove-route.py
  • Le retour des SMS grâce à la panne de Facebook
  • Facebook : Encore des problèmes – accessibilité limitée
  • Après la perturbation de Facebook : le délégué à la protection des données de Hambourg appelle à un renforcement de la réglementation
  • Politique d’édition : les conséquences des scandales de Facebook

Au moins, Santosh Janardhan promet dans un billet de blog que l’entreprise tirera les leçons de cet incident. La plupart des changements ne seront pas divulgués. Mais nous verrons si l’entreprise fait comme beaucoup d’autres et met en place des serveurs DNS de secours (DNS secondaire faisant autorité hors site). Il y a suffisamment de fournisseurs, même pour les petites entreprises. D’autres exemples sont UltraDNS, Cloudflare ou GoDaddy.

c’est le 23/2021

Dans le c’t 23/21, vous apprendrez les astuces des hackers. Avec les bons outils, vous pouvez craquer des mots de passe oubliés, trouver des failles de sécurité dans votre réseau et décrypter des documents Word. Nous analysons également ce qui rend WordPress si unique et nous vous aidons à vous lancer et à trouver des thèmes et des plug-ins adaptés. Vous trouverez le c’t 23/21 à partir du 22 octobre dans la boutique et dans les kiosques à journaux bien achalandés.

Plus d'articles