Wenn die DoS-Attacke von innen kommt

Verteilte Architekturen für Web-Applikationen (µService-Architekturen) sind gefragt. Allerdings sind solche Systeme ohne präventive Maßnahmen häufig anfälliger für (D)DoS-Attacken bzw. Überlastungen als monolithische Dinosaurier. Aber warum ist das so? Am folgenden Beispiel wird dies schnell deutlich.

Bei einem Denial-of-Service (DoS)-Angriff wird ein Dienst solange mit einer großen Zahl von Anfragen geflutet, bis dieser wegen Überlastung schließlich ausfällt. Distributed Denial-of-Service (DDoS)-Angriffe sind darüber hinaus, in Erweiterung zu DoS-Attacken, Angriffe, die gleichzeitig von vielen verteilten Rechnern aus gestartet werden – und dementsprechend nicht so einfach über z. B. das Sperren der Quelle (bzw. deren IP) abgewehrt werden können.

Klassische Web-Applikationen und E-Commerce-Systeme sind meist noch monolithische Anwendungen. Das heißt: Eine Software steht hinter allen Funktionalitäten und liefert somit alle Seiten und Informationen an den Benutzer aus. Wenn ein solches System angegriffen wird und in der Folge dann ausfällt, ist jegliches Arbeiten am System nicht mehr möglich. Auch nebenläufige Prozesse wie Auftragsbearbeitung, Zahlungsverarbeitung oder die Redaktion neuer Inhalte und Produkte funktionieren dann nicht mehr. In verteilten Architekturen gibt es jeweils eigene Software-Komponenten für dedizierte Aufgaben, wie beispielsweise Preise, Verfügbarkeit, Bildbearbeitung, Produktdarstellung, Customer-Self-Care, Login und Nutzerverwaltung, Produktdatenhaltung, Auftragsabwicklung, Checkout-Strecke und CMS. Die Vorteile solcher verteilten Architekturen liegen somit auf der Hand: Übernimmt ein Angreifer die Kontrolle über eine Komponente hat er nicht automatisch gleich Zugriff auf die Daten der anderen. Überlastet er diese, bleibt die Funktionalität der Anderen erhalten. Darüber hinaus ist die Code-Basis einzelner Komponenten kleiner und somit leichter unabhängig von den restlichen Elementen zu warten. Außerdem lassen sich die einzelnen Bereiche der Plattform zielgenauer und bedarfsgerechter skalieren.

Auf den ersten Blick scheint es also so, als seien die modernen, verteilten Architekturen viel besser dazu geeignet, (D)DoS-Angriffen zu begegnen als klassische, monolithische Architekturen. Warum das nicht so sein muss, erläutern wir anhand eines in der nachfolgenden Grafik dargestellten (Zusammenhänge vernachlässigenden) Beispiels einer Produkt-Listen-Seite.

In einer monolithischen Applikation mit nur einer Datenbank können all diese Informationen mittels etwa 25-30 Anfragen über eine persistente Verbindung zusammengetragen werden. Häufig ist die Datenbank auch noch auf dem gleichen Server installiert, sodass darüber hinaus zudem keine Netzwerkkommunikation nötig wird. Meist erfolgt diese Kommunikation über ein Unix-Socket, einem prozessübergreifenden Kommunikationsmechanismus, der den bidirektionalen Datenaustausch zwischen Prozessen ermöglicht, die auf demselben Computer ausgeführt werden.

Bei einer verteilten Architektur müssen dieselben Informationen aus unterschiedlichen Applikationen zusammengetragen werden, die diese wiederum selbst erst aus einer Datenbank extrahieren müssen. Wie man der Grafik 2 (3) entnehmen kann, kommen somit 319 API-Abfragen, 266 Datenbank-Abfragen über 8 verschiedene Datenbankverbindungen zusammen. Auch sieht man in der Grafik, dass zentrale Dienste von verschiedenen anderen Diensten angefragt werden. Dies bedeutet in Summe automatisch ein Vielfaches des einzelnen Seitenaufrufes. Selbst wenn diese Zusammenhänge nur linear sind, wird doch offensichtlich, dass dadurch schnell ein erhebliches Problem entstehen kann.

Jetzt senden wir gedanklich 500 gleichzeitige Anfragen an die beiden exemplarischen Systeme. Im Falle des monolithischen Systems kommen wir also auf Größenordnungen von 15.000 DB-Anfragen und 500 Verbindungen – ohne Netzwerk-Traffic.

Im Falle der verteilten Architektur erzeugen die Anfragen 160.000 interne API-Requests, die zu 133.000 Datenbank-Abfragen und gleichzeitig zu 4000 Datenbank-Verbindungen führen – alles über das Netzwerk. Wenn man, stark vereinfachend, von einem 1:1 Verhältnis zwischen Anfrage und Netzwerkverbindungen ausgeht, so bedeutet das, dass man in seinem Netzwerk, Cluster, seiner Virtualisierungs- oder Containermanagement-Umgebung 293.000 Netzwerkverbindungen erzeugt. Deren Ursprung liegt dabei hinter jeglichen schützenden Firewalls, DDoS-Protections, Content Delivery Networks (CDNs) oder gar limitierenden Internetanbindungen.

Wirklich gefährlich wird es dann, sobald Angreifer Wege oder Bereiche in der Applikation identifizieren können, bei deren Nutzung bestimmte dahinter liegende Systeme besonders belastet werden. Vor allem, wenn die belasteten Systeme nicht dediziert für den Webshop genutzt werden, sondern ganz andere Produktivitätsbereiche des Unternehmens betreffen (wie etwa ein CRM-System, ein ActiveDirectory oder die Lagerhaltung).

Das aufgeführte Beispiel schematisiert selbstverständlich sehr stark und lässt dabei einige Randbedingungen außer Acht. Dennoch zeigt es eindrucksvoll auf, dass es beim Einsatz verteilter Architekturen gänzlich andere Aspekte zu beachten gilt als bei monolithischen Systemen.

Es ist also wichtig, dass man sich gleich bei der Implementierung neuer Software über Resilienz-Pattern für die interne Kommunikation Gedanken macht und diese auch einführt. Auch helfen Use-Case-orientierte APIs anstelle generischer APIs sowie schlaue Caching- Konzepte dabei, die Anzahl der nötigen internen Anfragen zu reduzieren. Zirkuläre Abhängigkeiten zwischen den Services sollten vermieden werden, zu viele Abhängigkeiten zwischen den Diensten deuten gar einen falschen Service-Schnitt an.

Unser Tipp: Geben Sie Ihrer IT-Abteilung oder Dienstleistern Raum und Budget, diese Punkte im Detail zu betrachten und notwendige Stabilisierungsmaßnahmen durchzuführen. Vergessen Sie dabei nicht, eine Architektur-Dokumentation einzufordern. Mit Hilfe von µService-Architektur-Dokumentations-Tools wie beispielsweise vistecture, pivio oder c4model können Abhängigkeiten sogar modelliert und visualisiert werden. Auf dieser Basis kann man potenzielle Flaschenhälse, zyklische Abhängigkeiten und Ähnliches rasch identifizieren – in einigen Tools passiert das sogar automatisch.

Nur wenn man sich bewusst mit den Potentialen moderner Architektur-Konzepte auseinandersetzt, kann man deren Vorteile auch richtig nutzen. Bei zu naiver Herangehensweise hat man mit der Verwendung moderner Ansätze nichts gewonnen und steht, besonders aufgrund der geringeren Erfahrung in puncto Stabilisierung und Skalierung, gegenüber monolithischen Ansätzen deutlich schlechter da.