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
Ein HTTP-DDoS-Angriff durch Flooding nutzt aus, dass Apps HTTP-Anfragen annehmen und beantworten müssen. Genau das ist ihr Zweck, oder? Und genau das tun sie. Und das unabhängig davon, wie schnell die Anfragen eintreffen. Auch wenn die Anfragen so schnell kommen, dass die Serverressourcen innerhalb von Minuten – oder Sekunden – erschöpft sind, versucht die App zu antworten. Jede App (bzw. jedes Gerät, jeder Dienst, jedes System usw.) hat eine Obergrenze für die Anzahl der TCP-Verbindungen, die sie gleichzeitig öffnen kann, bevor keine weiteren mehr zugelassen werden. Erreicht die Anzahl diese Obergrenze, ignoriert das System alle weiteren Anfragen. Sie erkennen das am normalen Hinweis „Verbindung wird hergestellt…“, wenn Ihr Browser oder Ihre App wartet, bis die vom System vorgegebene Zeit abgelaufen ist und dann meldet, dass keine Verbindung hergestellt werden konnte.
Ein solcher Angriff erfolgt so schnell (deshalb der Vergleich mit einer Sturzflut), dass die Systeme nicht schnell genug skalieren können, um den Bedarf zu decken. Auch automatische Skalierung hilft hier nicht, weil es länger dauert, eine neue App-Instanz bereitzustellen und zu starten, als der Angriff benötigt, um die bestehenden Instanzen vollständig zu erschöpfen.
Der Drain-Angriff
Das Gegenteil – ein erschöpfender Angriff – verfolgt dasselbe Ziel, indem es die App dazu bringt, eine Verbindung länger offen zu halten als notwendig. Es erreicht das, indem es eine Einwahlverbindung simuliert; die App bekommt pro Sekunde nur wenige Datenhäppchen, anstatt sie mit ihrer vollen empfangbaren Geschwindigkeit zu versorgen. Dadurch halten sich die Verbindungen länger, und wenn Sie das mit genug Verbindungen tun, führen Sie im Grunde zur gleichen Situation wie beim Flooding-Angriff: einem Verbrauch 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.
Es muss außerdem wissen, wohin es die Antwort senden soll und kennt daher den Client und dessen Netzwerkverbindung (in der Regel wird der App nur die IP-Adresse des Clients übermittelt, nicht mehr). Im Gegensatz zur Anwendung besitzt es die nötige Transparenz, um sowohl Flooding- als auch Draining-Angriffe zu erkennen – und sie zu stoppen, bevor sie die Ressourcen der Anwendung ausnutzen 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.