Wie sich NGINX App Protect Denial of Service an die sich wandelnde Bedrohungslandschaft anpasst

NGINX | 06. Juli 2021

Da wir immer mehr Bereiche unseres täglichen Lebens ins Internet verlagern, verstärken auch Cyberangreifer ihre Bemühungen, die Servicequalität der Apps zu beeinträchtigen, auf die wir angewiesen sind. Ihre Beweggründe sind vielfältig: Sie reichen von Rache über die Beeinflussung des Aktienkurses betroffener Unternehmen bis hin zur Erzeugung eines Ablenkungsmanövers, das Sicherheitsteams von Datenschutzverletzungen ablenkt.

In einem früheren Blogbeitrag beschreiben wir, wie Sicherheitsteams in der Vergangenheit fortlaufend neue Abwehrmaßnahmen gegen volumetrische Denial-of-Service-Angriffe (DoS) und verteilte DoS-Angriffe (DDoS) auf der Netzwerk- und Transportebene (Schichten 3 und 4) entwickeln mussten. Diese Angriffe schöpfen die verfügbare Bandbreite von Servern aus, indem sie sie mit TCP/UDP-Verbindungsanfragen überfluten. Nun haben Angreifer ihr Arsenal um ein neues Werkzeug erweitert: DoS- und DDoS-Angriffe, die HTTP-Anfragen oder API-Aufrufe nutzen, um Ressourcen auf der Anwendungsebene (Schicht 7) zu erschöpfen.

Herkömmliche DoS-Schutzmaßnahmen gegen Netzwerk- und volumetrische Angriffe sind bei Layer-7-Angriffen nicht wirksam, da bösartige Anfragen auf Anwendungsebene häufig genauso aussehen wie legitime Anfragen. Darüber hinaus können HTTP-Angriffe auf Layer 7 bereits bei einer deutlich geringeren Anfragerate und einem deutlich geringeren Anfragevolumen Schaden anrichten als Angriffe auf Netzwerkebene. Angesichts völlig neuer Anforderungen muss der Layer-7-DoS-Schutz daher empfindlicher reagieren:

  • Angriffe von regulären Datenverkehrsmustern unterscheiden
  • Bewertung des Serverzustands unter Last
  • Feststellen, wann ein Angriff begonnen hat und ob er beendet ist
  • Angriffe abwehren, ohne legitime Nutzer zu beeinträchtigen
  • Feststellen, ob Änderungen im Verhalten der App auf einen Angriff oder auf Aktualisierungen der App-Funktionalität zurückzuführen sind
  • Einen lang anhaltenden Angriff ohne Beeinträchtigung der Erkennungswirksamkeit überstehen

NGINX App Protect Denial of Service (DoS) bewältigt all diese Herausforderungen und gewährleistet so einen optimierten, einfach zu implementierenden Zero-Day-Schutz mit adaptiver, vollautomatischer Richtlinienkonfiguration.

Wie sich NGINX App Protect DoS automatisch anpasst, um Angriffe abzuwehren

NGINX App Protect DoS verwendet einen mehrstufigen Prozess, um DoS-Angriffe auf Layer 7 zu erkennen und abzuwehren:

  1. Typisches Verhalten in einem statistischen Website-Modell erfassen
  2. Dienststatus überprüfen
  3. Eine Anomalie erkennen
  4. Böswillige Akteure und Anfragemuster identifizieren
  5. Wehren Sie den Angriff mit einer mehrschichtigen Verteidigung ab

Erfassung typischen Verhaltens in einem statistischen Website-Modell

Der erste Schritt in diesem Prozess besteht darin, das Benutzer- und Anwendungsverhalten zu einem Zeitpunkt zu erfassen, an dem die Website nachweislich nicht angegriffen wird, um ein statistisches Website-Modell zu erstellen, das als Ausgangsbasis für typisches Verhalten dient. NGINX App Protect DoS erfasst 320 Benutzer- und Anwendungsmetriken und bietet so einen umfassenden Überblick über Ihre Anwendungsbereitstellung. Zudem aktualisiert es das statistische Website-Modell dynamisch, während es den Datenverkehr beobachtet. Dadurch müssen Sie die Systemschwellenwerte nicht mehr manuell anpassen. Gleichzeitig ist gewährleistet, dass NGINX App Protect DoS die im Laufe der Zeit unvermeidlich auftretenden Veränderungen der Datenverkehrsmuster berücksichtigt.

Eine Kategorie der erfassten Metriken betrifft die Merkmale von HTTP-Anfragen – die HTTP-Methode, den Wert des User-Agent-Headers und weitere Merkmale, wie sie in der Abbildung dargestellt sind.

Kreisdiagramme zur Darstellung der Werteverteilung für Merkmale von HTTP-Anfragen (Methode, Wert des User-Agent-Headers und sechs weitere)

Überprüfen des Dienststatus

