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

Die Kundennachfrage nach Waren und Dienstleistungen hat in den letzten zwei Jahren unterstrichen, wie wichtig es für Unternehmen ist, problemlos zu skalieren und schneller zu innovieren. Dies hat viele von ihnen dazu veranlasst, den Wechsel von einer monolithischen zu einer Cloud-nativen Architektur zu beschleunigen. Laut dem aktuellen F5-Bericht „The State of Application Strategy 2021“ ist die Zahl der Organisationen, die Applications modernisieren, allein im letzten Jahr um 133 % gestiegen. Cloudfähige Applications sind modular aufgebaut, verteilt und werden automatisch bereitgestellt und verwaltet. Zwar ist es möglich, eine vorhandene monolithische Application einfach per Lift-and-Shift zu übernehmen, doch bietet dies keinerlei Kosten- oder Flexibilitätsvorteile. Der beste Weg, vom verteilten Modell der Cloud-Computing-Dienste zu profitieren, besteht darin, modular zu denken – und damit Microservices ins Spiel zu bringen.

Microservices ist ein Architekturansatz, der es Entwicklern ermöglicht, eine Application als eine Reihe leichtgewichtiger Application zu erstellen, die strukturell voneinander und von der zugrunde liegenden Plattform unabhängig sind. Jeder Microservice wird als einzigartiger Prozess ausgeführt und kommuniziert über gut definierte und standardisierte APIs mit anderen Services. 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 zur schnellen Innovation.

Entwickler suchen immer nach Möglichkeiten, die Effizienz zu steigern und die Application zu beschleunigen. APIs ermöglichen die Software-zu-Software- Kommunikation und stellen die Bausteine für die Entwicklung bereit. Um Daten von Servern über HTTP anzufordern, verwendeten Webentwickler ursprünglich SOAP , das Details der Anforderung in einem XML- Dokument sendet. XML-Dokumente sind jedoch in der Regel groß, erfordern einen erheblichen Mehraufwand und ihre Entwicklung dauert lange.

Viele Entwickler sind seitdem zu REST übergegangen, einem Architekturstil und Richtliniensatz zum Erstellen zustandsloser, zuverlässiger Web-APIs. Eine Web-API, die diese Richtlinien befolgt, wird als RESTful bezeichnet. RESTful-Web-APIs basieren normalerweise auf HTTP-Methoden für den Zugriff auf Ressourcen über URL-codierte Parameter und verwenden JSON oder XML zur Datenübertragung. Durch die Verwendung von RESTful APIs lassen sich Applications schneller entwickeln und verursachen weniger Aufwand.

Technologische Fortschritte bieten neue Möglichkeiten zur Weiterentwicklung des Application . Im Jahr 2015 entwickelte Google mit Google Remote Procedure Call ( gRPC ) ein 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 Request-Response-Kommunikationsmodell verwendet, nutzt gRPC HTTP/2 für den Transport und ein Client-Response-Kommunikationsmodell, das in Protokollpuffern (protobuf) als Schnittstellenbeschreibungssprache (IDL) implementiert ist und zur Beschreibung von Diensten und Daten verwendet wird. Protobuf wird zum Serialisieren strukturierter Daten verwendet und ist auf Einfachheit und Leistung ausgelegt. Aufgrund der Effizienz von Protobuf und der Verwendung von HTTP/2 ist gRPC beim Empfangen von Daten etwa 7-mal schneller als REST und beim Senden von Daten 10-mal schneller. gRPC ermöglicht auch Streaming-Kommunikation und bearbeitet mehrere Anfragen gleichzeitig.

Für Entwickler ist die Erstellung von Microservices mit gRPC eine attraktive Alternative zur Verwendung von RESTful APIs. Grund dafür sind die geringe Latenz, die Unterstützung mehrerer Sprachen, die kompakte Datendarstellung und das Echtzeit-Streaming. All diese Eigenschaften machen gRPC besonders geeignet für die Kommunikation zwischen Microservices und über Netzwerke mit geringem Stromverbrauch und geringer Bandbreite. gRPC erfreut sich zunehmender Beliebtheit, da es die schnelle und effiziente Erstellung neuer Services erleichtert, die zuverlässiger und skalierbarer ist und sowohl für Clients als auch für Server sprachunabhängig ist.

