Zusammenfassung
Am 14. Oktober 2020, zwischen 02:41 und 02:52 UTC, war jede Instanz in AMS-01 nicht erreichbar. Ein volumetrischer Angriff, der auf eine einzelne Kundenadresse zielte, erreichte einen Spitzenwert von 340 Gbit/s und sättigte die Uplinks des Standorts. Wir lösten das Problem, indem wir den Upstream anwiesen, den gesamten Verkehr zur Zieladresse zu verwerfen, wodurch der Standort wiederhergestellt wurde und dieser eine Kunde für weitere fünfzig Minuten offline blieb. Es gingen keine Daten verloren und keine Instanz wurde beschädigt. Der Standort verfügte zu diesem Zeitpunkt über keine Scrubbing-Kapazität, und das war eine Kaufentscheidung und kein Zufall.
Zeitverlauf
Alle Zeiten UTC, 14. Oktober 2020.
| Zeit | Ereignis |
|---|---|
| 02:41:04 | Verkehr zu einer einzelnen Kundenadresse steigt in weniger als zwanzig Sekunden von etwa 200 Mbit/s auf 90 Gbit/s. |
| 02:41:30 | Beide Standort-Uplinks sättigen. Paketverlust wird vollständig auf jedem Präfix am Standort, nicht nur beim Ziel. |
| 02:42 | Automatische Alarmierung löst bei Erreichbarkeitsprüfungen von drei externen Sonden aus. |
| 02:44 | Bereitschaftsingenieur online. Angriff ist nur auf den Portdiagrammen sichtbar und sonst nirgends, da unsere Flow-Erfassung mit einer Rate abgetastet wurde, die nicht mithalten konnte. |
| 02:46 | Spitzenwert gemessen bei 340 Gbit/s. Zusammensetzung ist reflektiertes UDP, hauptsächlich DNS und NTP, von Zehntausenden Quellen. |
| 02:47 | Entscheidung getroffen, den Upstream anzuweisen, den gesamten Verkehr zur Zieladresse zu verwerfen. Das war das einzige uns zur Verfügung stehende Werkzeug. |
| 02:49 | Verwerfen verbreitet sich beim ersten Upstream. |
| 02:51 | Zweiter Upstream wendet es an. Uplink-Auslastung fällt unter die Kapazität. |
| 02:52:10 | Standort vollständig erreichbar. Gesamte kundensichtbare Unterbrechung: elf Minuten und sechs Sekunden. |
| 03:20 | Betroffener Kunde kontaktiert und erhält eine neue Adresse angeboten. |
| 03:42 | Kunde wechselt zu einer neuen Adresse; sein Dienst kehrt zurück. |
Ursache
Die unmittelbare Ursache war ein Angriff, den wir nicht absorbieren konnten. Was es tatsächlich verursacht hat, ist, dass wir Hosting in einer Stadt verkauft haben, in der Angriffe dieser Größenordnung üblich waren, mit zweihundert Gigabit Uplink und keinerlei Filterung, und eine Upstream-Verwerfungsvereinbarung als Plan behandelt haben.
Das ist kein Pech. Es war eine Entscheidung, die 2019 zugunsten der Ausgabe des Geldes für Hardware getroffen wurde, und sie war falsch.
Zwei sekundäre Fehler machten es schlimmer. Unsere Flow-Erfassung wurde mit einer Rate abgetastet, die uns während eines echten Ereignisses keine nützlichen Details lieferte, sodass die ersten vier Minuten damit verbracht wurden, Interface-Zähler zu lesen. Und das Verwerfen war manuell, was einen wachen, authentifizierten und selbstbewussten Menschen erforderte, was um drei Uhr morgens drei Anforderungen zu viele sind.
Was das den Kunden gekostet hat
Um es klar zu sagen: Wir haben unser Problem gelöst, indem wir ihren Dienst abgeschaltet haben. Eine Verwerfungsroute ist eine Entscheidung, dass ein Kunde nicht erreichbar sein wird, damit alle anderen es nicht sind. Es war die richtige Entscheidung mit den Werkzeugen, die wir hatten, es war trotzdem ihre Unterbrechung und nicht unsere, und sie hatten kein Produkt von uns gekauft, das etwas anderes versprach.
Sie blieben. Wir haben ihnen den Oktober nicht berechnet.
Was wir geändert haben
- Immer aktives Scrubbing am Edge, innerhalb von drei Wochen gekauft, beginnend mit 1,2 Tbit/s Kapazität. Die Filterung liegt dauerhaft im Pfad, sodass es keine Erkennungsverzögerung und keinen Knopf gibt, den jemand um 02:47 drücken müsste. Dies ist jetzt Standard an jedem Standort, bis zu 12 Tbit/s am größten.
- Uplink in AMS-01 erhöht, zunächst um 200 Gbit/s zusätzlicher Kapazität und später auf die 400 Gbit/s, die der Standort heute betreibt.
- Unsamples Flow-Telemetrie an jedem Standort-Edge, sieben Tage für betriebliche Zwecke aufbewahrt. Dies sind Verkehrsmetadaten für unsere eigenen Ports; es ist kein Instanzverkehr und es ist nicht der Inhalt von irgendetwas.
- Die Verwerfungsroute wurde automatisiert, mit einem dokumentierten Schwellenwert, einer angekündigten Richtlinie und einer Mail an den betroffenen Kunden innerhalb von sechzig Sekunden statt neununddreißig Minuten.
- Angriffe werden veröffentlicht auf der Statusseite, mit Größe und Dauer, ob nun jemand es bemerkt hat oder nicht.
Was wir nicht geändert haben und warum
Wir haben nicht begonnen, für Filterung zu verlangen. Basis-Scrubbing ist in jedem Tarif an jedem Standort enthalten und war es immer, seit wir es gekauft haben. Ein Angriff ist kein Dienst, den das Opfer angefordert hat. Layer-7-Filterung mit benutzerdefinierten Regeln gibt es als Add-on, weil sie einen Menschen auf unserer Seite erfordert, und das ist etwas anderes als eine volumetrische Flut.
Wir haben die Verwerfungsroute nicht entfernt. Zwölf Terabit pro Sekunde ist eine Zahl, nicht unendlich, und so zu tun, als würden wir das grobe Werkzeug nie wieder brauchen, wäre unehrlich. Was sich geändert hat, ist, dass es jetzt der dokumentierte letzte Ausweg ist und nicht der einzige Schritt.
Wir haben keine Verkehrsobergrenzen pro Kunde eingeführt. Das Drosseln jedes Kunden auf einen sicheren Bruchteil des Uplinks hätte dies verhindert, würde aber auch jeden legitimen Spitzenwert abwürgen. Die Filterung gehört an den Edge, auf den Angriff, nicht auf den Kunden.
Wir haben den Kunden nicht auf ein anderes Produkt umgestellt. Sie betrieben das, wofür sie bezahlt hatten, in dem Tarif, der zu ihnen passte, und es war nicht ihre Schuld, dass jemand ein Botnetz auf sie richtete.