NGINX App Protect Denial of Service blockiert DoS-Angriffe auf Anwendungsebene

NGINX | 06. Juli 2021

Während die digitale Transformation das Geschäftspotenzial steigert, vergrößert sie leider zugleich die Bedrohungslandschaft. Da Sicherheitsteams damit beschäftigt sind, sich an ihren wachsenden Aufgaben- und Verantwortungsbereich anzupassen, nutzen Angreifer dies aus und gehen beim Missbrauch von Anwendungen zur finanziellen Bereicherung raffinierter vor als je zuvor. Im Vergleich zu herkömmlichen Denial-of-Service-Angriffen (DoS) auf Netzwerkebene nehmen DoS-Angriffe auf Anwendungsebene (Layer 7) stark zu. Das liegt vor allem daran, dass sie herkömmliche Abwehrmaßnahmen umgehen können, die nicht für moderne Anwendungsarchitekturen ausgelegt sind.

Aus Sicht der Angreifer bieten Layer-7-DoS-Angriffe zwei entscheidende Vorteile: Sie benötigen nur sehr wenige Ressourcen, um erhebliche Störungen zu verursachen, und sind schwer zu erkennen. Solche Angriffe werden mithilfe ausgefeilter Tools und präzise ausgerichteter Anfragen durchgeführt. Sie stören Anwendungsserver und APIs, sodass diese keine legitimen Anfragen mehr verarbeiten können. Wird ein Server mit mehr Anfragen bombardiert, als er verarbeiten kann, verwirft er legitime Anfragen, reagiert nicht mehr oder stürzt sogar ab.

Herkömmliche Lösungen zur Abwehr von DoS-Angriffen sind für moderne Anwendungen nicht geeignet. Sie bieten statische, regelbasierte Sicherheit und müssen kontinuierlich gepflegt werden, um mit den schnellen Änderungen und Aktualisierungen moderner Anwendungslandschaften Schritt zu halten.

Einführung in NGINX App Protect DoS

NGINX App Protect Denial of Service (DoS) ist ein neues, schlankes dynamisches Modul für NGINX Plus, das moderne Anwendungen vor den ausgefeiltesten DoS-Angriffen auf Anwendungsebene schützt. NGINX App Protect DoS wehrt Angriffe ab, die darauf abzielen, Anwendungen zu stören und zu schädigen. So gewährleistet es eine kontinuierliche Leistung und Umsatzgenerierung und trägt dazu bei, die Kundentreue und den Markenwert in einer hart umkämpften digitalen Welt zu bewahren.

NGINX App Protect DoS kann in der Nähe von Anwendungen und Microservices auf jeder Plattform, Architektur oder Umgebung bereitgestellt werden, einschließlich Kubernetes-Clustern. Es lässt sich gemeinsam mit der Anwendung horizontal skalieren und gewährleistet jederzeit eine hohe Sicherheitswirksamkeit.

NGINX App Protect DoS im Einsatz

Anwendungsfälle für die Bereitstellung

NGINX App Protect DoS kann an verschiedenen Stellen bereitgestellt werden, um Anwendungsdienste zu schützen:

  • Edge – Externe Load Balancer und Proxys
  • Ingress-Controller – Einstiegspunkt in Kubernetes
  • Dienstspezifischer Proxy – Interne Dienst-Proxy-Ebene
  • Proxy pro Pod – Im Pod eingebetteter Proxy
  • API-Gateway – Einstiegspunkt für Microservices

Abgewehrte Angriffsarten