Obwohl die offene Natur des gRPC-Protokolls mehrere positive Vorteile bietet, bietet der Standard keinen Schutz vor den Auswirkungen, die ein DoS-Angriff auf eine Application haben kann. Eine gRPC Application kann immer noch unter den gleichen Arten von DoS-Angriffen leiden wie eine herkömmliche Application.

Warum das Erkennen eines DoS-Angriffs auf eine gRPC-App eine Herausforderung ist

Zwar geben Microservices und Container Entwicklern mehr Freiheit und Autonomie, um Kunden schnell neue Funktionen bereitzustellen, doch führen sie auch neue Schwachstellen und Möglichkeiten zur Ausnutzung ein. Eine Art von Cyberangriff, die immer beliebter wird, sind Denial-of-Service-Angriffe (DoS). In den letzten Jahren waren sie für eine zunehmende Zahl häufiger Schwachstellen und Gefährdungen (CVEs) verantwortlich, von denen viele auf die unsachgemäße Handhabung von gRPC-Anfragen zurückzuführen sind. Layer-7-DoS-Angriffe auf Applications und APIs haben in den letzten Jahren um 20 % zugenommen, während das Ausmaß und die Schwere der Auswirkungen um fast 200 % zugenommen haben.

Bei einem DoS-Angriff werden im Allgemeinen große Mengen legitim erscheinenden Datenverkehrs gesendet, um die Ressourcen der Anwendung zu erschöpfen und sie dazu zu bringen, nicht mehr zu reagieren. Bei einem typischen DoS-Angriff überflutet ein böswilliger Akteur eine Website oder Application mit so viel Datenverkehr, dass die Server mit all den Anfragen überlastet sind und ins Stocken geraten oder sogar abstürzen. DoS-Angriffe zielen darauf ab, Rechner oder Netzwerke zu verlangsamen oder komplett lahmzulegen, sodass sie für die Personen, die sie benötigen, unzugänglich werden. Bis der Angriff abgewehrt wird, sind Dienste, die von der Maschine oder dem Netzwerk abhängen – wie etwa E-Commerce-Sites, E-Mail und Online-Konten – nicht nutzbar.

Wir beobachten zunehmend mehr DoS-Angriffe, bei denen HTTP- und HTTP/2-Anfragen oder API-Aufrufe zum Einsatz kommen, um die Application (Layer 7) anzugreifen. Der Grund hierfür liegt größtenteils darin, dass Layer-7-Angriffe herkömmliche Abwehrmechanismen umgehen können, die nicht für den Schutz moderner Application konzipiert sind. Warum sind Angreifer von herkömmlichen volumetrischen Angriffen auf den Netzwerkebenen (Ebene 3 und 4) zu Angriffen auf Ebene 7 übergegangen? Sie folgen dem Weg des geringsten Widerstandes. Infrastrukturingenieure haben jahrelang wirksame Abwehrmechanismen gegen Layer-3- und Layer-4-Angriffe entwickelt, um diese leichter zu blockieren und ihre Erfolgschancen zu verringern. Das macht solche Angriffe sowohl finanziell als auch zeitaufwändiger, weshalb die Angreifer andere Methoden gewählt haben.

Das Erkennen von DoS-Angriffen auf gRPC Applications ist äußerst schwierig, insbesondere in modernen Umgebungen, in denen die Skalierung automatisch erfolgt. Ein gRPC-Dienst ist möglicherweise nicht für die Verarbeitung hohen Datenverkehrs ausgelegt und stellt daher für Angreifer ein leichtes Ziel dar. 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 es übermäßig viele Anfragen an den Dienst stellt. Angenommen, ein Automatisierungsskript gibt einen API-Aufruf aus, wenn eine bestimmte Bedingung eintritt, was nach Ansicht der Designer alle zwei Sekunden der Fall sein sollte. Aufgrund eines Fehlers bei der Definition der Bedingung gibt das Skript den Aufruf jedoch alle zwei Millisekunden aus, was zu einer unerwarteten Belastung des gRPC-Backend-Dienstes führt.

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

