Unter Beschuss! Wie wir massive DDoS-Angriffe abgewehrt haben

Es war September 2023, ein schöner warmer Sommertag. Wir waren alle zum wöchentlichen Bürotag bei unserem Kunden - einer Bank in den Niederlanden - versammelt. Wir scherzten über die Tatsache, dass es ein ganz normaler Arbeitstag war - ruhig, gelassen und ein bisschen langweilig. Plötzlich erhielten wir einen Anruf vom IT-Service Desk. Kunden beschwerten sich, dass die öffentlichen Websites nicht mehr funktionierten und sie sich nicht mehr in ihre Umgebungen einloggen konnten. Was war da los? Die Hölle brach los.

Zu dieser Zeit betrieben wir Websites, die in Azure App Service-Umgebungen gehostet wurden und über ein Azure Application Gateway, das durch eine Web Application Firewall geschützt war, ins Internet gingen. Das Application Gateway war mit einer Anzahl von zwei Instanzen konfiguriert, mehr als genug, um die normale Anzahl von Besuchern auf unseren Websites zu bewältigen, etwa 400-500 Webanfragen pro Minute.

Wir haben versucht, unsere Websites zu besuchen und festgestellt, dass sie nicht erreichbar waren. Wir öffneten Azure Portal, um unser Web Application Gateway zu untersuchen. Die Übersichtsseite zeigte, dass wir 600.000 Anfragen pro Minute erhielten. Das Application Gateway hatte Mühe, lief aber weiter. Um ihm etwas mehr Spielraum zu geben, erhöhten wir die maximale Anzahl der Instanzen auf zehn. Das Application Gateway begann besser zu reagieren, aber unsere Websites blieben unerreichbar. Was sollten wir als nächstes tun?

Autsch

In der Zwischenzeit wurde klar, dass wir ein großes Problem hatten. Unerreichbare Webseiten einer Bank lösen bei Rating-Agenturen, der niederländischen Nationalbank und der Europäischen Zentralbank ernste Bedenken aus.

Es wurde ein Krisenteam aus Infrastruktur-, Anwendungs- und Sicherheitsspezialisten gebildet. Einer der Sicherheitsspezialisten entdeckte über Telegram, dass wir eines der strategischen Ziele eines gut koordinierten globalen DDoS-Angriffs waren, der von einem russischen Hackerkollektiv initiiert wurde. Der Angriff war eine Reaktion auf die Ankündigung der militärischen Unterstützung durch unsere politischen Führer. Ein Angriff, der darauf abzielte, das tägliche Leben zu destabilisieren, indem Websites von Banken, Behörden und öffentlichen Verkehrsmitteln lahmgelegt wurden.

In unserem Azure-Tenant hatten wir einen Azure DDoS Network Protection Plan. In diesem Plan sind bis zu 100 öffentliche IP-Adressen unabhängig vom Abonnement geschützt, solange es sich um ein Abonnement unter dem jeweiligen Tenant handelt. Einer der Vorteile des DDoS Network Protection Plan ist, dass Kunden, die angegriffen werden, sich an Rapid Response wenden können. Ein weiterer Vorteil ist, dass Sie durch den Kostenschutz abgedeckt sind (Sie zahlen nur für das, was Sie konfiguriert haben).

Microsoft wurde darüber informiert, dass wir einem schweren DDoS-Angriff ausgesetzt waren, und wir baten sie, einige Gegenmaßnahmen zu ergreifen. Bald darauf begann unser Application Gateway massiv zu skalieren (habe ich schon die Vorteile eines Kostenschutzes erwähnt). Zu diesem Zeitpunkt waren wir in der Lage, eine allgemeine Fehlerseite auszuliefern, die anzeigte, dass wir aufgrund eines technischen Problems offline waren. Dies gab uns die Möglichkeit, eine gründliche Analyse der verursachenden IP-Adressen durchzuführen. Wir fanden heraus, dass mehrere IP-Adressen die Hauptursache für den starken Anstieg unseres Datenverkehrs waren. Wir erstellten eine Firewall-Regel, um diese IP-Adressen zu blockieren, aber das führte nicht dazu, dass unsere Websites wieder online waren. Die Angreifer starteten ihre Angriffe einfach von anderen IP-Adressen aus. Dann sahen wir uns die User-Agents an (jede Web-Anfrage enthält Informationen über den User-Agent) und beschlossen, eine Reihe von verdächtigen und anonymen User-Agents zu blockieren. Unter den verdächtigen Benutzer-Agenten fielen uns go-http-client/1.1 und go-http-client/2.0 auf. Diese User Agents sind normalerweise die Kennung für den Google Bot/Crawler. Ein Dienst, der Ihre Website für das Ranking im Google-Suchindex indiziert. Dieser Dienst besucht Ihre Website mehrmals am Tag, schlägt aber nie auf Ihre Website ein. In unserem Fall gaben die Hacker vor, der Google Crawler zu sein.

