Internet-Schwachstelle legt Google lahm

Internet-Schwachstelle legt Google lahm

Am 12. November 2018, zwischen 13:00 und 14:23 Uhr PST, bemerkte ThousandEyes Probleme bei der Verbindung mit der G Suite, einer kritischen Anwendung für unser Unternehmen. Bei der Überprüfung der Statistik der ThousandEyes-Endpoint-Agents stellten wir fest, dass dies Auswirkungen auf alle Nutzer im ThousandEyes-Büro hatte. Der Ausfall betraf nicht nur die G Suite, sondern auch Google Search sowie Google Analytics. Uns fiel auf, dass der Traffic zu Google bei China Telecom unterbrochen wurde. Warum sollte der an Google übermittelte Traffic von einem Büro in San Francisco bis nach China gelangen? Wir bemerkten auch einen russischen ISP im Traffic-Pfad, was ebenfalls verdächtig war.

Abbildung 1: Wir bemerkten auch einen russischen ISP im Traffic-Pfad, was definitiv einige Bedenken aufkommen ließ.

Bei weiteren Nachforschungen stellten wir fest, dass mehrere ThousandEyes-Positionen rund um den Globus ähnlich ungewöhnliche Datenverkehrswege meldeten, die alle bei China Telecom endeten.

Abbildung 2: Traffic von mehreren Standorten zu Google, der bei China Telecom in ein schwarzes Loch gerät.

Die ThousandEyes BGP Route Visualization zeigte ein interessantes Bild. Der Traffic von Paris zu www.google.com wurde zu 216.58.204.204.132 aufgelöst. Obwohl Google viele /24-Präfixe ankündigt, um seinen IP-Adressbereich abzudecken, wurde diese Adresse nicht durch ein /24-Präfix abgedeckt. Stattdessen wurde sie durch ein /19-Präfix abgedeckt. Wir beobachteten eine verdächtige Ankündigung für 216.58.192.0/19 die kurz nach 12:45 Uhr PST stattfand, mit einem gewundenen AS-Pfad, der TransTelecom (AS 20485) in Russland, China Telecom (AS 4809) in China und MainOne (AS 37282), einen kleinen ISP in Nigeria.

Abbildung 3: Verdächtige Ankündigung für 216.58.192.0/19, die den optimalen Pfad zu Google über Russland, China und Nigeria zeigt.

Die Traffic-Pfade, die wir sahen, spiegelten den BGP AS Path wider, nur dass der gesamte Traffic gegen die Great Firewall prallte und am China Telecom Edge-Router endete. Weitere Details dazu sind hier verfügbar.

Dieser Vorfall hatte zumindest einen massiven Denial-of-Service für G Suite und Google Search zur Folge. Allerdings wurde dadurch auch wertvoller Google Traffic in die Hände von ISPs gelenkt, die in Ländern mit einer langen Geschichte der Internetüberwachung angesiedelt sind. Insgesamt erkannte ThousandEyes über 180 Präfixe, die von diesem Routenverlust betroffen waren, was einen großen Bereich von Google-Diensten abdeckt. Unsere Analyse zeigt, dass der Ursprung dieses Verlusts der BGP-Datenaustausch zwischen MainOne, dem nigerianischen Anbieter, und China Telecom war. MainOne tauschte die Daten mit Google über IXPN in Lagos sowie eine direkte Verbindung zu Google aus, die an China Telecom durchsickerte. Diese durchgesickerten Routen wurden von China Telecom über TransTelecom an NTT und andere Transit-ISPs weitergegeben. Wir stellten auch fest, dass dieser Verlust in erster Linie von Business-Level-Transitanbietern propagiert wurde und die ISP-Netzwerke der Verbraucher nicht so stark betroffen waren.

Wir stellten auch fest, dass dieser Verlust in erster Linie von Business-Level-Transitanbietern aufgebracht wurde und die ISP-Netzwerke der Verbraucher nicht so stark betroffen waren.

Am 13. November teilte MainOne auf Twitter mit, dass die Ursache des Problems tatsächlich auf einen Konfigurationsfehler zurückzuführen war.

Abbildung 4: MainOne bekennt sich zu dem Konfigurationsfehler, der die Google-Dienste zum Absturz brachte.

Dieser Vorfall zeigt einmal mehr eine der grundlegenden Schwächen im Gefüge des Internets. BGP wurde als eine Vertrauenskette zwischen ISPs und Universitäten konzipiert, die den erhaltenen Informationen blind vertrauten. Es spiegelt nicht die aktuellen, komplexen kommerziellen und geopolitischen Beziehungen zwischen ISPs und Nationen wider. Obwohl es Verifikationsmethoden wie ROA gibt, setzen nur wenige ISPs diese ein. Selbst Unternehmen wie Google, die über massive Ressourcen verfügen, sind nicht immun gegen diese Art von BGP-Verlusten oder böswilligen Übergriffen. MainOne brauchte 74 Minuten, um das Problem zu bemerken und es zu beheben. Es dauerte etwa eine weitere Dreiviertelstunde, bis die Dienste wieder einsatzbereit waren. Die meisten Unternehmen, die nicht über die Reichweite und Ressourcen von Google verfügen, können das Problem möglicherweise nicht so schnell lösen, was sich erheblich auf den Geschäftserfolg auswirken kann.

BGP-bezogene Vorfälle sind auf dem Vormarsch. Im April 2018 erlebten wir einen dreisten Kryptowährungsraub bei dem ein ganzer DNS-Provider (Route 53) bestohlen wurde. Nur ein Jahr zuvor, im April 2017, sahen wir den Rostelecom BGP Routenverlust, von dem eine große Anzahl von E-Commerce- und Finanzdienstleistungs-Websites betroffen waren. Die ISP-Community erkennt das Ausmaß des Problems, und es gibt dafür Lösungen wie ROA- und IRR-Filter. Allerdings ist keine davon eine Wunderwaffe und deren Implementierung birgt die Gefahr, das Internet zum Erliegen zu bringen.

Da es keine Garantien gibt, müssen Unternehmen ihre BGP-Routen kontinuierlich überwachen, um solche Vorfälle schnell zu erkennen. Nur so können sie die Auswirkungen auf den Service für ihr Unternehmen minimieren. Erfahren Sie mehr darüber, wie Sie mit ThousandEyes BGP-Raub und Verluste erkennen können. Abonnieren Sie den ThousandEyes-Blog, um über solche Ausfallanalysen und Best Practices zur Bereitstellung eines zuverlässigen Internet-Erlebnisses auf dem Laufenden zu bleiben.