• Das Einfügen eines bösartigen Felds in eine gRPC-Nachricht kann zum Ausfall der Application führen.
• Ein langsamer POST- Angriff sendet Teilanforderungen im gRPC-Header. In Erwartung des Eintreffens des Rests der Anforderung halten die Application oder der Server die Verbindung offen. Der Pool gleichzeitiger Verbindungen kann voll werden, was dazu führt, dass weitere Verbindungsversuche von Clients abgelehnt werden.
• Eine HTTP/2-Settings-Flood ( CVE-2019-9515 ) , bei der der Angreifer leere SETTING- Frames an das gRPC-Protokoll sendet, verbraucht NGINX-Ressourcen, sodass keine neuen Anfragen bearbeitet werden können.

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

Applications vor heutigen DoS-Angriffen zu schützen, ist ein moderner Ansatz erforderlich. Zum Schutz komplexer und adaptiver Applications benötigen Sie eine Lösung, die hochpräzisen, dynamischen Schutz auf der Grundlage des Benutzer- und Site-Verhaltens bietet, die Sicherheitsteams entlastet und gleichzeitig eine schnelle Application und Wettbewerbsvorteil unterstützt.

F5 NGINX App Protect DoS ist ein leichtes Softwaremodul für NGINX Plus, das auf dem marktführenden WAF und Verhaltensschutz von F5 basiert. NGINX App Protect DoS wurde zum Schutz vor selbst den raffiniertesten Layer-7-DoS-Angriffen entwickelt und verwendet einzigartige Algorithmen zur Erstellung eines dynamischen statistischen Modells, das adaptives maschinelles Lernen und automatisierten Schutz bietet. Es misst kontinuierlich die Effektivität der Schadensbegrenzung, passt sich an verändertes Benutzer- und Site-Verhalten an und führt proaktive Server-Integritätsprüfungen durch. Ausführliche Informationen finden Sie in unserem Blog unter „So passt sich NGINX App Protect Denial of Service an die sich entwickelnde Angriffslandschaft an“ .

Verhaltensanalysen werden sowohl für herkömmliche HTTP-Apps als auch für moderne HTTP/2-App-Header bereitgestellt. NGINX App Protect DoS mildert Angriffe auf der Grundlage von Signaturen und der Identifizierung böswilliger Akteure. In der anfänglichen Signaturminderungsphase profiliert NGINX App Protect DoS die mit anomalem Verhalten verbundenen Attribute, um dynamische Signaturen zu erstellen, die dann in Zukunft Anfragen blockieren, die diesem Verhalten entsprechen. Wenn der Angriff anhält, wechselt NGINX App Protect DoS in die Phase der Eindämmung des Übeltäters.

Auf der Grundlage statistischer Anomalieerkennung identifiziert NGINX App Protect DoS böswillige Akteure erfolgreich anhand der Quell-IP-Adresse und TLS-Fingerabdrücke. Dadurch kann das Programm dynamische Signaturen generieren und bereitstellen, die diese spezifischen Muster des Angriffsverkehrs automatisch identifizieren und abschwächen. Dieser Ansatz unterscheidet sich von herkömmlichen DoS-Lösungen auf dem Markt, die erkennen, wenn ein Volumenschwellenwert überschritten wird. NGINX App Protect DoS kann Angriffe blockieren, bei denen die Anfragen völlig legitim aussehen und jeder Angreifer möglicherweise sogar weniger Datenverkehr erzeugt als der durchschnittliche legitime Benutzer.

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

Abbildung 1 zeigt eine gRPC- Application , die einem DoS-Flood-Angriff ausgesetzt ist. Im Kontext von gRPC ist die kritische Metrik „Datagramme pro Sekunde“ (DPS), was der Nachrichtenrate pro Sekunde entspricht. In diesem Bild stellt die gelbe Kurve den Lernprozess dar: Wenn die Baseline-DPS -Vorhersage dem Incoming-DPS- Wert (in Blau) entgegenkonvergiert, hat NGINX App Protect gelernt, wie „normaler“ Datenverkehr für diese Application aussieht. Der starke Anstieg des DPS um 12:25:00 zeigt den Beginn eines Angriffs an. Die rote Alarmglocke zeigt den Zeitpunkt an, an dem NGINX App Protect DoS davon überzeugt ist, dass ein Angriff im Gange ist, und mit den Abwehrphasen beginnt.