Viele Tools zur Abwehr von Layer-7-DoS-Angriffen berücksichtigen ausschließlich die Datenverkehrsmuster der Clients. Für eine bessere Angriffserkennung können Sie NGINX App Protect DoS so konfigurieren, dass zusätzlich der Zustand des Dienstes aktiv überprüft wird. Dabei werden mehrere Leistungskennzahlen des Servers erfasst, beispielsweise die Antwortzeit und der Anteil verworfener Anfragen. Verschlechtern sich diese Werte, deutet dies darauf hin, dass eine Anwendung möglicherweise aufgrund eines Angriffs „unter hoher Last“ steht. Die Überwachung von Serverkennzahlen bietet einen weiteren Vorteil: Sobald NGINX App Protect DoS feststellt, dass ein Angriff stattfindet, lässt sich anhand des Antwortmusters bei den Zustandsprüfungen ermitteln, wann der Angriff begonnen hat.

Erkennen einer Anomalie

Wenn NGINX App Protect DoS anhand von Abweichungen vom statistischen Modell der Website und Änderungen der Serverantwort (sofern konfiguriert) feststellt, dass ein Angriff stattfindet, wird die Aktualisierung des statistischen Modells der Website beendet. Stattdessen wird analysiert, wie sich die aktuellen Messwerte von den festgelegten Basiswerten unterscheiden. Die Unterschiede deuten wahrscheinlich auf eine globale Anomalie hin.

Identifizieren böswilliger Akteure und Anfragemuster

NGINX App Protect DoS startet daraufhin zwei parallel ablaufende Prozesse:

  1. Analyse des Verhaltens einzelner Benutzer, um zu erkennen, wer die Anomalie verursacht oder dazu beigetragen hat. NGINX App Protect betrachtet zunächst alle Benutzer als Verdächtige und analysiert ihr Verhalten. Es ist unwahrscheinlich, dass jeder Benutzer ein Angreifer ist. Durch die Messung des Verhaltens aller Benutzer kann NGINX App Protect jedoch ein statistisches Bild erstellen, aus dem hervorgeht, wer zu dem Angriff beigetragen hat und wer nicht. Erkannte böswillige Akteure werden anhand ihrer IP-Adresse oder des X-Forwarded-For-Headers in ihren Anfragen identifiziert.
  2. Erstellen einer Liste von Regeln, die den Angriffsverkehr beschreiben, ohne legitime Benutzer zu blockieren – Echtzeitsignaturen zum Schutz vor Zero-Day-Angriffen. Bei früheren Angriffen generierte Signaturen können wiederverwendet werden. Die generierten Signaturen identifizieren HTTP-Attribute, die mit dem Angriff in Verbindung stehen, wie in diesem Beispiel:
http.request.method eq GET and http.user_agent contains Chrome and http.uri_parameters eq 6 and http.accept_header_exists eq false and 
http.headers_count eq 7

Abwehr des Angriffs durch eine mehrschichtige Verteidigung

Das Hauptziel bei der Abwehr eines Layer-7-Angriffs besteht darin, ihn zu erkennen, bevor er Schaden anrichten kann.

Wie im folgenden Diagramm dargestellt, können Sie entweder eine konservative oder eine standardmäßige Abwehrstrategie konfigurieren. Bei beiden Strategien besteht die erste Verteidigungsebene darin, Anfragen von böswilligen Akteuren zu blockieren, die im vorherigen Schritt anhand ihrer IP-Adresse und des X-Forwarded-For-Headers identifiziert wurden. Die nächste Verteidigungsebene blockiert Anfragen, die den im vorherigen Schritt generierten Signaturen entsprechen.

Wenn Sie schließlich die Standardabwehr konfiguriert haben und NGINX App Protect DoS feststellt, dass die ersten beiden Verteidigungsebenen nicht ausreichen, wird für kurze Zeit eine globale Ratenbegrenzung angewendet.

NGINX App Protect DOS bietet einen mehrstufigen Schutz vor Angriffen. Dabei kommen zunächst konservative Abwehrmaßnahmen zum Einsatz (Blockieren schädlicher IP-Adressen und übereinstimmender Signaturen), gefolgt von Standardmaßnahmen (Ratenbegrenzung), falls erforderlich.

Minimierung von Fehlalarmen bei der Abwehr von Angriffen

Wenn NGINX App Protect DoS eine globale Ratenbegrenzung anwendet, besteht die Möglichkeit, dass Anfragen legitimer Benutzer blockiert werden – ein Fehlalarm. NGINX App Protect DoS kann Fehlalarme reduzieren, da ein typischer DoS-Angriff mithilfe von Skripten ausgeführt wird, die von einem Botnet-Controller (Schadsoftware auf infizierten Computern) gesteuert werden, und nicht direkt von Menschen. Im Gegensatz zu Webbrowsern können viele dieser einfachen Skripte eine HTTP-Weiterleitung nicht ordnungsgemäß verarbeiten, und noch weniger sind in der Lage, JavaScript auszuführen. Anhand dieser unterschiedlichen Fähigkeiten von Skripten und Browsern kann NGINX App Protect DoS erkennen, welche davon den verdächtigen Datenverkehr erzeugen.

