Facebook: Problême d'employé,de serveurs DNS ,ou hacké a 15:40 UTC ? Qui a changer la config du serveur DNS ? Hein ???
C'est
la panne la plus importante jamais observée qui a touché Facebook et
ses réseaux sociaux et services de messagerie comme WhatsApp et
Instagram ainsi que leurs 3,5 milliards d'utilisateurs.
7h de panne mondiale, un coût de 6 milliards de dollars... La panne
géante pour Facebook, Messenger, Whatsapp et Instagram est désormais
terminée ce mardi matin.
Les réseaux sociaux et messageries du géant californien Facebook sont
restés inaccessibles une partie de la journée de lundi avant un retour à
la normale aux environs de minuit. Un nouveau revers pour la firme de
Mark Zuckerberg.
Ce serait plus spécifiquement, les résolveurs DNS tels que Cloudflare-Services qui convertissent ces noms de domaine en adresses IP - ont vu autant que le double du trafic habituel, car les gens continuent à tenter de charger Facebook, Instagram et WhatsApp en vain. Ces demandes ne suffisent pas pour submerger le système, mais la surtension est un rappel de la manière interdépendante et parfois fragile, Internet est vraiment.
« Facebook ne peut pas être en panne, n'est-ce pas ? »,
avons-nous pensé pendant une seconde.
Aujourd'hui 041021, à 15:51 UTC, nous avons ouvert un incident interne intitulé "Facebook DNS lookup return SERVFAIL" car nous craignions que quelque chose n'allait pas avec notre résolveur DNS 1.1.1.1. Mais alors que nous étions sur le point de publier sur notre page de statut public, nous avons réalisé que quelque chose de plus grave se passait.
Les médias sociaux ont rapidement pris feu, rapportant ce que nos ingénieurs ont rapidement confirmé également. Facebook et ses services affiliés WhatsApp et Instagram étaient, en fait, tous en panne. Leurs noms DNS ont cessé de se résoudre et leurs adresses IP d'infrastructure étaient inaccessibles.
C'était comme si quelqu'un avait "tiré les câbles" de leurs centres de données d'un seul coup et les avait déconnectés d'Internet.
Ce n'était pas un problème DNS en soi, mais l'échec du DNS était le premier symptôme que nous avions vu d'une panne plus importante de Facebook.
Comment est-ce possible ?
Mise à jour de Facebook
Facebook a maintenant publié un article de blog donnant quelques détails sur ce qui s'est passé en interne.
En externe, nous avons vu les problèmes BGP et DNS décrits dans cet article, mais le problème a en fait commencé par un changement de configuration qui a affecté l'ensemble du backbone interne. Cela s'est répercuté sur la disparition de Facebook et d'autres propriétés et le personnel interne à Facebook a du mal à rétablir le service.
Facebook a publié un autre article de blog avec beaucoup plus de détails sur ce qui s'est passé. Vous pouvez lire ce post pour la vue intérieure et ce post pour la vue extérieure.
Passons maintenant à ce que nous avons vu de l'extérieur.
Rencontrez BGP
BGP signifie Border Gateway Protocol. C'est un mécanisme permettant d'échanger des informations de routage entre des systèmes autonomes (AS) sur Internet. Les gros routeurs qui font fonctionner Internet ont d'énormes listes constamment mises à jour des routes possibles qui peuvent être utilisées pour livrer chaque paquet réseau à leurs destinations finales.
Sans BGP, les routeurs Internet ne sauraient pas quoi faire et Internet ne fonctionnerait pas.
Internet est littéralement un réseau de réseaux, et il est lié par BGP. BGP permet à un réseau (par exemple Facebook) d'annoncer sa présence à d'autres réseaux qui forment Internet. Au moment où nous écrivons, Facebook ne fait pas de publicité pour sa présence, les FAI et autres réseaux ne peuvent pas trouver le réseau de Facebook et il est donc indisponible.
Les réseaux individuels ont chacun un ASN : un numéro de système autonome. Un système autonome (AS) est un réseau individuel avec une politique de routage interne unifiée.
Un AS peut générer des préfixes (disons qu'il contrôle un groupe d'adresses IP), ainsi que des préfixes de transit (disons qu'il sait comment atteindre des groupes spécifiques d'adresses IP). L'ASN de Cloudflare est AS13335.(Pourtant le 26 septembre ,une fausse page facebook circulait par un lien dans messenger a cette adresse https://l1x.eu) Chaque ASN doit annoncer ses routes de préfixe vers Internet en utilisant BGP ; sinon, personne ne saura comment se connecter et où nous trouver.
Notre centre d'apprentissage a un bon aperçu de ce que sont BGP et ASN et comment ils fonctionnent.
Dans ce schéma simplifié, vous pouvez voir six systèmes autonomes sur Internet et deux routes possibles qu'un paquet peut utiliser pour aller du début à la fin.
AS1 → AS2 → AS3 étant le plus rapide, et AS1 → AS6 → AS5 → AS4 → AS3 étant le plus lent, mais cela peut être utilisé si le premier échoue.
À 15h58 UTC, nous avons remarqué que Facebook avait cessé d'annoncer les routes vers leurs préfixes DNS.
Cela signifiait qu'au moins les serveurs DNS de Facebook n'étaient pas disponibles. À cause de cela, le résolveur DNS 1.1.1.1 de Cloudflare ne pouvait plus répondre aux requêtes demandant l'adresse IP de facebook.com.
routes-vues> afficher l'ip bgp 185.89.218.0/23
% Réseau non dans le tableau
routes-vues>
route-vues> afficher l'ip bgp 129.134.30.0/23
% Réseau non dans le tableau
routes-vues>
Pendant ce temps, d'autres adresses IP Facebook restaient routées mais n'étaient pas particulièrement utiles car sans DNS, Facebook et les services associés étaient effectivement indisponibles :
route-vues> afficher l'ip bgp 129.134.30.0
Entrée de table de routage BGP pour 129.134.0.0/17, version 1025798334
Chemins : (24 disponibles, meilleur n°14, table par défaut)
Non annoncé à aucun pair
Rafraîchir l'époque 2
3303 6453 32934
217.192.89.50 à 217.192.89.50 (138.187.128.158)
Origine IGP, localpref 100, valide, externe
Communauté : 3303 : 1004 3303 : 1006 3303 : 3075 6453 : 3000 6453 : 3400 6453 : 3402
chemin 7FE1408ED9C8 État RPKI introuvable
rx pathid : 0, tx pathid : 0
Rafraîchir l'époque 1
routes-vues>
Nous gardons une trace de toutes les mises à jour et annonces BGP que nous voyons dans notre réseau mondial. À notre échelle, les données que nous collectons nous donnent une idée de la façon dont Internet est connecté et où le trafic est censé circuler depuis et vers partout sur la planète.
Un message BGP UPDATE informe un routeur de toute modification que vous avez apportée à une annonce de préfixe ou retire entièrement le préfixe. Nous pouvons clairement le voir dans le nombre de mises à jour que nous avons reçues de Facebook lors de la vérification de notre base de données BGP de séries chronologiques.
Normalement, ce graphique est assez calme : Facebook n'apporte pas beaucoup de changements à son réseau minute par minute.
Mais vers 15h40 UTC, nous avons vu un pic de changements de routage de Facebook. C'est alors que les ennuis ont commencé.
Si nous divisons cette vue par les annonces d'itinéraires et les retraits, nous obtenons une même meilleure idée de ce qui s'est passé.
Des routes ont été retirées, les serveurs DNS de Facebook ont été déconnectés et une minute après que le problème se soit produit, les ingénieurs de Cloudflare étaient dans une pièce se demandant pourquoi 1.1.1.1 ne pouvait pas résoudre facebook.com et s'inquiétant qu'il s'agisse d'un problème avec nos systèmes.
Avec ces retraits, Facebook et ses sites se sont effectivement déconnectés d'Internet.
DNS est affecté
En conséquence directe de cela, les résolveurs DNS du monde entier ont cessé de résoudre leurs noms de domaine.
➜ ~ creuser @1.1.1.1 facebook.com
;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322
;facebook.com. DANS UN
➜ ~ creuser @ 1.1.1.1 whatsapp.com
;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322
;whatsapp.com. DANS UN
➜ ~ creuser @8.8.8.8 facebook.com
;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322
;facebook.com. DANS UN
➜ ~ creuser @ 8.8.8.8 whatsapp.com
;; ->>HEADER<<- code opération : QUERY, statut : SERVFAIL, id : 31322
;whatsapp.com.
DANS UN
Cela se produit parce que le DNS, comme de nombreux autres systèmes sur Internet, possède également son mécanisme de routage.
Lorsque quelqu'un tape l'URL https://facebook.com dans le navigateur, le résolveur DNS, responsable de la traduction des noms de domaine en adresses IP réelles auxquelles se connecter, vérifie d'abord s'il a quelque chose dans son cache et l'utilise. Sinon, il essaie de récupérer la réponse des serveurs de noms de domaine, généralement hébergés par l'entité qui en est propriétaire.
Si les serveurs de noms sont inaccessibles ou ne répondent pas pour une autre raison, un SERVFAIL est renvoyé et le navigateur envoie une erreur à l'utilisateur.
Encore une fois, notre centre d'apprentissage fournit une bonne explication sur le fonctionnement du DNS.
En raison de l'arrêt de Facebook d'annoncer leurs routes de préfixe DNS via BGP, nos résolveurs DNS et tous les autres n'avaient aucun moyen de se connecter à leurs serveurs de noms. Par conséquent, 1.1.1.1, 8.8.8.8 et d'autres principaux résolveurs DNS publics ont commencé à émettre (et à mettre en cache) des réponses SERVFAIL.
Mais ce n'est pas tout. Maintenant, le comportement humain et la logique d'application entrent en jeu et provoquent un autre effet exponentiel. Un tsunami de trafic DNS supplémentaire s'ensuit.
Cela s'est produit en partie parce que les applications n'accepteront pas une erreur pour une réponse et commenceront à réessayer, parfois de manière agressive, et en partie parce que les utilisateurs finaux ne prendront pas non plus une erreur pour une réponse et commenceront à recharger les pages, ou à tuer et relancer leur applications, parfois aussi agressivement.
Voici l'augmentation du trafic (en nombre de requêtes) que nous avons constaté sur 1.1.1.1 :
Alors maintenant, parce que Facebook et leurs sites sont si grands, nous avons des résolveurs DNS dans le monde entier qui traitent 30 fois plus de requêtes que d'habitude et peuvent causer des problèmes de latence et de délai d'attente à d'autres plates-formes.
Heureusement, 1.1.1.1 a été conçu pour être gratuit, privé, rapide (comme peut en témoigner le moniteur DNS indépendant DNSPerf) et évolutif, et nous avons pu continuer à servir nos utilisateurs avec un impact minimal.
La grande majorité de nos requêtes DNS ont continué à se résoudre en moins de 10 ms.
Dans le même temps, une fraction minimale des centiles p95 et p99 a vu ses temps de réponse augmenter, probablement en raison des TTL expirés devant recourir aux serveurs de noms Facebook et au délai d'attente.
La limite de temporisation DNS de 10 secondes est bien connue des ingénieurs.
Impact sur d'autres services
Les gens recherchent des alternatives et veulent en savoir plus ou discuter de ce qui se passe. Lorsque Facebook est devenu inaccessible, nous avons commencé à voir une augmentation des requêtes DNS vers Twitter, Signal et d'autres plateformes de messagerie et de médias sociaux.
Nous pouvons également voir un autre effet secondaire de cette inaccessibilité dans notre trafic WARP vers et depuis l'ASN 32934 affecté de Facebook.
Ce graphique montre comment le trafic est passé de 15:45 UTC à 16:45 UTC par rapport à trois heures auparavant dans chaque pays. Partout dans le monde, le trafic WARP vers et depuis le réseau de Facebook a tout simplement disparu.
L'Internet
Les événements d'aujourd'hui nous rappellent en douceur qu'Internet est un système très complexe et interdépendant de millions de systèmes et de protocoles fonctionnant ensemble. Cette confiance, cette normalisation et cette coopération entre les entités sont au cœur de son fonctionnement pour près de cinq milliards d'utilisateurs actifs dans le monde.
Mettre à jour
Vers 21h00 UTC, nous avons vu une activité BGP renouvelée du réseau de Facebook qui a culminé à 21h17 UTC.
Ce graphique montre la disponibilité du nom DNS « facebook.com » sur le résolveur DNS de Cloudflare 1.1.1.1. Il a cessé d'être disponible vers 15h50 UTC et est revenu à 21h20 UTC.
Il ne fait aucun doute que les services Facebook, WhatsApp et Instagram mettront plus de temps à se mettre en ligne, mais à 21h28 UTC, Facebook semble être reconnecté à l'Internet mondial et le DNS fonctionne à nouveau.
Note:
Les prises de paroles ont leur importance dans ces moments-là, et celle
de John Graham-Cumming, le CTO de l'hébergeur Cloudflare, est intéressante. Le spécialiste explique avoir remarqué, quelques minutes
avant que les DNS de Facebook ne tombent, que ces derniers avaient subi
un nombre très important de modifications des routeurs BGP. Pour
schématiser, ces routeurs permettent à la machine de fonctionner. Une
erreur humaine pourrait être la cause de l'incident, mais cela reste
évidemment à confirmer.
Entre-temps, l'utilisateur de Reddit u/ramenporn, qui prétendait être un employé de Facebook travaillant à ramener le réseau social d'entre les morts, a signalé, avant de supprimer son compte et ses messages, que "les services DNS pour FB ont été affectés et cela est probablement un symptôme du problème réel, et c'est que l'appairage BGP avec les routeurs d'appairage Facebook a baissé, très probablement en raison d'un changement de configuration qui est entré en vigueur peu de temps avant les pannes (a commencé à environ 1540 UTC)."Selon, Ramenporn de Reddit,il a également déclaré qu'il ne s'agissait pas d'une attaque, mais d'un changement de configuration erroné effectué via une interface Web. Ce qui pue vraiment - et pourquoi Facebook est toujours en panne quelques heures plus tard - c'est que puisque BGP et DNS sont en panne, la "connexion au monde extérieur est en panne, l'accès à distance à ces outils n'existe plus, donc la procédure d'urgence est d'obtenir un accès physique aux routeurs de peering et de faire toute la configuration localement." Bien entendu, les techniciens sur site ne savent pas comment faire et les administrateurs réseau seniors ne sont pas sur place. C'est, en bref, un gros gâchis.
Selon Jean-Loup Delmas: Une autre affaire est en cours en parallèle, concernant une prétendue
fuite des données de 1,5 milliard de profils Facebook. Ces dernières
seraient en vente sur le darkweb, à la suite d’une cyberattaque
effectuée peu de temps avant le bug de Facebook, mais qui n’aurait donc
rien à voir avec lui, constituant une simple coïncidence. Néanmoins, il
faut là aussi avancer avec prudence. Une telle récolte de données serait
inédite, et consisterait en un véritable exploit. Rien ne dit que cette
rumeur est crédible et que les données ont bel et bien été volées.Mais une simple attaque XSS est plausible !
Car la fausse page facebook n'avait pas l'adresse internet facebook.com!!!
C'est frort probable une attaque script intersites ?
Le script intersites (XSS)
est un exploit dans lequel l'attaquant attache du code à un site Web
légitime qui s'exécutera lorsque la victime chargera le site Web. Ce
code malveillant peut être inséré de plusieurs manières. Le plus
souvent, il est soit ajouté à la fin d'une URL, soit publié directement
sur une page qui affiche le contenu généré par l'utilisateur. En termes
plus techniques, le cross-site scripting est une attaque par injection
de code côté client.
Attaque de script intersites
Qu'est-ce que le code côté client ?
Le
code côté client est un code JavaScript qui s'exécute sur la machine
d'un utilisateur. En termes de sites Web, le code côté client est
généralement un code exécuté par le navigateur Web une fois que le
navigateur a chargé une page Web. Cela contraste avec le code côté
serveur, qui est exécuté sur le serveur Web de l'hôte
Le code qui s'exécute côté client est très populaire dans le
développement Web moderne et est utilisé sur la plupart des sites Web
modernes. Étant donné que le code intersites est un élément essentiel du
Web moderne, les scripts intersites sont devenus l'une des
vulnérabilités de cybersécurité les plus fréquemment signalées, et les attaques de scripts intersites ont frappé des sites majeurs tels que YouTube, Facebook et Twitter.
Même problême en Mars 2021: Durée 1 hr !!!
Sur Downdetector,
près de 20 000 signalements ont été recensés en France, et plus de
130 000 aux Etats-Unis. Les internautes ont également manifesté leur
agacement sur Twitter avec les hashtags #whatsappdown et #instagramdown.
Un peu moins d’une heure après, la situation est revenue progressivement à la normale sur les différentes applications. «Des utilisateurs ont eu des difficultés à accéder à certains services Facebook à cause d’un problème technique», a confirmé auprès de l’AFP un porte-parole du groupe, qui chapeaute les trois applications, avant d’ajouter : «Nous avons résolu le problème pour tout le monde et nous nous excusons pour la gêne occasionnée.»
Selon FB: Des changements de configuration sur les routeurs backbone ?
Pour expliquer la panne générale rencontrée, Facebook évoque des changements de configuration sur les routeurs backbone qui coordonnent le trafic réseau entre les centres de données. Ils auraient causé des problèmes de communication, et par conséquent entraîné une perturbation du trafic réseau, amenant inévitablement à l’arrêt des services.Le serveur AS13335 serait situer au Kansas dans le fond de l'eau a 42 pieds dans le réservoir cheney,probablement compliqué a faire des manipulations en hardware a ce niveau la !!!
Les ingénieurs de facebook nous expliquent qu'Au cours de l’un de ces travaux de maintenance de routine, une commande a été émise avec l’intention d’évaluer la disponibilité de la capacité du réseau fédérateur mondial,
ce qui a involontairement interrompu toutes les connexions de notre
réseau fédérateur(relier au gros serveur backbone AS32934), déconnectant efficacement les centres de données
Facebook dans le monde. Nos systèmes sont conçus pour auditer des
commandes comme celles-ci afin d’éviter de telles erreurs, mais un bogue
dans cet outil d’audit l’a empêché d’arrêter correctement la commande. Un bogue ;-) ???????
Le DNS vous indique où vous rendre, et BGP vous précise comment
Sauf
que pour pouvoir utiliser le DNS, il faut, comme pour tout type de
serveur, aussi savoir comment s’y rendre. Or, sans BGP, trouver son
chemin était justement impossible. Pour reprendre la métaphore de
l’annuaire, c’est un peu comme si ce dernier ne se trouvait pas chez
vous mais dans la maison d’un ami. Sans BGP, il était déjà impossible
d’exploiter les informations fournies par l’annuaire, mais il était
aussi tout bonnement impossible de même aller le chercher.
Qu’est-ce qui a déclenché la panne en premier lieu ?
On
ne sait pas encore. L’enchaînement des faits n’est pas encore
totalement connu à ce stade, mais peu avant 18 heures, lundi, Facebook a
procédé à une mise à jour BGP (la « carte collaborative », donc) en
expliquant que certains chemins menant à ses DNS n’étaient plus valides.
Il a été soudainement très difficile de joindre ces serveurs, ce qui a
bloqué une grande partie des connexions. Facebook a aussi, plus
largement, déclaré comme inutilisables l’ensemble des chemins
informatiques menant à ses serveurs, se coupant de fait du reste de
l’Internet.
REF.:
