Der Angriff, den Sie in Ihrer Anwendung nicht stoppen können

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Eine Vielzahl HTTP-basierter Angriffe kann (und sollte) in Ihrer Anwendung verhindert werden. Die OWASP Top 10 sind ein Paradebeispiel für Angriffstechniken, die sich innerhalb jeder Anwendung sowohl erkennen als auch verhindern lassen. Zahlreiche Tools, darunter statische und dynamische Analysen sowie Penetrationstests, können sicherstellen, dass diese Schwachstellen gar nicht erst in die Produktion gelangen. Vorausgesetzt natürlich, dass solche Sicherheitstests im CI/CD-Prozess nach links verlagert werden und nicht erst als letzter Schritt erfolgen, bevor der Schalter umgelegt wird (oder vielmehr die Bits), durch den die Anwendung für Benutzer zugänglich wird.

Selbst wenn Sie jede potenzielle Schwachstelle beseitigt haben, die während der Entwicklung gefunden wurde, sind Anwendungen weiterhin gefährdet. Das liegt daran, dass manche Angriffe von der Anwendung nicht erkannt werden können – und mit „nicht können“ meine ich wirklich: Sie können es nicht. Wenn der Angriff die Anwendung erreicht, ist es tatsächlich bereits zu spät.

Natürlich spreche ich von DDoS-Angriffen auf der Anwendungsschicht (HTTP). Sie wissen schon, diese vampirartigen Angriffe, die das HTTP-Protokoll selbst ausnutzen, um einer Anwendung praktisch auch noch den letzten Rest an verfügbarer Rechenleistung und Arbeitsspeicher zu entziehen und sie so für legitime Nutzer unbrauchbar zu machen.

Grundsätzlich gibt es zwei Arten von HTTP-DDoS-Angriffen: die schnellen und die langsamen – die Flut und das Aussaugen.

Der Flood-Angriff

Ein auf Überflutung basierender HTTP-DDoS-Angriff macht sich zunutze, dass Anwendungen HTTP-Anfragen annehmen und beantworten sollen. Das ist schließlich gewissermaßen ihre Aufgabe, oder? Also tun sie es. Und zwar unabhängig davon, wie schnell diese Anfragen eingehen. Selbst wenn die Anfragen mit einer solchen Geschwindigkeit eintreffen, dass die verfügbaren Ressourcen des Servers innerhalb von Minuten – oder Sekunden – erschöpft sind, versucht er, sie zu beantworten. Denn jede Anwendung (genau genommen jedes Gerät, jeder Dienst, jedes System usw.) kann nur eine begrenzte Anzahl von TCP-Verbindungen gleichzeitig offen halten. Ist diese Obergrenze erreicht, können schlicht keine weiteren Verbindungen geöffnet werden. Alle nachfolgenden Anfragen werden dann einfach ignoriert. Für Benutzer äußert sich dies in der harmlos klingenden Statusmeldung „Verbindungsaufbau wird versucht…“, während ihr Browser oder ihre Anwendung wartet, bis die vom System vorgegebene Wartezeit abgelaufen ist, und anschließend bedauernd mitteilt, dass keine Verbindung hergestellt werden konnte.

Diese Art von Angriff kann so schnell erfolgen (daher der Vergleich mit einer „Sturzflut“), dass die Systeme nicht schnell genug skalieren können, um den Bedarf zu decken. In diesem Szenario hilft nicht einmal die automatische Skalierung, da die Bereitstellung und Inbetriebnahme einer neuen Instanz der App länger dauert, als der Angriff benötigt, um die Ressourcen der vorhandenen Instanzen vollständig aufzubrauchen.

Der Ressourcenentzug-Angriff

Das Gegenteil – ein Draining-Angriff – erfüllt denselben Zweck, indem er die App dazu zwingt, eine Verbindung länger als nötig offenzuhalten. Dazu gibt er vor, eine Einwahlverbindung zu nutzen, und ruft pro Sekunde nur wenige Daten von der App ab, anstatt sie mit der tatsächlich möglichen Geschwindigkeit zu empfangen. Dadurch bleiben Verbindungen länger bestehen. Geschieht dies mit genügend Verbindungen, entsteht im Grunde dieselbe Situation wie bei einem Flooding-Angriff: Die Ressourcen werden aufgebraucht.

Keine dieser beiden Angriffsarten lässt sich innerhalb einer Anwendung erkennen. Wie sollte das auch möglich sein? Aus Sicht der Anwendung sind all diese Anfragen legitim; es handelt sich durchweg um korrekt formatierte, HTTP-basierte Datenanfragen, wie sie die Anwendung vermutlich Tausende Male am Tag beantwortet. Weder die HTTP-Header noch die Nutzdaten enthalten ein Merkmal, das auf die bösartige Natur der Anfragen hinweist. Die Anwendung ist gegenüber den böswilligen Absichten hinter diesen Anfragen vollkommen blind, da sie weder Einblick in das Netzwerk noch in die übergeordnete Umgebung hat – insbesondere nicht in die Sitzungstabelle des Servers, in der die zentrale Liste aller offenen Verbindungen geführt wird. Ich erspare Ihnen die technischen Details und einen Vortrag über Threads, Prozesse und die Flüchtigkeit von Daten in Multithreading-Umgebungen und belasse es bei der Aussage, dass „kein Einblick in die Verarbeitung anderer Anfragen“ besteht.

Kurz gesagt: Die Anwendung selbst kann nicht feststellen, ob eine bestimmte Anfrage Teil eines größeren Angriffs (Flooding) ist oder ob ihr Verhalten nicht mit ihren bekannten Fähigkeiten übereinstimmt (Draining).

Der Proxy als Retter in der Not

Was hingegen Einblick in beides hat, ist der Proxy, der der Anwendung vorgeschaltet ist. Das liegt daran, dass der Proxy wahrscheinlich für den Lastenausgleich zuständig ist und daher sowohl darauf achten muss, wie viele Anfragen gerade verarbeitet werden, als auch darauf, wie viele neu eingehen, da er sie an eine der Anwendungen im Cluster (oder Pool, wenn Ihnen das lieber ist) weiterleiten muss.

Darüber hinaus muss der Proxy wissen, wohin er die Antwort senden soll, und kennt daher den Client und dessen Netzwerkverbindung (in der Regel wird lediglich die IP-Adresse des Clients an die Anwendung übermittelt, sonst nichts). Anders als die Anwendung verfügt er über den nötigen Einblick, um sowohl Flooding- als auch Draining-Angriffe zu erkennen – und sie zu stoppen, bevor sie ihre vampirischen Zähne in die Ressourcen der Anwendung schlagen können.

Deshalb spielen Proxy-basierte Dienste wie eine WAF (Web Application Firewall) oder sogar ein moderner Load Balancer eine entscheidende Rolle in heutigen Strategien zur Anwendungssicherheit. Denn sie verfügen über den nötigen Einblick und die erforderlichen Mittel, um anomales Verhalten zu erkennen, das auf einen Angriff hindeutet – und ihn abzuwehren wie Knoblauch einen Vampir.

Und da diese traditionell dem „Netzwerk“ zugeordneten Dienste zwangsläufig Teil der Anwendungsarchitektur werden sollten, erscheint es logisch, dass ein DevOps-Ansatz seinen Horizont erweitert und stärker jene Dienste einbezieht, die ohnehin von Natur aus eng mit der Anwendung verbunden sind, wie Anwendungssicherheit und Skalierbarkeit (Lastausgleich).

Anwendungen können nicht jeden Angriff abwehren, insbesondere wenn dafür ein Maß an Transparenz erforderlich ist, das ihnen schlichtweg nicht zur Verfügung steht. Durch das Zusammenspiel mit anwendungsnahen Diensten wie Webanwendungssicherheit und Lastverteilung lassen sich jedoch vielfältigere Angriffe erkennen und abwehren, sodass es zu weniger Ausfällen und Sicherheitsverletzungen kommt.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie