Der Angriff, den Sie in Ihrer Anwendung nicht stoppen können
Eine Vielzahl von HTTP-basierten Angriffen kann (und sollte) in Ihrer Anwendung verhindert werden. Die OWASP Top 10 sind ein Paradebeispiel für Angriffstechniken, die innerhalb jeder Anwendung erkannt und verhindert werden können. Zahlreiche Tools, darunter statische und dynamische Analysen sowie Penetrationstests, können sicherstellen, dass diese Schwachstellen nicht in die Produktion gelangen. Voraussetzung hierfür ist natürlich, dass derartige Sicherheitstests nach links in den CI/CD-Prozess verlagert werden und nicht erst als letzter Schritt vor dem Umlegen des Schalters (oder der Bits, sozusagen) durchgeführt werden, der sie für Benutzer zugänglich macht.
Auch wenn Sie alle potenziellen Schwachstellen in der Entwicklung beseitigt haben, sind die Anwendungen weiterhin gefährdet. Das liegt daran, dass manche Angriffe von der Anwendung nicht erkannt werden können – und mit „nicht“ meine ich wirklich „nicht“. Wenn der Angriff die Anwendung erreicht, ist es tatsächlich schon zu spät.
Natürlich spreche ich von DDoS-Angriffen auf Anwendungsebene (HTTP). Sie wissen schon, die Vampire, die das HTTP-Protokoll selbst ausnutzen, um im Grunde auch den letzten Rest an Rechenleistung und Speicher aus einer Anwendung herauszusaugen und sie so für legitime Benutzer unbrauchbar zu machen.
Grundsätzlich gibt es zwei Arten von HTTP-DDOS-Angriffen: die schnellen und die langsamen, die Flood- und die Drain-Angriffe.
Der Flutangriff
Bei einem auf Flooding basierenden HTTP-DDoS-Angriff wird die Tatsache ausgenutzt, dass von Apps erwartet wird, dass sie HTTP-Anfragen akzeptieren und darauf antworten. Das ist sozusagen ihr Ding, oder? Und das tun sie. Und das tun sie unabhängig davon, wie schnell die Anfragen eingehen. Auch wenn die Anfragen in einer Geschwindigkeit eingehen, die die dem Server zur Verfügung stehenden Ressourcen in Minuten – oder Sekunden – erschöpft, versucht er zu antworten. Bedenken Sie, dass jede App (eigentlich jedes Gerät, jeder Dienst, jedes System usw.) eine Obergrenze für die Anzahl der TCP-Verbindungen hat, die sie jederzeit offen halten kann, bevor sie einfach keine weiteren mehr öffnen kann. Wenn diese Obergrenze erreicht ist, werden alle nachfolgenden Anfragen einfach ignoriert. Benutzer erleben dies mit dem harmlosen Status „Verbindungsversuch …“, während ihr Browser oder ihre App wartet, bis die vom System angegebene Wartezeit abgelaufen ist, und sich dann für die fehlgeschlagene Verbindung entschuldigt.
Ein derartiger Angriff kann so schnell erfolgen (daher auch der Vergleich mit einer „Sturzflut“), dass die Skalierbarkeit der Systeme zur Deckung der Nachfrage übersteigt. Nicht einmal die automatische Skalierung kann in diesem Szenario helfen, da die zum Bereitstellen und Starten einer neuen Instanz der App benötigte Zeit größer ist als die Zeit, die der Angriff benötigt, um die vorhandenen Instanzen aller Ressourcen zu berauben.
Der Drain-Angriff
Das Gegenteil – ein Draining-Angriff – erreicht dieselbe Aufgabe, tut dies jedoch, indem die App gezwungen wird, eine Verbindung länger als nötig offen zu halten. Dies wird erreicht, indem vorgetäuscht wird, eine DFÜ-Verbindung zu nutzen. Dabei werden pro Sekunde nur wenige Daten aus der App gesendet, statt mit der Rate, mit der die App diese tatsächlich empfangen kann. Dies bedeutet, dass die Verbindungen länger halten, und wenn Sie dies mit genügend Verbindungen tun, gelangen Sie im Grunde in die gleiche Situation wie beim Flooding-Angriff: Erschöpfung der Ressourcen.
Keiner dieser Angriffe ist innerhalb einer Anwendung erkennbar. Warum sollten sie das sein? Für die Anwendung sind diese Anfragen alle legitim. Es handelt sich allesamt um wohlgeformte, HTTP-basierte Datenanfragen, die sie wahrscheinlich tausende Male am Tag beantwortet. Es gibt in den HTTP-Headern oder der Nutzlast kein Flag, das auf die schändliche Natur der Anfragen hinweist. Die Anwendung ist sich der böswilligen Absichten hinter diesen Anfragen überhaupt nicht bewusst, da sie weder Einblick in das Netzwerk noch in die weitere Umgebung hat – insbesondere nicht in die Sitzungstabelle des Servers, in der die Hauptliste aller offenen Verbindungen verwaltet wird. Ich erspare Ihnen die technischen Details und Vorträge über Threads, Prozesse und die Volatilität von Daten in Multithread-Umgebungen und bleibe einfach bei „keine Einsicht in die Verarbeitung anderer Anfragen“.
Es genügt zu sagen, dass die Anwendung selbst nicht feststellen kann, ob eine bestimmte Anforderung Teil eines größeren Angriffs ist (Flooding) oder ob ihr Verhalten nicht mit ihren bekannten Fähigkeiten übereinstimmt (Draining).
Der Proxy zur Rettung
Was in beides Einblick hat , ist der Proxy, der sich vor der Anwendung befindet. Das liegt daran, dass der Proxy wahrscheinlich einen Lastenausgleich durchführt und daher darauf achten muss, wie viele Anfragen derzeit bearbeitet werden und wie viele eingehen, da er sie an eine der Apps im Cluster (oder Pool, wenn Sie das so bevorzugen) senden muss.
Darüber hinaus muss es wissen, wohin die Antwort gesendet werden soll, also über den Client und seine Netzwerkverbindung Bescheid wissen ( normalerweise wird nur die IP-Adresse des Clients an die App gesendet, mehr nicht ). Im Gegensatz zur Anwendung verfügt es über die notwendige Sichtbarkeit, um sowohl Flooding- als auch Draining-Angriffe zu erkennen – und sie zu stoppen, bevor sie ihre Vampirzähne in die Ressourcen der App schlagen können.
Aus diesem Grund sind proxybasierte Dienste wie eine WAF (Web Application Firewall) oder sogar ein erweiterter Load Balancer ein entscheidender Faktor in den heutigen Anwendungssicherheitsstrategien. Denn sie verfügen über die nötige Sichtbarkeit und die Mittel, um das auf einen Angriff hinweisende anomale Verhalten zu erkennen – und es wie Knoblauch und einen Vampir abzuwehren.
Und weil diese traditionellen „Netzwerk“-Dienste zwangsläufig Teil der Anwendungsarchitektur werden sollten, scheint es logisch, dass ein DevOps-Ansatz dazu neigt, seine Flügel auszubreiten und jene Dienste stärker einzubeziehen, die von Natur aus in erster Linie auf die Anwendung ausgerichtet sind , wie etwa App-Sicherheit und Skalierbarkeit (Lastausgleich).
Anwendungen können nicht jeden Angriff stoppen, insbesondere nicht diejenigen, die ein Maß an Transparenz erfordern, das ihnen einfach nicht zur Verfügung steht. Durch die Zusammenarbeit mit anwendungsaffinen Diensten wie Web-App-Sicherheit und Lastenausgleich können jedoch umfassendere Angriffe erkannt und abgewehrt werden, um Ausfälle und Sicherheitsverletzungen zu verringern.