NGINX App Protect DoS bietet Schutz vor mehreren komplexen Angriffsarten:

  • GET- und POST-Flood-Angriffe – (sowohl HTTP als auch HTTPS) Der Angreifer versucht, den Server oder die API mit einer großen Anzahl von Anfragen zu überlasten, sodass keine Anfragen echter Benutzer mehr beantwortet werden können.
  • „Slow“-Angriffe – (sowohl HTTP als auch HTTPS) „Slow-and-Low“-Angriffe binden Serverressourcen, sodass keine Kapazitäten mehr für die Bearbeitung von Anfragen tatsächlicher Benutzer verfügbar sind. Zwei Faktoren erschweren die Abwehr solcher Angriffe: Es gibt drei Hauptarten von „Slow“-Angriffen:
    • Im Gegensatz zu DDoS-Angriffen auf Netzwerkebene beanspruchen sie keine große Bandbreite, sodass sie nur schwer von normalem Datenverkehr zu unterscheiden sind.
    • Für ihre Durchführung sind nur wenige Ressourcen erforderlich, sodass mithilfe ausgefeilter Automatisierungstools Tausende von Anfragen von einem einzigen Computer aus gesendet werden können.
    • Slowloris – Der Angreifer stellt eine Verbindung zum Server her und sendet unvollständige Anfrage-Header in langsamem Tempo. Der Server hält die Verbindung offen, während er auf die restlichen Header wartet, wodurch der Pool der für tatsächliche Benutzer verfügbaren Verbindungen erschöpft wird.
    • Slow Read – Der Angreifer sendet eine korrekt formatierte HTTP-Anfrage, liest die Antwort anschließend jedoch nur sehr langsam oder gar nicht. Dadurch werden nach und nach Serverressourcen belegt, sodass legitime Anfragen nicht mehr verarbeitet werden können.
    • Langsamer POST – Der Angreifer sendet legitime HTTP-POST-Header an den Server, einschließlich einer korrekten Angabe der Größe des nachfolgenden Nachrichtentexts. Anschließend sendet er den Nachrichtentext sehr langsam. Da die Nachricht gültig zu sein scheint, hält der Server die Verbindung offen und wartet darauf, dass der vollständige Nachrichtentext eintrifft. Eine große Anzahl langsamer POST-Angriffe erschöpft den Pool der für tatsächliche Benutzer verfügbaren Verbindungen.
  • Verteilte Varianten der zuvor beschriebenen Angriffe – Durch den Einsatz mehrerer Computer lässt sich natürlich problemlos eine größere Anzahl gleichzeitiger Angriffe durchführen. Zudem kann das Datenverkehrsvolumen jedes einzelnen Computers relativ gering sein, sodass es dem eines normalen Benutzers ähnelt. Computer können außerdem aus dem Angriffspool ausscheiden und später wieder hinzukommen, wodurch sich die Gruppe der Quell-IP-Adressen ständig ändert. Diese Merkmale des Datenverkehrs beeinträchtigen die Wirksamkeit herkömmlicher Abwehrtechniken wie Ratenbegrenzung und Geoblocking.
  • Challenge-Collapsar-Angriff/zufällige URIs – Bei einem Challenge-Collapsar-Angriff (CC-Angriff) sendet der Angreifer häufig Anfragen, die grundsätzlich normal sind, bei denen die angeforderten URIs jedoch die Ausführung komplexer und damit zeitaufwendiger Algorithmen oder Datenbankoperationen erfordern. Dadurch können die Ressourcen des angegriffenen Servers erschöpft werden. Der Angreifer kann außerdem URIs und andere HTTP-Parameter so zufällig variieren, dass herkömmliche Abwehrtools wie statische Regeln umgangen werden. NGINX App Protect DoS setzt stattdessen auf fortschrittliche Algorithmen für maschinelles Lernen, die die Wirksamkeit erheblich steigern und die Zahl der Fehlalarme reduzieren.

​

  • Verbergen hinter NAT – Der Angreifer nutzt Verschlüsselung oder Netzwerkadressübersetzung (NAT), um der Erkennung zu entgehen. Der Versuch, Angriffe ausschließlich anhand der Quell-IP-Adresse zu erkennen, ist wirkungslos, da dadurch alle NAT-Benutzer als Angreifer eingestuft werden, selbst wenn nur ein Benutzer einen Angriff ausführt. NGINX App Protect DoS verwendet Fingerprinting für IPv4, um böswillige Akteure hinter NAT präzise zu erkennen. Da der Großteil des Datenverkehrs mit SSL/TLS verschlüsselt ist, kann der Schlüssel zur Identifizierung eines Akteurs von der reinen IP-Adresse auf eine Kombination aus IP-Adresse und TLS-Fingerabdruck erweitert werden (wobei der Fingerabdruck auf der TLS-Hello-Nachricht basiert).
  • Gezielte SSL/TLS-Angriffe – Der Angreifer missbraucht das SSL/TLS-Handshake-Protokoll. Eine gängige Methode besteht darin, unbrauchbare Daten an den angegriffenen SSL/TLS-Server zu senden. Die Verarbeitung einer ungültigen Nachricht ist genauso rechenintensiv wie die einer legitimen Nachricht, liefert jedoch kein verwertbares Ergebnis. Die meisten Firewalls helfen in diesem Fall nicht, da sie nicht zwischen gültigen und ungültigen SSL/TLS-Handshake-Paketen unterscheiden können und die Implementierung einer Entschlüsselung auf einer Firewall zu kostspielig ist. NGINX App Protect DoS verwendet einen Mechanismus für SSL/TLS-Signaturen, um auf Grundlage der unverschlüsselten CLIENT HELLO-Nachricht, die bereits früh im SSL/TLS-Handshake-Prozess übertragen wird, eine anomaliebasierte Erkennung und Abwehr zu ermöglichen. Dadurch entfallen die hohen Kosten der Entschlüsselung. Darüber hinaus ermöglichen SSL/TLS-Signaturen in Verbindung mit einem Mechanismus zur Überwachung des Serverzustands den DoS-Schutz und die Abwehr von Angriffen ohne SSL/TLS-Terminierung.

Zusammenfassung

DoS-Angriffe richten sich zunehmend gegen Anwendungen statt gegen das Netzwerk. Da viele dieser Layer-7-DoS-Angriffe wie legitimer Datenverkehr aussehen, können herkömmliche WAF-Schutzmechanismen sie nicht zuverlässig erkennen.

Darüber hinaus nutzen Angreifer weiterhin neue Technologien wie maschinelles Lernen und KI, um Layer-7-DoS-Angriffe zu starten, wodurch einfache Regeln und statische Signaturen an Wirksamkeit verlieren. Auch die Abwehr von Layer-7-DoS-Angriffen muss sich weiterentwickeln. NGINX App Protect DoS setzt dafür mit adaptiven und dynamischen Schutzmechanismen auf die richtige Technologie.

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

Über den Autor

Ä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.