Kommentare zu folgendem Beitrag: Rapid Reset DDoS-Angriff: Eine neue Gefahr für die Sicherheit im Netz
Dass sowas 2023 überhaupt noch möglich ist, wtf…
Naja…grundsätzlich ist HTTP/2 eine gute Sache! HTTP/2 wurde im Zusammenhang mit den heutigen Web-Nutzungstrends entwickelt. Funktionen wie Multiplexing und Header-Kompression sind gut geeignet, um die Latenzzeit beim Zugriff auf Internet-Dienste über mobile Datennetze mit begrenzter Bandbreite pro Benutzer zu verringern. HTTP/2 optimiert die Web-Erfahrung für mobile Benutzer mit hoher Leistung und Sicherheit, die bisher nur der Desktop-Internetnutzung zugeschrieben wurden. Die Vorteile von HTTP/2 für mobile Benutzer versprechen unmittelbare positive Auswirkungen auf die Art und Weise, wie Online-Unternehmen Kunden in der Cyberwelt ansprechen.
Das total banale an diesem DDoS ist ja, dass man während die Verbindung bestehen bleibt, den Request wie in einem Loop, anscheinend unendlich oft nacheinander stellen kann an den Server! Das wird ja auch auf dem Artikelbild schnell deutlich…
BTW → Auf dem Bild gibt es einen Fehler. Und zwar sind die beiden ersten Teile (HTTP1.1 / HTTP/2) beides keine Attacke, sondern nur die Kommunikation der beiden unterschiedlichen Protokolle!
Das wirklich banale ist also, dass nicht schon ein „Overflow“ (z.B. im Cache) auf dem System des Senders eintritt…! Parallel ist das, wie oben beschrieben, eigentlich ein Feature betreffend die mobilen Web-Clients. Da beißt sich die Ratte in den eigenen Schwanz! 
1 „Gefällt mir“
Danke für den Ausführlichen und gut beschrieben Artikel. 
1 „Gefällt mir“
Es scheint einen fix zu geben https://github.com/nginx/nginx/commit/6ceef192e7af1c507826ac38a2d43f08bf265fb9
1 „Gefällt mir“
Schließe ich mich an. Vielen Dank!
Da war der Clemens schneller…
Ich hatte eben erst die Versionserweiterung bei nginx gefunden.
https://hg.nginx.org/nginx/rev/cdda286c0f1b
Um sicherzustellen, dass Versuche, Server mit vielen Streams zu überfluten, frühzeitig erkannt werden
früh erkannt werden, wurde eine Grenze von nicht mehr als 2 * max_concurrent_streams neuen Streams pro einer Iteration der Ereignisschleife eingeführt. Diese Grenze gilt auch dann, wenn
max_concurrent_streams noch nicht erreicht ist - zum Beispiel, wenn entsprechende
Streams synchron behandelt oder zurückgesetzt werden.Außerdem werden abgelehnte Streams jetzt auf ein Maximum von max_concurrent_streams
und 100 begrenzt, ähnlich wie der Anfangswert von priority_limit, wodurch eine gewisse Toleranz
gegenüber Clients, die versuchen, mehrere Streams beim Verbindungsstart zu öffnen, jedoch
geringe Toleranz gegenüber Flooding-Versuchen.