Schützen Sie Ihre gRPC-Apps mit NGINX App Protect DoS vor schwerwiegenden DoS-Angriffen

Die Kundennachfrage nach Waren und Dienstleistungen in den vergangenen zwei Jahren hat verdeutlicht, wie entscheidend es für Unternehmen ist, sich problemlos skalieren zu lassen und schneller Innovationen voranzutreiben. Dies hat viele von ihnen dazu veranlasst, den Umstieg von einer monolithischen auf eine cloudnative Architektur zu beschleunigen. Laut dem aktuellen F5-Bericht „The State of Application Strategy 2021“ ist die Zahl der Unternehmen, die ihre Anwendungen modernisieren, allein im vergangenen Jahr um 133 % gestiegen. Cloudfähige Anwendungen sind so konzipiert, dass sie modular und verteilt aufgebaut sind sowie automatisiert bereitgestellt und verwaltet werden. Eine bestehende monolithische Anwendung lässt sich zwar einfach per Lift-and-Shift migrieren, doch bietet dies weder bei den Kosten noch bei der Flexibilität Vorteile. Um das verteilte Modell von Cloud-Computing-Diensten optimal zu nutzen, ist ein modularer Ansatz erforderlich – hier kommen Microservices ins Spiel.

Microservices sind ein Architekturansatz, der es Entwicklern ermöglicht, eine Anwendung als eine Reihe schlanker Anwendungsdienste zu erstellen, die strukturell voneinander und von der zugrunde liegenden Plattform unabhängig sind. Jeder Microservice wird als eigenständiger Prozess ausgeführt und kommuniziert mit anderen Diensten über klar definierte und standardisierte APIs. Jeder Dienst kann von einem kleinen, unabhängigen Team entwickelt und bereitgestellt werden. Diese Flexibilität bietet Unternehmen größere Vorteile hinsichtlich Leistung, Kosten, Skalierbarkeit und der Fähigkeit, schnell Innovationen voranzutreiben.

Entwickler suchen ständig nach Möglichkeiten, die Effizienz zu steigern und die Bereitstellung von Anwendungen zu beschleunigen. APIs ermöglichen die Kommunikation zwischen Softwareanwendungen und stellen die Bausteine für die Entwicklung bereit. Um Daten über HTTP von Servern abzurufen, verwendeten Webentwickler ursprünglich SOAP, wobei die Details der Anfrage in einem XML-Dokument übermittelt werden. XML-Dokumente sind jedoch meist umfangreich, verursachen einen erheblichen Zusatzaufwand und ihre Entwicklung nimmt viel Zeit in Anspruch.

Viele Entwickler sind inzwischen zu REST übergegangen, einem Architekturstil und Regelwerk für die Erstellung zustandsloser, zuverlässiger Web-APIs. Eine Web-API, die diese Richtlinien befolgt, wird als RESTful bezeichnet. RESTful-Web-APIs basieren in der Regel auf HTTP-Methoden, um über URL-codierte Parameter auf Ressourcen zuzugreifen, und verwenden JSON oder XML zur Datenübertragung. Durch den Einsatz von RESTful-APIs lassen sich Anwendungen schneller und mit geringerem Aufwand entwickeln.

Technologische Fortschritte eröffnen neue Möglichkeiten, das Anwendungsdesign weiterzuentwickeln. Im Jahr 2015 entwickelte Google Google Remote Procedure Call (gRPC) als modernes Open-Source-RPC-Framework, das in jeder Umgebung ausgeführt werden kann. Während REST auf dem HTTP-1.1-Protokoll basiert und ein Anfrage-Antwort-Kommunikationsmodell verwendet, nutzt gRPC HTTP/2 für die Übertragung sowie ein Client-Antwort-Kommunikationsmodell, das mithilfe von Protokollpuffern (Protobuf) als Schnittstellenbeschreibungssprache (IDL) zur Beschreibung von Diensten und Daten implementiert wird. Protobuf dient zur Serialisierung strukturierter Daten und ist auf Einfachheit und Leistung ausgelegt. Beim Empfangen von Daten ist gRPC etwa siebenmal schneller als REST, beim Senden etwa zehnmal schneller. Dies ist auf die Effizienz von Protobuf und die Verwendung von HTTP/2 zurückzuführen. gRPC ermöglicht außerdem Streaming-Kommunikation und verarbeitet mehrere Anfragen gleichzeitig.