Bald waren unsere Websites wieder online, wenn auch langsam. Wir haben auch festgestellt, dass sich der Angriff auf die Suchseite auf unseren öffentlichen Websites konzentrierte. Das Anwendungsteam nahm die Seite vorübergehend offline. Die Websites begannen normal, aber langsam zu reagieren.

Der erste Angriff wurde entschärft, die hohe Zahl der Anfragen, die auf uns abgefeuert wurden, hielt bis zum nächsten Tag an. Der Verkehr kehrte zu normalen Zahlen zurück. Zeit für uns, ernsthafte Maßnahmen zu ergreifen! Egal, was passiert, unsere Online-Präsenz hatte höchste Priorität. Bald darauf öffnete das Wort "DDos-Attacke" alle möglichen Türen innerhalb der Bank und ebnete den Weg für alle möglichen Änderungen, die an unserer Infrastruktur vorgenommen werden mussten.

Als die DDoS-Angriffe begannen, war eines der IT-Themen bei der Bank "Disaster Recovery". Im Falle eines regionalen Ausfalls von Azure sollte der Betrieb weitergehen. Daher waren wir dabei, unsere Azure-Infrastruktur so einzurichten, dass sie weltweit redundant war - in unserem Fall bauten wir eine komplette Infrastruktur in unserer gepaarten Region, Nordeuropa, auf.Damit unsere öffentlichen Websites unter denselben URLs verfügbar waren, arbeitete ich im Hintergrund an der Implementierung von Azure Front Door - dem globalen Content Delivery Network von Microsoft. Ein ziemlich komplexes Unterfangen, um es mit Infrastructure as Code (IaC) einzurichten.

Probleme mit der Haustür, veraltete Beispiele und mehrere Produkte

Wie sich herausstellt, gibt es in Azure mehrere Produkte namens Front Door. Und das macht es sehr verwirrend, wenn Sie in dieses Produkt eintauchen. Es gibt Front Door classic Microsoft.Networking/Front Doors und Front Door Standard/Premium Microsoft.CDN/profiles. Letzteres sollten Sie verwenden, da die erste Version ausläuft. Die meisten Beispiele auf MS Learn verwenden die klassische Version, weshalb ich mich frage, warum Microsoft seine Beispiele nicht aktualisiert, um zu zeigen, wie die neueste und beste Version verwendet werden sollte.

Eine Woche nach dem ersten DDoS-Angriff konnten wir FrontDoor CDN vor unseren Websites einrichten. Während des Abendessens hatten wir die DNS-Einträge auf die Verwendung von Azure Front Door umgestellt. Nach einem kleinen Hick-Up und einem Hack in letzter Minute zwischen dem Hauptgang und dem Dessert wurden die öffentlichen Websites über das Azure Front Door CDN-Netzwerk bedient.

Das Schöne an einem CDN ist, dass Sie keine IP-Adresse haben, die von einem Hacker ins Visier genommen werden kann. Stattdessen müssen Sie lediglich CNAMES in Ihrem DNS bereitstellen, die auf die spezifische Front Door-Instanz verweisen, die Sie verwenden.

Das Problem bei den meisten DNS-Anbietern ist jedoch, dass Sie einen A-Eintrag benötigen, der auf Ihre Top-Level-Domain (z.B. bank.nl) verweist; ein A-Eintrag verweist auf eine bestimmte IP-Adresse. Microsoft empfiehlt, dass Sie einen DNS-Anbieter wählen, der CNAME-Flattening anbietet. Eine Funktion, die bei DNS-Anbietern nicht weit verbreitet ist. CNAME Flattening ermöglicht es Ihnen, einen Domainnamen wie "bank.nl" als CNAME-Eintrag zu verwenden, während ein CNAME-Eintrag wie "www.bank.nl" aussehen sollte. Wir haben das Problem gelöst, indem wir die IP-Adresse der nächstgelegenen Front Door CDN-Instanz in unserer Region - die sich im Azure-Rechenzentrum in Amsterdam befindet - als A-Eintrag verwendet haben.

Um sicherzustellen, dass der Datenverkehr an unser Anwendungs-Gateway gesendet wird, haben wir eine Firewall-Richtlinie für Webanwendungen implementiert, die nur Datenverkehr zulässt, der von unserem Front Door kommt (indem wir die Front Door ID im Header senden). Als zweite Maßnahme haben wir eine Netzwerksicherheitsgruppe im Subnetz des Anwendungs-Gateways implementiert, um nur den von Front Door eingehenden Datenverkehr zuzulassen.

Es geht wieder los

Wie auch immer, mit der neuen Front Door wartete es auf den nächsten DDoS-Angriff... Es dauerte nicht lange, da kam unsere Regierung mit einer neuen Ankündigung für Militärhilfe. Am Tag darauf wurde ein neuer DDoS-Angriff von demselben Hackerkollektiv gestartet.

Dieses Mal stellten wir fest, dass unsere Websites überlastet waren. Die Benutzer erhielten eine nette Fehlerseite, die anzeigte, dass wir technische Schwierigkeiten hatten. Mit den Lehren aus dem ersten Angriff beschlossen wir, die Suchseite zu blockieren und eine Regel zum Blockieren bestimmter Bots einzuführen. Innerhalb kürzester Zeit waren unsere Websites wieder online und sind es seitdem auch geblieben. Wir waren fast am Ziel, aber noch nicht ganz.

Nachdem der Angriff vorüber war, fügten wir die neu hinzugefügten Regeln zu unserem IaC hinzu und beschlossen, eine weitere Funktion von Azure Front Door Premium zu implementieren: Throttling. Mit Throttling konnten wir die Anzahl der Webanfragen, die von einem einzelnen Client innerhalb eines bestimmten Zeitraums kamen, begrenzen. Wir haben eine maximale Anzahl von Anfragen pro Minute eingeführt, die auf der starken Nutzung multipliziert mit zwei basiert. Gleichzeitig arbeiteten wir daran, von App Service Environments wegzukommen und Application Service Plans zum Hosten der Websites zu implementieren. Eine letzte Maßnahme, die wir eingeführt haben, war ein Frühwarnsystem, das uns alarmiert, wenn der Datenverkehr auf unseren Websites einen bestimmten Schwellenwert überschreitet. Aus den vorangegangenen Angriffen haben wir gelernt, dass die Hacker ihre Angriffe schrittweise steigern, um die DDoS-Kontrollen der Internet Service Provider (ISP) zu umgehen. Für den ISP sahen die Metriken wie eine sehr gut besuchte Website aus.

Keiner hat es bemerkt

Trotz aller Vorkehrungen wurden wir während der Weihnachtsfeiertage angegriffen. Niemand hat es bemerkt, bis auf den diensthabenden Ingenieur. Er erhielt eine Warnung, dass wir im Rahmen des massivsten Angriffs, den die Hacker bisher gestartet hatten, angegriffen wurden. 1,2 Millionen Anfragen pro Minute wurden auf unsere Websites abgefeuert. Unsere Kunden konnten weiterhin unsere Websites besuchen und ihre Umgebungen nutzen.

Gelernte Lektionen

Wenn Sie unternehmenskritische Websites haben, könnte es eine gute Idee sein, die Websites hinter ein Front Door CDN zu stellen. Front Door kann die Komplexität aus Ihrer internen Umgebung herausnehmen und die Regelverarbeitung auf die Seite von Microsoft verlagern. Dasselbe gilt für Firewall-Richtlinien und die Konvertierung von HTTP zu HTTPS. Der Datenverkehr, der an die eigentliche Website weitergeleitet wird, wird gescannt.

Front Door kann für die Drosselung eingerichtet werden, eine Funktion, die ich sehr empfehle. Die Drosselung verhindert, dass Ihre Website überlastet wird. Nutzen Sie die Caching-Funktion von Front Door für statische Inhalte, Ihr Webserver wird es Ihnen danken.

Das Application Gateway muss sich nur um das grundlegende Routing zu den Webservern kümmern. Mit einer benutzerdefinierten Firewall-Richtlinie und einer Netzwerksicherheitsgruppe können wir sicherstellen, dass der eingehende Datenverkehr nur von unserer Front Door-Instanz stammt (alle anderen Daten werden abgewiesen).

Verwenden Sie einen Log-Analyse-Arbeitsbereich, um Ihren Datenverkehr zu analysieren, herauszufinden, welche User Agents Ihre Website besuchen, und eine Richtlinie zum Blockieren unerwünschter Gäste einzurichten.

Implementieren Sie ein Frühwarnsystem. Die meisten Angriffe werden allmählich aufgebaut, um unter dem Radar zu bleiben. Wenn der Alarm ausgelöst wird, entscheiden Sie, ob Sie Gegenmaßnahmen ergreifen müssen.

Arbeiten Sie weiter und verfeinern Sie weiter, denn Sicherheit ist eine unendliche Geschichte. Die Frage, die Sie sich stellen müssen, lautet: "Nicht 'ob', sondern 'wann' werde ich angegriffen?", und dann sollten Sie darauf vorbereitet sein!

 

Dieser Beitrag ist Teil von XPRT.#16. Sie können das Magazin hier herunterladen.