Schutz Ihrer Anwendungen vor Layer-7-DoS-Angriffen mit NGINX App Protect Denial of Service

NGINX | 09. September 2021

Die Benutzererfahrung ist das A und O. Apps und Websites sind sinnlos, wenn Verbraucher und Kunden sie nicht nutzen. Daher ist es wichtig, eine positive und konsistente Benutzererfahrung zu gewährleisten – insbesondere, da Nutzer immer weniger Verständnis für Latenzen, Ausfallzeiten und Fehler haben.

Wenn Nutzer mit Ihrer App oder Website negative Erfahrungen machen, verlieren Sie sie möglicherweise für immer als Kunden. In einer Salesforce-Umfrage gaben 61 % der Verbraucher an, nach nur einer schlechten Erfahrung zu einem Wettbewerber gewechselt zu sein. Wiederholt sich die schlechte Erfahrung, ist die Abwanderung unvermeidlich. Markentreue hat nur begrenzten Einfluss, wenn online so viele Alternativen zur Auswahl stehen.

Eine der Hauptursachen für die Unzufriedenheit von Verbrauchern sind Ausfallzeiten, wobei Denial-of-Service-Angriffe (DoS) maßgeblich zu länger anhaltenden Ausfällen beitragen. Durch Veränderungen im Anwendungsdesign sind neue Bedrohungsvektoren entstanden, und Angreifer haben die seit über zwei Jahrzehnten eingesetzten DoS-Angriffe angepasst, um moderne Architekturen auszunutzen. Zwischen Januar 2020 und März 2021 nahmen DoS-Angriffe auf der Anwendungsebene (Layer 7) stark zu und machten 16 % aller DDoS-Vorfälle aus. Tatsächlich betrifft die Hälfte der Anfragen an das F5 Security Incident Response Team die Unterstützung bei DoS-Angriffen auf der Anwendungsebene.

Eine zentralisierte Abwehr kann bei volumetrischen DoS-Angriffen auf der Netzwerkschicht (Layer 4) wirksam sein. DoS-Angriffe auf der Anwendungsschicht sind jedoch gezielter und erfordern daher spezielle Schutzmaßnahmen für moderne Anwendungen, die zunehmend verteilt sind, aus APIs und Microservices bestehen und auf flexibleren Infrastrukturen wie der Cloud ausgeführt werden.

Über traditionelle Schutzmaßnahmen hinaus

Selbst wenn die Quelle eines DoS-Angriffs verteilt ist (wodurch er zu einem DDoS-Angriff wird), richten sich einfache volumetrische Angriffe auf der Netzwerkebene in der Regel gegen ein einzelnes Gerät oder einen einzelnen Dienst. Herkömmliche Schutzlösungen sind ähnlich monolithisch und zentralisiert. Diese Lösungen haben in der Anwendungssicherheit zwar nach wie vor ihre Berechtigung, reichen jedoch nicht aus. Cloudbasierte DDoS-Schutzdienste sind heute Branchenstandard. Sie tragen jedoch weiterhin nicht der Tatsache Rechnung, dass Anwendungen keine monolithischen Einzeldienste mehr sind, sondern über zahlreiche Integrationspunkte verfügen, die geschützt werden müssen.

Vor der digitalen Transformation und dem damit einhergehenden umfassenden Architekturwandel hin zu APIs, Microservices und cloudbasierten Integrationen konnte eine einfache Web Application Firewall (WAF) die Ausnutzung von Schwachstellen und DoS-Angriffe weitgehend abwehren. Bei einem volumetrischen Angriff, der sich beispielsweise als Überflutung auf der Clientseite äußert, sind eine einfache WAF und herkömmliche DoS-Schutzlösungen wirksam, da der Datenverkehr zentralisiert ist: Ein cloudbasierter Scrubbing-Dienst kann Angriffe abwehren, bevor der Datenverkehr die Eingangsleitungen erreicht, oder der Schutz kann vor dem Anwendungs-Stack platziert werden. Einfache WAFs schützen auch weiterhin vor herkömmlichen Angriffen, vor allem durch Ratenbegrenzung, Sperrlisten und Bot-Signaturen. Die Bedrohungslandschaft hat sich jedoch inzwischen weiterentwickelt.