Für Entwickler ist die Entwicklung von Microservices mit gRPC aufgrund der geringen Latenz, der Unterstützung mehrerer Sprachen, der kompakten Datendarstellung und des Echtzeit-Streamings eine attraktive Alternative zur Verwendung von RESTful APIs. Dadurch eignet sich gRPC besonders für die Kommunikation zwischen Microservices sowie über Netzwerke mit geringem Energieverbrauch und niedriger Bandbreite. gRPC erfreut sich zunehmender Beliebtheit, da sich damit neue Dienste schnell und effizient sowie mit höherer Zuverlässigkeit und Skalierbarkeit entwickeln lassen und sowohl Clients als auch Server unabhängig von der verwendeten Programmiersprache sind.

Obwohl die Offenheit des gRPC-Protokolls einige Vorteile bietet, schützt der Standard eine Anwendung nicht vor den Auswirkungen eines DoS-Angriffs. Eine gRPC-Anwendung kann weiterhin von denselben Arten von DoS-Angriffen betroffen sein wie eine herkömmliche Anwendung.

Warum es schwierig ist, einen DoS-Angriff auf eine gRPC-App zu erkennen

Microservices und Container geben Entwicklern zwar mehr Freiheit und Autonomie, um Kunden schnell neue Funktionen bereitzustellen, schaffen jedoch zugleich neue Schwachstellen und Angriffsmöglichkeiten. Eine zunehmend verbreitete Art von Cyberangriffen sind Denial-of-Service-Angriffe (DoS), die in den letzten Jahren für eine wachsende Zahl allgemein bekannter Schwachstellen (Common Vulnerabilities and Exposures, CVEs) verantwortlich waren. Viele davon wurden durch die unsachgemäße Verarbeitung von gRPC-Anfragen verursacht. Die Zahl der Layer-7-DoS-Angriffe auf Anwendungen und APIs ist in den letzten Jahren um 20 % gestiegen, während Umfang und Schwere der Auswirkungen um fast 200 % zugenommen haben.

Bei einem DoS-Angriff werden in der Regel große Mengen scheinbar legitimen Datenverkehrs erzeugt, um die Ressourcen der Anwendung zu erschöpfen und sie dadurch funktionsunfähig zu machen. Bei einem typischen DoS-Angriff überflutet ein Angreifer eine Website oder Anwendung mit so viel Datenverkehr, dass die Server durch die Vielzahl der Anfragen überlastet werden und ins Stocken geraten oder sogar abstürzen. DoS-Angriffe zielen darauf ab, Computer oder Netzwerke zu verlangsamen oder vollständig lahmzulegen, sodass die darauf angewiesenen Personen nicht mehr darauf zugreifen können. Bis der Angriff abgewehrt ist, können Dienste, die von dem Computer oder Netzwerk abhängig sind – etwa E-Commerce-Websites, E-Mail-Dienste und Onlinekonten – nicht genutzt werden.

