“Low-and-Slow“ mag wie ein alter Hut klingen, ist aber nach wie vor ein relevantes Thema. 65 % der Unternehmen waren 2020 von Low-and-Slow-Angriffen betroffen, 30 % davon sogar monatlich. Deshalb sollten wir uns kurz damit befassen!
Wenn ein Angreifer eine Applikation lahmlegen möchte, lenkt er am besten eine riesige Menge an Datenverkehr auf die Anwendung und schaltet damit den Applikationsserver aus (Distributed Denial of Service, kurz DDoS). Viele Technologien sind heute jedoch in der Lage, solche Versuche zu erkennen und zu unterbinden, entweder durch IP- bzw. Signatur-basierte Blockierung, Quota-Management oder dedizierte DDoS-Abwehrlösungen.
Im letzten Monat haben wir neben diesen massiven Angriffen festgestellt, dass auch eine altgediente, immer noch sehr effektive Methode zurückkehrt: der Low-and-Slow-Angriff. Bis Ende Februar verzeichnete Radware bei den Low-and-Slow-Angriffen auf seine Kunden einen Anstieg um 20 % im Vergleich zum vierten Quartal 2020.
Zur Erinnerung: das bedeutet "Low-and-Slow“
Anstatt einen plötzlichen Anstieg des Traffic-Volumens zu generieren, verlaufen Low-and-Slow-Angriffe (auch Low-Rate-Angriffe genannt) ganz heimlich still und leise. Sie sollen das Zielobjekt unbemerkt in die Knie zwingen, indem sie Verbindungen auf dem Zielobjekt offenlassen. Dazu stellen sie über längere Zeit eine relativ geringe Anzahl an Verbindungen her und sorgen dafür, dass diese Sitzungen möglichst lange geöffnet bleiben.
Häufig werden HTTP-Teilanfragen, kleine Datenpakete oder „Keep-Alive“-Nachrichten gesendet, um zu verhindern, dass die Sitzung inaktiv wird oder abläuft. Diese Angriffsvektoren sind nicht nur schwer zu blockieren, sondern auch schwer zu erkennen.
[Das könnte Sie auch interessieren: How to Keep APIs Secure in an Interconnected World]
Es gibt mehrere bekannte Tools, mit denen Kriminelle solche Angriffe starten können, z. B. SlowLoris, SlowPost, SlowHTTPTest, Tor’sHammer, R.U.Dead.Yet und LOIC.
Für Low-and-Slow-Angriffe, die sich gegen Applikationen bewährt haben, werden vernachlässigte APIs ausgenutzt, die weniger gut geschützt sind als Applikationen und den Weg zum Zielobjekt freigeben. Aufgrund der geringen Datenmenge, die auch bei legitimen Verbindungsversuchen zu Applikationen oder Serverressourcen auftritt, wird eine andere Abwehrtechnologie benötigt. Die Quelle sollte auf Basis des Verhaltens blockiert werden, nicht aufgrund ihrer Reputation.
Verhaltensbasierte Blockierung
Die Synchronisierung der Erkennungs- und Abwehrkomponenten ist einer der Gründe, warum Radware zu den anerkannten Branchenführern für DDoS-Schutz gehört: Verhaltensbasierte lernende Algorithmen überwachen und messen die Reaktionszeiten der TCP-Verbindung auf Client- und Serverseite und stellen sicher, dass die Quelle wie erwartet mit der Applikation interagiert.
Diese Methode beinhaltet keine Interaktion mit der Applikation und birgt keine Risiken, weil die Abwehr auf Sitzungsebene stattfindet. Weitere Versuche werden anschließend mithilfe eines einzigartigen Signalmechanismus und automatisierter Workflows am Netzwerkperimeter blockiert, ohne Auswirkung auf die Applikation.