DDoS - diesmal wirklich heftig (Part 1/n)
Am Sonntag, den 16. September um 17:05 Uhr erreichten uns Meldungen unseres Monitoringsystems, dass einige Services am Standort FRA3 gar nicht, andere nur sporadisch erreichbar sind. Also erst einmal den Hund vertrösten dass man heute ein wenig später mit ihm raus geht. Dann ein erster Blick ins Monitoring, der zeigt, dass es keinen speziellen Host betrifft, sondern den ganzen Standort.
Durch Messungen von anderen Standorten war ein extremer Packet-Loss zu erkennen, was in der Regel auf eine DDoS-Attacke hindeutet. Also gleich ein Ticket bei unserem Rechenzentrumsanbieter (in diesem Fall Uvensys) aufmachen, denn wir haben an diesem Standort eine DDoS-Protection über einen Cloudservice - so der Plan. Leider war das Ticketsystem nicht erreichbar was auf ein echtes Problem vor Ort hindeutete. Also folgte der Griff zum Telefon und nach wenigen Sekunden und einem kurzen “Hi!” waren wir beim Thema. Es bestätigte sich, dass wir es mit einer DDoS-Attacke zu tun haben, die so massiv ist, dass die maximale Bandbreite aller Anbindungen an diesen Standort weit überschritten ist.
Wir vereinbarten, dass jeder in kurzer Zeit so viel Informationen wie möglich sammelt und wir uns dann erneut kurzschließen. Also analysierten wir, auf einem Host der sich um das Traffic-Accounting kümmert, unsere Uplinks und schnitten einen kurzen Datenstrom mit. Erreichbar war dieser Host über seine IPv6-Adresse - extrem zäh, aber erreichbar. Wie sich jetzt herausstellte, war tatsächlich eines unserer Systeme das Ziel dieses Angriffs. Zu erkennen war ein “Rauschen” an DNS-Antwortpaketen mit Informationen der DNS-Zone “outlook.com”. Okay, diese Zone ist auch wirklich riesig und für eine DNS-Reflection-Attack sehr geeignet. Es folgte wieder der Griff zum Hörer um diese Information zu übermitteln.
Ab ca. 18:10 Uhr lief dann die DDoS-Protection, die eingehende Pakete filtert und über einen GRE-Tunnel bereinigt zurückgeschickt. Über diesen Zustand wurden wir auch direkt telefonisch benachrichtigt - perfekt. Der Vollständigkeit halber kurz das Ticketsystem unseres Anbieters aufgerufen (jetzt ist ja wieder alles erreichbar) und ein Ticket aufgemacht um diesen Vorfall sauber abzuwickeln und somit auch kurz zu dokumentieren. So, abgeschlossen.
Erste Recovery-Meldungen trudeln ein, aber der Paketverlust ist noch zu groß und einige Hosts sind weiterhin nicht erreichbar. Was folgt? Richtig, das Telefon. Die Ursache war schnell gefunden. Es gab vor ein paar Wochen eine Anpassung unseres Netzbereiches bzgl. der IPv4-Adressen, die jetzt beim Routing der Pakete über die DDoS-Protection zu Problemen führten. Aber auch dieses Problem wurde schnell gefixt und nach kurzer Zeit waren alle Hosts und Services wieder erreichbar.
20:45 Uhr. Wir haben dann noch mit Uvensys, genau - telefoniert und die ersten Reports der DDoS-Protection erhalten. Daran wird ersichtlich, dass die Bandbreite teilweise 200 Gbit/s überschritten hat und dass in der ersten Stunde (genauer gesagt bis 19:06 Uhr) 293 Attacken gefahren und 23,696,852 MB an Daten gefiltert wurden. Dieser Angriff stellt vom Volumen her alles bis dato Vorgefallene in den Schatten. Auf jeden Fall ist aber Ruhe eingekehrt. Es gibt zwar Packet-Loss, wenn man den betroffenen und immer noch angegriffenen Host via ICMP erreichen möchte, aber das ist okay. ICMP wird im Mitigationsnetz nicht priorisiert behandelt. So, jetzt aber Notebook eingepackt und kurz mit dem Hund raus …
Gegen 0:05 Uhr am Montagmorgen verzeichneten wir noch einmal einen Ausfall einiger Dienste, der dann (ja, nach einem Telefonat) darauf zurückzuführen war, dass der genannte GRE-Tunnel, über den der “gewaschene” Traffic zurück kommt, durch Überlast ausgefallen ist. Auch dieses Problem wurde dann rasch gefixt und es kehrte Ruhe ein. In der Zwischenzeit hat sich die Art des Angriffs geändert. Die DNS-Reflection-Attacke ist vorbei, stattdessen wird der angegriffene Host (alnilam.uberspace.de) mit ACK-Paketen auf Port 443 IP inklusive Address Spoofing attackiert.
Am späten Montagabend den 17.September ist der besagte GRE-Tunnel leider wiederholt und ohne bekannten Grund weggebrochen. Zu diesem Zeitpunkt hat Uvensys die DDoS-Protection deaktiviert und den Traffic wieder direkt angenommen. Es wurden nun eigene Maßnahmen getroffen den Angriff zu unterbinden, im Detail Traffic Shaping auf die angegriffene IP von alnilam und gleichzeitigem Blockieren des angegriffenen Ports 443. Dadurch war der Host alnilam zu diesem Zeitpunkt via HTTPS nicht, alle anderen Systeme und Services aber wieder erreichbar.
Am frühen Dienstag den 18. September um ca. 2:00 Uhr nahm die Kraft der Attacke erneut zu und führte zu einer Blockade aller Netzeingänge seitens Uvensys. Die dort sofort eingeleitete Maßnahme war das Aktivieren der DDoS-Protection. Diese konnte die Angriffe recht schnell abwehren und sicherte nach wenigen Minuten wieder ein Erreichen aller Systeme. Auch der GRE-Tunnel lief stabil und machte keinerlei Probleme. Nichtsdestotrotz war der Angriff im vollen Gange.
Am frühen Mittwoch den 19. September um ca. 2:50 Uhr verzeichneten wir noch einen kleinen Ausfall einiger Services die aber um 2:57 Uhr schon wieder alle erreichbar waren. Einen Grund hierfür haben wir dann nicht gesucht, behielten das Monitoring aber im Auge.
Stand Mittwoch, 19. September 11:00 Uhr. Unfortunately - to be continued …
Als Vorabinformation aber schon mal so viel: Die derzeitige DDoS-Protection muss in einigen Dingen verbessert werden. Zum einen muss das Aktivieren der Protection optimiert werden und zum anderen wird der GRE-Tunnel einer Dark-Fibre weichen, um Stabilität zu gewährleisten. Alle Beteiligten arbeiten wirklich intensiv daran, diese Angriffe abzuwehren und “nutzen die Gelegenheit” zu analysieren, zu beobachten und Erfahrungen zu sammeln, die dann in Optimierungen und Verbesserungen der Protection enden werden.
Des Weiteren ist unsere Statusseite so gut wie fertig. Hier soll auf einen Blick zu erkennen sein was gerade passiert, wo es klemmt und wo Entwarnung gegeben werden kann. Dazu dann jeweils natürlich auch kurze und knappe Informationen und Hinweise. Aber dazu später mehr, versprochen.
Update: Unsere Statusseite ist nun unter der hoffentlich leicht zu merkenden Adresse is.uberspace.online erreichbar. Wir hosten diese Statusseite bewusst vollständig außerhalb unserer eigenen Infrastruktur, damit sie erreichbar bleibt, wenn bei uns nichts mehr gehen sollte. Wenn ihr also etwas beobachtet, was für euch nach Störung aussieht, könnt ihr dort nachschauen, ob wir schon von etwas wissen - und wenn dort nichts steht, mit unserem Support twittern.