Zunehmend beobachten wir mehr DoS-Angriffe, bei denen HTTP- und HTTP/2-Anfragen oder API-Aufrufe für Angriffe auf der Anwendungsschicht (Layer 7) eingesetzt werden. Dies liegt vor allem daran, dass Layer-7-Angriffe herkömmliche Schutzmechanismen umgehen können, die nicht auf den Schutz moderner Anwendungsarchitekturen ausgelegt sind. Warum sind Angreifer von traditionellen volumetrischen Angriffen auf den Netzwerkschichten (Layer 3 und 4) zu Layer-7-Angriffen übergegangen? Sie wählen den Weg des geringsten Widerstands. Infrastrukturtechniker haben über Jahre hinweg wirksame Abwehrmechanismen gegen Angriffe auf Layer 3 und Layer 4 entwickelt, sodass diese leichter abzuwehren sind und geringere Erfolgsaussichten haben. Dadurch sind solche Angriffe sowohl finanziell als auch zeitlich aufwendiger, weshalb sich die Angreifer anderen Methoden zugewandt haben.

Die Erkennung von DoS-Angriffen auf gRPC-Anwendungen ist äußerst schwierig, insbesondere in modernen Umgebungen, in denen die horizontale Skalierung automatisch erfolgt. Ein gRPC-Dienst ist möglicherweise nicht für ein hohes Datenverkehrsaufkommen ausgelegt und daher ein leichtes Ziel für Angreifer, die ihn außer Betrieb setzen wollen. gRPC-Dienste sind außerdem anfällig für HTTP/2-Flood-Angriffe mit Tools wie h2load. Darüber hinaus können gRPC-Dienste leicht angegriffen werden, wenn der Angreifer Datendefinitionen ausnutzt, die ordnungsgemäß in einer Protobuf-Spezifikation deklariert sind.

Ein typischer, wenn auch unbeabsichtigter Missbrauch eines gRPC-Dienstes liegt vor, wenn ein Fehler in einem Skript dazu führt, dass übermäßig viele Anfragen an den Dienst gesendet werden. Angenommen, ein Automatisierungsskript führt beim Eintreten einer bestimmten Bedingung einen API-Aufruf aus, wobei die Entwickler davon ausgehen, dass dies alle zwei Sekunden geschieht. Aufgrund eines Fehlers bei der Definition der Bedingung führt das Skript den Aufruf jedoch alle zwei Millisekunden aus und belastet dadurch den gRPC-Dienst im Backend unerwartet stark.

Weitere Beispiele für DoS-Angriffe auf eine gRPC-Anwendung sind:

• Das Einfügen eines schädlichen Feldes in eine gRPC-Nachricht kann zum Ausfall der Anwendung führen.
• Bei einem Slow-POST-Angriff werden unvollständige Anfragen im gRPC-Header gesendet. In Erwartung des restlichen Teils der Anfrage hält die Anwendung oder der Server die Verbindung offen. Dadurch kann der Pool für gleichzeitige Verbindungen ausgelastet werden, sodass weitere Verbindungsversuche von Clients abgelehnt werden.
• Ein HTTP/2-Settings-Flood-Angriff (CVE-2019-9515), bei dem der Angreifer leere SETTING-Frames an das gRPC-Protokoll sendet, beansprucht die Ressourcen von NGINX, sodass keine neuen Anfragen mehr verarbeitet werden können.

Nutzen Sie die Leistungsfähigkeit der dynamischen Analyse des Benutzer- und Websiteverhaltens, um gRPC-DoS-Angriffe mit NGINX App Protect DoS abzuwehren

Der Schutz von Anwendungen vor heutigen DoS-Angriffen erfordert einen modernen Ansatz. Zum Schutz komplexer und anpassungsfähiger Anwendungen benötigen Sie eine Lösung, die auf Grundlage des Benutzer- und Websiteverhaltens einen hochpräzisen, dynamischen Schutz bietet, Sicherheitsteams entlastet und zugleich eine schnelle Anwendungsentwicklung sowie Wettbewerbsvorteile ermöglicht.