Kurz gesagt: Die Spielregeln haben sich geändert, und einfache WAFs sowie herkömmliche DoS-Schutzmaßnahmen sind bei modernen Anwendungsarchitekturen nicht wirksam.

Moderne DoS-Angriffe finden auf Layer 7 statt. Da sie in verschlüsselten Kanälen verborgen sind und auf die Anwendungslogik abzielen, sind sie weitaus schwieriger zu erkennen. Daher benötigen Sie eine zusätzliche Schutzebene, um das Clientverhalten und die Serverauslastung zu messen – die beiden wichtigsten Indikatoren für einen DoS-Angriff.

Um dieses Problem anzugehen, haben wir kürzlich das Modul NGINX App Protect Denial of Service veröffentlicht. Vielleicht fragen Sie sich, ob Sie ein DoS-Modul benötigen, wenn Sie bereits über eine WAF und herkömmlichen DoS-Schutz verfügen. Das ist tatsächlich der Fall – lesen Sie weiter, um zu erfahren, warum.

Moderne Architekturen brauchen modernen Schutz

Verschlüsselung ist allgegenwärtig, und herkömmlicher DoS-Schutz wurde nicht für die Entschlüsselung in großem Maßstab konzipiert. In der Ära monolithischer Anwendungen war eine zentralisierte DoS-Abwehr sinnvoll, da Verschlüsselung noch nicht so weit verbreitet war und Angriffe weitgehend allein durch die Betrachtung der Clientseite erkannt werden konnten. Heute ist nahezu der gesamte Datenverkehr verschlüsselt. Daher ist eine zustandslose DoS-Abwehr, die sich ausschließlich auf eingehenden Datenverkehr konzentriert, weitgehend wirkungslos – insbesondere dann, wenn ein Angriff mit einer einzigen gezielten Anfrage die Anwendung stark belastet.

Anwendungen werden heute für verteilte Architekturen wie Microservices konzipiert und optimiert. Gleichzeitig setzt sich die Ende-zu-Ende-Verschlüsselung immer stärker durch – dank der zunehmenden Bedeutung des Schutzes der Privatsphäre von Nutzern (und der daraus resultierenden Gesetzgebung) sowie der Fortschritte in der Kryptografie. Moderne Architekturen sind in hohem Maße auf APIs angewiesen, und die Kommunikation zwischen APIs (auch als „Ost-West-Datenverkehr“ bezeichnet) durchläuft unter Umständen nicht einmal zentrale Sicherheitskontrollen.

Ein wirksamer DoS-Schutz auf Anwendungsebene erfordert durchgängige Transparenz und Kontextinformationen, einschließlich der Fähigkeit, clientseitige Anomalien und serverseitige Überlastungen zu erkennen. Fortschrittliche DoS-Angriffe auf Layer 7 tarnen sich häufig als legitimer Datenverkehr, sodass grundlegende Schutzmaßnahmen wie Ratenbegrenzung, Sperrlisten, Signaturen und Protokollkonformitätsprüfungen nicht mehr ausreichen.

Ausgefeilte Layer-7-Angriffe wirken auf den ersten Blick wie legitimer Datenverkehr, und einfachen WAFs fehlt die für ihre Erkennung erforderliche Verhaltensanalyse. NGINX App Protect DoS wurde speziell dafür entwickelt, sowohl Anomalien auf Clientseite als auch die Serverauslastung zu untersuchen. Die Lösung kann Angriffe dynamisch erkennen und abwehren sowie die Wirksamkeit der Abwehrmaßnahmen messen, ohne die bereits überlasteten Sicherheitsteams zusätzlich zu beanspruchen.