Abbildung 2 zeigt NGINX App Protect DoS beim Erkennen von anomalem Verhalten und Vereitelung eines gRPC-DoS-Flood-Angriffs mithilfe eines stufenweisen Minderungsansatzes. Die rote Spitze gibt die Anzahl der HTTP/2-Weiterleitungen an, die während der globalen Rate-Mitigationsphase an alle Clients gesendet wurden. Das violette Diagramm stellt die Umleitungen dar, die an bestimmte Clients gesendet werden, wenn ihre Anforderungen mit einer Signatur übereinstimmen, die das anomale Verhalten modelliert. Das gelbe Diagramm stellt die Weiterleitungen dar, die an bestimmte erkannte böswillige Akteure gesendet wurden, die anhand ihrer IP-Adresse und ihres TLS-Fingerabdrucks identifiziert wurden.

Abbildung 3 zeigt eine dynamische Signatur, die von NGINX App Protect DoS erstellt wurde. Sie basiert auf maschinellem Lernen und erstellt ein Profil der Attribute, die mit dem anomalen Verhalten dieses gRPC-Flood-Angriffs verbunden sind. Die Signatur blockiert während der anfänglichen Signaturminderungsphase Anfragen, die mit ihr übereinstimmen.

Abbildung 4 zeigt, wie NGINX App Protect DoS von der signaturbasierten Schadensbegrenzung zur Schadensbegrenzung durch böswillige Akteure übergeht, wenn ein Angriff anhält. Durch die Analyse des Benutzerverhaltens hat NGINX App Protect DoS böswillige Akteure anhand der hier angezeigten Quell-IP-Adresse und der TLS-Fingerabdrücke identifiziert. Anstatt jede Anfrage auf bestimmte Signaturen zu prüfen, die auf anomales Verhalten hinweisen, wird hier bestimmten Angreifern der Dienst verweigert. Dadurch können dynamische Signaturen erstellt werden, die diese spezifischen Angriffsmuster identifizieren und automatisch abschwächen.

Mit gRPC-APIs verwenden Sie die gRPC-Schnittstelle, um die Sicherheitsrichtlinie in der Typbibliotheksdatei (IDL) und den Protodefinitionsdateien für Protobuf festzulegen. Dies bietet eine Zero-Touch-Sicherheitsrichtlinienlösung – Sie müssen sich nicht auf die Protobuf-Definition verlassen, um den gRPC-Dienst vor Angriffen zu schützen. gRPC-Protodateien werden häufig als Teil von CI/CD-Pipelines verwendet. Sie stimmen Sicherheits- und Entwicklungsteams aufeinander ab, indem sie den Schutz automatisieren und Sicherheit als Code für eine vollständige CI/CD-Pipeline-Integration ermöglichen. NGINX App Protect DoS gewährleistet konsistente Sicherheit durch nahtlose Integration des Schutzes in Ihre gRPC- Applications , sodass diese immer durch die neuesten und aktuellsten Sicherheitsrichtlinien geschützt sind.

Zwar bietet gRPC die Geschwindigkeit und Flexibilität, die Entwickler zum Entwerfen und Bereitstellen moderner Applications benötigen, aufgrund der inhärenten offenen Natur seines Frameworks ist es jedoch äußerst anfällig für DoS-Angriffe. Um schweren Layer-7-DoS-Angriffen einen Schritt voraus zu sein, die zu Leistungseinbußen, Application und Website-Ausfällen, Umsatzeinbußen und einer Schädigung der Kundentreue und der Marke führen können, benötigen Sie eine moderne Verteidigung. Deshalb ist NGINX App Protect DoS für Ihre modernen gRPC- Applications unverzichtbar.

Um NGINX App Protect DoS mit NGINX Plus selbst auszuprobieren, 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 „ Sichern moderner Apps gegen Layer-7-DoS-Angriffe“ .