F5 NGINX App Protect DoS ist ein schlankes Softwaremodul für NGINX Plus, das auf der marktführenden WAF und dem verhaltensbasierten Schutz von F5 basiert. NGINX App Protect DoS wurde zur Abwehr selbst ausgefeiltester DoS-Angriffe auf Layer 7 entwickelt und erstellt mithilfe einzigartiger Algorithmen ein dynamisches statistisches Modell, das adaptives maschinelles Lernen und automatisierten Schutz ermöglicht. Die Lösung misst kontinuierlich die Wirksamkeit der Abwehrmaßnahmen, passt sich an Veränderungen im Benutzer- und Websiteverhalten an und führt proaktive Zustandsprüfungen der Server durch. Weitere Informationen finden Sie im Beitrag „Wie sich NGINX App Protect Denial of Service an die sich wandelnde Bedrohungslandschaft anpasst“ in unserem Blog.

Die Verhaltensanalyse wird sowohl für herkömmliche HTTP-Anwendungen als auch für Header moderner HTTP/2-Anwendungen bereitgestellt. NGINX App Protect DoS wehrt Angriffe sowohl anhand von Signaturen als auch durch die Identifizierung böswilliger Akteure ab. In der anfänglichen Phase der signaturbasierten Abwehr erstellt NGINX App Protect DoS Profile der mit anomalem Verhalten verbundenen Merkmale, um dynamische Signaturen zu erzeugen, die anschließend weitere Anfragen blockieren, die diesem Verhalten entsprechen. Hält der Angriff an, wechselt NGINX App Protect DoS in die Phase der Abwehr böswilliger Akteure.

Auf der Grundlage statistischer Anomalieerkennung identifiziert NGINX App Protect DoS Angreifer zuverlässig anhand ihrer Quell-IP-Adresse und TLS-Fingerabdrücke. Dadurch kann die Lösung dynamische Signaturen erstellen und bereitstellen, die diese spezifischen Muster im Angriffsverkehr automatisch erkennen und abwehren. Dieser Ansatz unterscheidet sich von herkömmlichen DoS-Lösungen auf dem Markt, die lediglich erkennen, wenn ein volumetrischer Schwellenwert überschritten wird. NGINX App Protect DoS kann Angriffe blockieren, bei denen die Anfragen völlig legitim erscheinen und jeder Angreifer möglicherweise sogar weniger Datenverkehr verursacht als ein durchschnittlicher legitimer Benutzer.

Die folgenden Kibana-Dashboards zeigen, wie NGINX App Protect DoS einen DoS-Flood-Angriff auf eine gRPC-Anwendung schnell und automatisch erkennt und abwehrt.

Abbildung 1 zeigt eine gRPC-Anwendung, die einem DoS-Überlastungsangriff ausgesetzt ist. Im Kontext von gRPC ist die entscheidende Metrik die Anzahl der Datagramme pro Sekunde (DPS), die der Nachrichtenrate pro Sekunde entspricht. In dieser Abbildung stellt die gelbe Kurve den Lernprozess dar: Wenn sich die Prognose für die DPS-Baseline dem Wert für die eingehenden DPS (in Blau) annähert, hat NGINX App Protect gelernt, wie der „normale“ Datenverkehr für diese Anwendung aussieht. Der starke Anstieg der DPS um 12:25:00 Uhr weist auf den Beginn eines Angriffs hin. Die rote Alarmglocke markiert den Zeitpunkt, an dem NGINX App Protect DoS mit hinreichender Sicherheit einen laufenden Angriff erkannt hat und die Abwehrphasen einleitet.

Abbildung 1: Eine gRPC-Anwendung, die einem DoS-Angriff ausgesetzt ist

Abbildung 2 zeigt, wie NGINX App Protect DoS anomales Verhalten erkennt und einen gRPC-DoS-Flood-Angriff mithilfe eines mehrstufigen Abwehransatzes vereitelt. Die rote Spitze gibt die Anzahl der HTTP/2-Weiterleitungen an, die während der globalen Phase zur Begrenzung der Anfragerate an alle Clients gesendet werden. Die violette Kurve stellt die Weiterleitungen dar, die an bestimmte Clients gesendet werden, wenn deren Anfragen mit einer Signatur übereinstimmen, die das anomale Verhalten abbildet. Die gelbe Kurve stellt die Weiterleitungen dar, die an bestimmte erkannte Angreifer gesendet werden, die anhand ihrer IP-Adresse und ihres TLS-Fingerabdrucks identifiziert wurden.

