Cloudflare will Webseiten schneller machen und vor Angriffen schützen, doch das Update einer Filterregel auf Cloudflares Routern führte am Wochenende dazu, dass rund 785.000 Websites vorübergehend nicht mehr erreichbar waren.
Rund 785.000 Websites waren am Wochenende für rund eine Stunde offline. Schuld daran war eine neue Filterregel, die Cloudflare auf seinen Routern verteilte. Eigentlich nichts Ungewöhnliches, nimmt Cloudflare doch ständig solche Änderungen an seinen Routern vor. Doch diesmal lief einiges schief.
Cloudflare bietet eine Art Proxy-Dienst an, der vor eine Website geschaltet werden kann. Dazu wird der DNS-Eintrag so geändert, dass Nutzer, die die eigene Website aufrufen, fortan auf den Servern von Cloudflare landen, die dann die Daten von dem eigentlichen Server laden. Zum einen schützt Cloudflare Websites so vor Angriffen, zum anderen werden die Daten optimiert, um die Ladezeiten der Websites zu verkürzen.
Der große Nachteil an diesem Konstrukt: Sind die Server von Cloudflare nicht erreichbar, sind alle Websites offline, die den Dienst benutzen. Damit das nicht passiert, setzt Cloudflare auf eine verteilte Infrastruktur. Die Systeme sind weltweit in 23 Rechenzentren in 14 Ländern verteilt, DNS-Anfragen werden mit Anycast verteilt, so dass es keinen Single-Point-of-Failure gibt. Fällt ein Rechenzentrum aus, gehen die Anfragen an das nächstgelegene.
Doch all das half an diesem Wochenende nichts, denn sämtliche Systeme von Cloudflare waren auf einen Schlag nicht mehr erreichbar, einschließlich Cloudflares DNS-Server und somit auch die Websites aller Cloudflare-Kunden.
Ausgangspunkt war die Änderung einer Filterregel auf Juniper-Routern von Cloudflare. Diese sollte eigentlich dafür sorgen, dass keine Pakete mehr durchgelassen werden, die zwischen 99.971 und 99.985 Byte groß sind. Cloudflares Analysesysteme hatten zuvor festgestellt, dass solche ungewöhnlichen großen Pakete für Angriffe auf die eigenen Systeme genutzt werden.
Für die Verteilung solcher Filterregeln auf seine weltweit verstreuten Router nutzt Cloudflare das von Juniper unterstützte Protokoll Flowspec. So auch in diesem Fall: Flowspec akzeptierte die neue Filterregel und verteilte sie an alle Router von Cloudflare. Statt aber die Regel zu aktivieren, lief der Speicher auf allen Routern voll, bis sie abstürzten.
Kommt es zu einem solchen Router-Absturz, sorgt ein Monitoring-Prozess dafür, dass der jeweilige Router neu gestartet wird. Allerdings stürzten viele der Router in diesem Fall so ab, dass sie eben nicht automatisch neu starteten. Bei einigen klappte das zwar, doch der hereinkommende Traffic war für diese wenigen Systeme, die nun wieder erreichbar waren, zu viel, so dass sie unter der Last zusammenbrachen.
Erst nachdem die Regel auf allen Systemen entfernt und die nicht startenden Router per Hand vor Ort neu gestartet wurden, war Cloudflare und damit auch die Websites der Kunden wieder erreichbar. Der Ausfall dauerte insgesamt 62 Minuten, in einigen Fällen waren Websites aber länger nicht erreichbar, da anfragende Systeme die DNS-Antworten, die sie während des Ausfalls erhielten, gecacht haben.
Cloudflare hat sich mit dem Problem an Juniper gewandt, um herauszufinden, ob die Ursache für den Absturz der Router ein genereller Bug ist oder mit der Konfiguration der eigenen Infrastruktur zu tun hat. Zudem will Cloudflare neue Filterregeln in Zukunft ausgiebiger testen, bevor sie per Flowspec verteilt werden. Und wenn möglich, sollen Filterregeln nur dort eingespielt werden, wo sie benötigt werden.
Quelle: Golem.de