Wenn Sie sich ausschließlich auf grundlegende WAF-Schutzmaßnahmen und herkömmliche DDoS-Abwehr verlassen, fehlt Ihnen der nötige Einblick und Kontext, um einen Layer-7-Angriff richtig einzuschätzen. Die möglichen Folgen sind gravierend: hohe Latenz, Ausfallzeiten, entgangene Umsätze und eine Schädigung der Marke. Mithilfe von Verhaltensanalysen können Client-Anomalien und der Zustand von Diensten kontinuierlich analysiert werden, um Zero-Day-DoS-Angriffe zu erkennen. Durch eine genaue Untersuchung des Verhaltens einer Website lassen sich Fragen wie die folgenden beantworten: Gibt es im Vergleich zu den üblichen Datenverkehrsmustern Auffälligkeiten? Fehlen in der Anfrage Informationen, die ein Browser normalerweise übermittelt, obwohl sie scheinbar von einem Browser stammt? Enthält die Anfrage eine komplexe Datenbankabfrage, die eine hohe CPU-Auslastung verursacht?

Durch die Erstellung eines Bildes der normalen Leistung und des normalen Verhaltens kann NGINX App Protect DoS gezielt Layer-7-Angriffe abwehren, die herkömmliche Schutzmaßnahmen umgehen und Anwendungen stark belasten.

Diagramm mit acht Arten von Angriffen, die von NGINX App Protect WAF und DoS blockiert werden

Mit mehreren Modulen abwehren

Die Folgen von DoS-Angriffen sind unverändert: langsame Performance, frustrierte Nutzer und entgangene Umsätze. Die Art und Weise, wie DoS-Angriffe erfolgen, kann jedoch sehr unterschiedlich sein. Hacker nutzen Verschlüsselungs- und Sicherheitstools, um ihre Bedrohung als legitimen Datenverkehr zu tarnen.

Auch wenn Ihre Benutzer möglicherweise keinen Unterschied zwischen verschiedenen Architekturen erkennen, bemerken sie sehr wohl den Unterschied zwischen einer guten und einer schlechten Website-Performance. Massive Mengen an Angriffs-Traffic verursachen Latenzen, durch die sich die Nutzung der Website langsam anfühlt. Ist sie langsam genug, brechen selbst die geduldigsten Benutzer (und davon gibt es nicht viele!) die Transaktion ab und wechseln zu einer anderen Website. Bereits eine einzige gezielte Anfrage kann Latenzen verursachen und den Server belasten. Daher ist ein spezieller DoS-Schutz für Anwendungen unerlässlich.

Sicherheitslösungen für Webanwendungen werden kontinuierlich weiterentwickelt, um mit neuen Angriffen Schritt zu halten, wie sie beispielsweise in OWASP Automated Threats to Web Applications beschrieben werden. Sie benötigen jedoch einen Schutz, der nativ in die Laufzeitumgebung Ihrer Anwendung integriert ist. Eine dynamische Lösung. Eine anpassungsfähige Lösung. Während andere DoS-Lösungen möglicherweise für DDoS-Angriffe auf Netzwerkebene wie SYN-Floods konzipiert sind, ist die DoS-Lösung von NGINX App Protect speziell auf Angriffe auf Layer 7 ausgelegt, die Anwendungsressourcen stark beanspruchen. Die Kombination aus WAF- und Layer-7-DoS-Lösungen stellt sicher, dass Anwendungen sowohl vor der Ausnutzung von Schwachstellen als auch vor dem Missbrauch der Geschäftslogik geschützt sind. So werden Kompromittierungen ebenso verhindert wie Latenzen, Leistungseinbußen und Ausfallzeiten.

Der Handel findet heute größtenteils online statt. Auch die Menschen sind heute überwiegend online. Sie müssen dafür sorgen, dass sie sich dort sicher und geschützt bewegen können. Durch die Kombination der Module NGINX App Protect WAF und NGINX App Protect DoS erhalten Sie einen robusten Schutz, der optimal auf Ihre Umgebung, Anwendungen und Geschäftsanforderungen abgestimmt ist.

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


Teilen

Über die Autoren

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