Abbildung 2: NGINX App Protect DoS nutzt einen mehrstufigen Abwehransatz, um einen gRPC-DoS-Flood-Angriff abzuwehren

Abbildung 3 zeigt eine von NGINX App Protect DoS erstellte dynamische Signatur, die auf maschinellem Lernen basiert und die mit dem anomalen Verhalten dieses gRPC-Flood-Angriffs verbundenen Merkmale erfasst. Die Signatur blockiert während der anfänglichen signaturbasierten Abwehrphase alle Anfragen, die mit ihr übereinstimmen.

Abbildung 3: Eine dynamische Signatur

Abbildung 4 zeigt, wie NGINX App Protect DoS bei einem anhaltenden Angriff von der signaturbasierten Abwehr zur Abwehr böswilliger Akteure übergeht. Durch die Analyse des Benutzerverhaltens hat NGINX App Protect DoS böswillige Akteure anhand der hier gezeigten Quell-IP-Adresse und TLS-Fingerabdrücke identifiziert. Anstatt jede Anfrage auf bestimmte Signaturen zu untersuchen, die auf anomales Verhalten hindeuten, wird hier gezielt bestimmten Angreifern der Dienst verweigert. Dadurch können dynamische Signaturen erstellt werden, die diese spezifischen Angriffsmuster erkennen und automatisch abwehren.

Abbildung 4: NGINX App Protect DoS identifiziert böswillige Akteure anhand von IP-Adresse und TLS-Fingerabdruck

Bei gRPC-APIs verwenden Sie die gRPC-Schnittstelle, um die Sicherheitsrichtlinie in der Typbibliotheksdatei (IDL) und den Proto-Definitionsdateien für Protobuf festzulegen. Dies ermöglicht eine Zero-Touch-Lösung für Sicherheitsrichtlinien – Sie müssen sich nicht auf die Protobuf-Definition verlassen, um den gRPC-Dienst vor Angriffen zu schützen. gRPC-Proto-Dateien werden häufig als Teil von CI/CD-Pipelines verwendet. Dadurch werden Sicherheits- und Entwicklungsteams aufeinander abgestimmt, indem der Schutz automatisiert und Security-as-Code für eine vollständige Integration in die CI/CD-Pipeline ermöglicht wird. NGINX App Protect DoS gewährleistet konsistente Sicherheit, indem der Schutz nahtlos in Ihre gRPC-Anwendungen integriert wird, sodass diese stets durch die neuesten und aktuellsten Sicherheitsrichtlinien geschützt sind.

gRPC bietet zwar die Geschwindigkeit und Flexibilität, die Entwickler für die Konzeption und Bereitstellung moderner Anwendungen benötigen, doch die inhärente Offenheit des Frameworks macht es äußerst anfällig für DoS-Angriffe. Um schwerwiegenden Layer-7-DoS-Angriffen einen Schritt voraus zu sein, die zu Leistungseinbußen, Ausfällen von Anwendungen und Websites, Umsatzeinbußen sowie einer Beeinträchtigung der Kundentreue und des Markenimages führen können, benötigen Sie einen modernen Schutz. Deshalb ist NGINX App Protect DoS für Ihre modernen gRPC-Anwendungen unverzichtbar.

Wenn Sie NGINX App Protect DoS mit NGINX Plus selbst ausprobieren möchten, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.

Weitere Informationen finden Sie in unserem Whitepaper „Moderne Anwendungen vor Layer-7-DoS-Angriffen schützen“.

---