Netzwerkadmins sind die ersten, die der Ausfall einer großen Plattform trifft. Als Facebook weg war, gingen US-Administratoren sofort auf Spurensuche.
War es ein Angriff, ein Inside Job oder doch nur ein Konfigurationsfehler? Unmittelbar nach dem weltweiten Ausfall von Facebooks Systemen begannen Netzwerkadministratoren in den USA mit der Fehlersuche. Über den Auslöser dafür, dass sich das Zuckerberg-Imperium mit all seinen Diensten aus dem Netz verabschiedete, wird noch spekuliert. Was technisch passiert ist, wurde aber im Laufe des Abends immer klarer.
Fast 128.000 Nutzeranfragen bezüglich des Facebook-Ausfalls gingen bei Wholesail Networks, einem Netzdienstleister aus Seattle, am Montagnachmittag ein. Auf der Mailingliste der North American Network Operators (Nanog) warnt ein Mitarbeiter die anderen Admins: "Das dürfte eine Menge Anrufe von Kunden nach sich ziehen."
Innerhalb von Minuten trugen die Administratoren Informationen zum Schadbild zusammen und notieren: Die IP-Präfixe, die anderen Internetteilnehmern erlauben, ihre für Facebook bestimmten Anfragen in die richtige Richtung zu schicken, waren bekannt. Aber sie fehlten in den Routingtabellen der "Default Free Zone", über große Player im Internet ihre Navigationsinformationen für den Internetverkehr austauschen.
Die für die Navigation im Netz notwendigen Routen tauschen die miteinander per Peering verbundenen großen Teilnehmer ständig untereinander aus. Das können Provider, Betreiber von Rechenzentren oder auch die großen Plattformen wie Facebook sein. Als sogenannte autonome Systeme "annoncieren" sie ihre Nummern (ASN) und Routen über das Border Gateway Protocol (BGP). Facebooks Problem: Es hatte alle seine Announcements zurückgezogen – kein Anschluss unter dieser Nummer.
Damit verschwanden Facebook und alle seine Dienste sang- und klanglos von der Bildfläche des Internets – niemand kannte mehr den Weg zu Facebook. Wegen der fehlenden Routing-Informationen konnten die anderen Teilnehmer auch die von Facebook selbst gehosteten DNS-Server nicht mehr finden. Per E-Mail war Facebook ebenfalls nicht mehr zu erreichen, eine Anfrage von heise online zu den Hintergründen des Ausfalls konnte am Montagabend nicht zugestellt werden.
Facebooks Zentralisierung der eigenen Infrastruktur führte offenbar zu einer verheerenden Kettenreaktion. Auf Twitter machten Meldungen die Runde, dass Facebook-Mitarbeiter nicht mehr ins Büro konnten, weil auch die vernetzte Schließanlage nicht mehr funktionierte. Schlimmer: Die Facebook-Administratoren konnten Medienberichten zufolge nicht auf die betroffene Hardware zugreifen, weil der Remote-Zugriff ohne Routen nicht funktionierte. Zugleich sollen die Mitarbeiter im Rechenzentrum nicht die nötigen Berechtigungen und Zugangsdaten gehabt haben, um die Routingtabellen direkt vor Ort zu reparieren.
Inzwischen macht Facebook erste Angaben zu den Hintergründen des sechsstündigen Ausfalls. Demnach wurde durch einen Konfigurationsfehler der Router die interne Verbindung zwischen Facebooks Rechenzentren gekappt. "Der Fehler hat sich kaskadenartig ausgebreitet und weitere Systeme in Mitleidenschaft gezogen", erklärte ein Sprecher gegenüber heise online. "Auch interne Systeme waren betroffen, was Diagnose und Behebung des Fehlers erschwert hat." Wer da was genau fehlkonfiguriert hat, sagt Facebook bisher nicht.
(Bild: Cloudflare)
Der globale Cloud- und DNS-Dienstleister Cloudflare, der selbst einschlägige Erfahrung mit einer Router-Fehlkonfiguration hat, war bereits am frühen Montagabend auf der richtigen Spur, als ihnen im BGP erhöhte Aktivität bei den Facebook-Routen aufgefallen war. Nachdem Facebook begonnen hatte, seine Routen zurückzuziehen und Facebooks eigene DNS-Server damit vom Netz waren, lieferten auch die anderen DNS-Resolver zunehmend Fehlermeldungen für Facebook. Die wiederholten vergeblichen Nachfragen nach Facebook setzten auch andere Systeme unter Stress.
Ein interessanter Hinweis, der in weiteren Post-Mortem-Analysen noch berücksichtigt werden könnte, kam aus den Niederlanden. Facebook hatte angekündigt, dass es sich vom Austauschknoten NLIX zurückziehen werde. "Vielleicht hat jemand alle BGP-Sessions und nicht nur die mit dem NLIX beendet und jetzt kommen sie nicht an ihre Maschinen, um das wieder rückgängig zu machen", vermutete ein Teilnehmer der Nanog-Mailingliste.
Quelle: heise
War es ein Angriff, ein Inside Job oder doch nur ein Konfigurationsfehler? Unmittelbar nach dem weltweiten Ausfall von Facebooks Systemen begannen Netzwerkadministratoren in den USA mit der Fehlersuche. Über den Auslöser dafür, dass sich das Zuckerberg-Imperium mit all seinen Diensten aus dem Netz verabschiedete, wird noch spekuliert. Was technisch passiert ist, wurde aber im Laufe des Abends immer klarer.
Fast 128.000 Nutzeranfragen bezüglich des Facebook-Ausfalls gingen bei Wholesail Networks, einem Netzdienstleister aus Seattle, am Montagnachmittag ein. Auf der Mailingliste der North American Network Operators (Nanog) warnt ein Mitarbeiter die anderen Admins: "Das dürfte eine Menge Anrufe von Kunden nach sich ziehen."
Innerhalb von Minuten trugen die Administratoren Informationen zum Schadbild zusammen und notieren: Die IP-Präfixe, die anderen Internetteilnehmern erlauben, ihre für Facebook bestimmten Anfragen in die richtige Richtung zu schicken, waren bekannt. Aber sie fehlten in den Routingtabellen der "Default Free Zone", über große Player im Internet ihre Navigationsinformationen für den Internetverkehr austauschen.
Die für die Navigation im Netz notwendigen Routen tauschen die miteinander per Peering verbundenen großen Teilnehmer ständig untereinander aus. Das können Provider, Betreiber von Rechenzentren oder auch die großen Plattformen wie Facebook sein. Als sogenannte autonome Systeme "annoncieren" sie ihre Nummern (ASN) und Routen über das Border Gateway Protocol (BGP). Facebooks Problem: Es hatte alle seine Announcements zurückgezogen – kein Anschluss unter dieser Nummer.
Du musst angemeldet sein, um Bilder zu sehen.
Damit verschwanden Facebook und alle seine Dienste sang- und klanglos von der Bildfläche des Internets – niemand kannte mehr den Weg zu Facebook. Wegen der fehlenden Routing-Informationen konnten die anderen Teilnehmer auch die von Facebook selbst gehosteten DNS-Server nicht mehr finden. Per E-Mail war Facebook ebenfalls nicht mehr zu erreichen, eine Anfrage von heise online zu den Hintergründen des Ausfalls konnte am Montagabend nicht zugestellt werden.
Facebooks Zentralisierung der eigenen Infrastruktur führte offenbar zu einer verheerenden Kettenreaktion. Auf Twitter machten Meldungen die Runde, dass Facebook-Mitarbeiter nicht mehr ins Büro konnten, weil auch die vernetzte Schließanlage nicht mehr funktionierte. Schlimmer: Die Facebook-Administratoren konnten Medienberichten zufolge nicht auf die betroffene Hardware zugreifen, weil der Remote-Zugriff ohne Routen nicht funktionierte. Zugleich sollen die Mitarbeiter im Rechenzentrum nicht die nötigen Berechtigungen und Zugangsdaten gehabt haben, um die Routingtabellen direkt vor Ort zu reparieren.
Fatale Abhängigkeiten
Die Experten auf der Nanog-Liste stellen daher auch die Frage, ob es klug ist, nicht nur alle Peering-Router, sondern auch alle DNS-Server im eigenen Netz zu betreiben. Allerdings macht das nicht nur Facebook so, sondern auch andere große Unternehmen – um die Kontrolle über die eigene Infrastruktur zu behalten, merkt ein Administrator an.Inzwischen macht Facebook erste Angaben zu den Hintergründen des sechsstündigen Ausfalls. Demnach wurde durch einen Konfigurationsfehler der Router die interne Verbindung zwischen Facebooks Rechenzentren gekappt. "Der Fehler hat sich kaskadenartig ausgebreitet und weitere Systeme in Mitleidenschaft gezogen", erklärte ein Sprecher gegenüber heise online. "Auch interne Systeme waren betroffen, was Diagnose und Behebung des Fehlers erschwert hat." Wer da was genau fehlkonfiguriert hat, sagt Facebook bisher nicht.
Du musst angemeldet sein, um Bilder zu sehen.
(Bild: Cloudflare)
Der globale Cloud- und DNS-Dienstleister Cloudflare, der selbst einschlägige Erfahrung mit einer Router-Fehlkonfiguration hat, war bereits am frühen Montagabend auf der richtigen Spur, als ihnen im BGP erhöhte Aktivität bei den Facebook-Routen aufgefallen war. Nachdem Facebook begonnen hatte, seine Routen zurückzuziehen und Facebooks eigene DNS-Server damit vom Netz waren, lieferten auch die anderen DNS-Resolver zunehmend Fehlermeldungen für Facebook. Die wiederholten vergeblichen Nachfragen nach Facebook setzten auch andere Systeme unter Stress.
Ein interessanter Hinweis, der in weiteren Post-Mortem-Analysen noch berücksichtigt werden könnte, kam aus den Niederlanden. Facebook hatte angekündigt, dass es sich vom Austauschknoten NLIX zurückziehen werde. "Vielleicht hat jemand alle BGP-Sessions und nicht nur die mit dem NLIX beendet und jetzt kommen sie nicht an ihre Maschinen, um das wieder rückgängig zu machen", vermutete ein Teilnehmer der Nanog-Mailingliste.
Quelle: heise