Anstatt also die Anfragerate für alle Clients zu begrenzen, sendet NGINX App Protect DoS zunächst eine HTTP-Weiterleitung und anschließend ein JavaScript-Codefragment zur Verarbeitung. Skriptgesteuerte Bots können darauf nicht erfolgreich reagieren, ein Browser hingegen schon. Dadurch kann NGINX App Protect DoS den Datenverkehr von Skripten blockieren und gleichzeitig den Browser-Datenverkehr zulassen.

Uns ist bewusst, dass einige Benutzer Bedenken haben, sich auf adaptives Lernen zu verlassen, da dabei potenziell eine große Zahl falsch positiver Ergebnisse auftreten kann. Wir haben jedoch festgestellt, dass dies die wirksamste Methode zur Abwehr von Layer-7-DoS-Angriffen ist. NGINX App Protect DoS reduziert falsch positive Ergebnisse durch die Kombination mehrerer Ansätze: die Analyse des Benutzerverhaltens, die Überprüfung des Dienstzustands und die Messung der Wirksamkeit von Abwehrmaßnahmen. Zusammen bieten diese drei Ansätze umfassende Transparenz und Schutz, ohne dass Sie die Konfiguration als Reaktion auf Angriffe manuell ändern müssen.

Warum brauche ich Layer-7-DoS-Schutz, wenn ich bereits eine WAF habe?

Sie fragen sich vielleicht, warum Sie einen Layer-7-DoS-Schutz benötigen, wenn Ihre WAF bereits vor Bots schützt. Zwar werden Layer-7-DDoS-Angriffe in der Regel von Bots ausgeführt, doch verfolgen sie einen anderen Zweck als sonstige Bot-Aktivitäten. Bots versuchen üblicherweise, Informationen abzugreifen, ohne den Dienst zu beeinträchtigen. Bei Layer-7-DoS- und DDoS-Angriffen hingegen ist die Unterbrechung des Dienstes genau das Ziel.

Ein weiterer Unterschied besteht darin, dass herkömmliche Anti-Bot-Tools versuchen, zwischen „guten Bots“ und „bösartigen Bots“ zu unterscheiden – eine anspruchsvolle Aufgabe, die in der Regel menschliche Überwachung erfordert, um Fehlalarme zu vermeiden. NGINX App Protect DoS hingegen ist es gleichgültig, ob der Datenverkehr von Bots oder einem anderen Mechanismus erzeugt wird. Stattdessen konzentriert sich die Lösung darauf, Angreifer anhand ihres Verhaltens von legitimen Benutzern zu unterscheiden. Da NGINX App Protect DoS Anti-Bot-Techniken nur dann einsetzt, wenn festgestellt wurde, dass die Bots an einem Layer-7-DoS-Angriff beteiligt sind, erzeugt die Lösung deutlich weniger Fehlalarme als herkömmliche Anti-Bot-Software. Darüber hinaus sind die Abwehrmethoden von NGINX App Protect DoS CPU-effizient, sodass Ihre Anwendungen während eines Layer-DoS-Angriffs durchgehend geschützt werden können.

Fazit

NGINX App Protect DoS erfasst mehr als 320 Metriken zum Benutzer- und Anwendungsverhalten. Daraus entsteht ein multifaktorielles statistisches Modell, das einen höchstmöglichen Schutz bietet. Seine einzigartigen Algorithmen reduzieren Fehlalarme erheblich. Dank dieser Funktionen kann NGINX App Protect DoS stark verteilte DoS-Angriffe abwehren, bei denen jede einzelne Angriffsanfrage vollkommen legitim erscheint und ein einzelner Angreifer möglicherweise sogar weniger Datenverkehr verursacht als ein durchschnittlicher legitimer Benutzer. Mit seiner adaptiven Technologie schützt NGINX App Protect DoS moderne Infrastrukturen nicht nur vor heutigen Angriffen, sondern auch vor solchen, die sich künftig entwickeln werden.

Wenn Sie mehr darüber erfahren möchten, wie Sie den Schutz vor DoS-Angriffen gewährleisten können, lesen Sie unsere Lösungsübersicht. Weitere Informationen finden Sie auch in diesen themenverwandten Blogbeiträgen:

Testen Sie NGINX App Protect DoS selbst – starten Sie noch heute eine kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.


Teilen

Ähnliche Blogbeiträge

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
NGINX | 23.08.2022

Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln

Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
NGINX | 08.09.2021

Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen

Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
NGINX | 16.08.2021

Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet

Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
NGINX | 12.12.2018

Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77

Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.

Ankündigung von NGINX Plus R16
NGINX | 05.09.2018

Ankündigung von NGINX Plus R16

NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
NGINX | 13.10.2016

5 Gründe für den Umstieg auf softwarebasiertes Load Balancing

Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.