DDoS-Aktivität verlagerte sich im dritten Quartal 2026 auf Schwärme
DDoS-Aktivität verlagerte sich im dritten Quartal 2026 auf mehr Schwärme und weniger riesige Angriffe. Das geht aus einem threat report hervor, den Cloudflares Cloudforce One am 29. Oktober 2026 veröffentlichte. DDoS steht für distributed denial of service, einen Angriff, bei dem Datenverkehr aus vielen Quellen einen Onlinedienst überlastet und legitime Nutzer daran hindert, ihn zu erreichen. Die zentrale Einordnung des Berichts deutet darauf hin, dass Organisationen die Anzahl und Verteilung der Angriffe berücksichtigen müssen und nicht nur die Größe der höchsten Verkehrsspitze.
Cloudflare bringt den Bericht mit botnet, Sicherheit und threat intelligence in Verbindung. Ein botnet ist eine Gruppe mit dem Internet verbundener Geräte, die gemeinsam gesteuert werden können, häufig ohne Wissen ihrer Eigentümer. Das Wort „Schwarm“ ist selbst kein Standardmaß für die Intensität von DDoS. Zusammen mit der Einordnung als botnet weist es jedoch auf koordinierte Aktivitäten aus mehreren Quellen hin. Cloudflares Schlagzeile beschreibt eher eine Entwicklung als einen zahlenmäßigen Vergleich. Sie sollte daher nicht als Beleg für eine bestimmte Anzahl von Angriffen, ein bestimmtes Datenverkehrsvolumen, eine bestimmte Dauer oder eine bestimmte Änderungsrate betrachtet werden.
Die Unterscheidung zwischen Schwärmen und riesigen Angriffen ist für den Betrieb relevant. Ein riesiger DDoS-Angriff lässt sich in erster Linie als Kapazitätsproblem verstehen: Können das Netzwerk und seine Schutzsysteme genügend schädlichen Datenverkehr aufnehmen oder verwerfen, damit der vorgesehene Dienst verfügbar bleibt? Aktivitäten nach Art eines Schwarms können den Schwerpunkt stärker darauf legen, viele verteilte Quellen zu identifizieren, eine einheitliche Filterung aufrechtzuerhalten und wiederholte Beeinträchtigungen des Dienstes zu erkennen. Weniger riesige Angriffe bedeuten daher nicht, dass das Verfügbarkeitsrisiko verschwunden ist. Auch ein kleineres Ereignis kann eine Website oder Anwendung unterbrechen, wenn es die Kapazität dieses Dienstes überschreitet oder auf eine Ressource abzielt, deren Verarbeitung besonders aufwendig ist.
Organisationen sollten ihre Einsatzbereitschaft daher nicht nur anhand des höchsten bisher beobachteten Datenverkehrswerts messen. Eine sinnvolle Überwachung sollte Verfügbarkeit, response time, error rate und ungewöhnliche Veränderungen des Anfragevolumens umfassen. Response time bezeichnet die Zeit, die ein Dienst benötigt, um auf eine Anfrage zu antworten, während error rate den Anteil der fehlgeschlagenen Anfragen angibt. Die gemeinsame Beobachtung dieser Signale hilft Teams dabei, einen vollständigen Ausfall von einer langsameren, teilweisen Störung zu unterscheiden, die Kunden dennoch daran hindern kann, sich anzumelden, einen Kauf abzuschließen oder eine Anwendung zuverlässig zu nutzen.
DDoS-Schutz muss außerdem den gesamten Weg zum Dienst abdecken. Eine geschützte öffentliche Website kann weiterhin nicht verfügbar sein, wenn ein Angreifer den zugrunde liegenden Host direkt erreichen, eine ungeschützte Netzwerkverbindung auslasten oder einen Anwendungsvorgang überlasten kann, der erhebliche Rechen- oder Datenbankkapazität beansprucht. Deshalb sollten Teams dokumentieren, welche öffentlichen Adressen und Dienste zugänglich sind, wo die Filterung des Datenverkehrs stattfindet und wer für die Reaktion verantwortlich ist, wenn sich die Verfügbarkeit verschlechtert. Diese Infrastrukturfragen gelten unabhängig davon, welche Hosting- oder Cloud-Plattform verwendet wird.
Rate limiting, das begrenzt, wie häufig ein Client eine Anfrage stellen kann, kann bei sorgfältiger Konfiguration den Druck auf ausgewählte Anwendungsfunktionen verringern. Caching, bei dem eine gespeicherte Kopie bereitgestellt wird, statt dieselben Inhalte wiederholt neu zu erzeugen, kann auch den Aufwand auf Anwendungs- und Datenbankebene reduzieren. Keines von beiden sollte als universelle Lösung betrachtet werden: Zu strenge Begrenzungen können legitime Nutzer blockieren, während Caching keine Vorgänge schützen kann, die einzeln verarbeitet werden müssen. Das praktische Ziel ist eine mehrschichtige Resilienz statt der Abhängigkeit von einer einzigen Schutzmaßnahme.
Ein incident plan sollte festlegen, wie ein Ausfall bestätigt wird, wie der Hosting- oder Netzwerkanbieter kontaktiert wird, wer Notfalländerungen an der Konfiguration genehmigen darf und wie Kunden informiert werden. Teams sollten außerdem Überwachungsdaten aufbewahren, damit sie prüfen können, wann die Störung begann, welche Dienste ausgefallen sind und ob die Wiederherstellungsmaßnahmen funktioniert haben. Diese betrieblichen Nachweise sind wichtig, weil ein stark verteiltes Ereignis andernfalls wie gewöhnliche Überlastung, ein Anwendungsfehler oder ein plötzlicher Anstieg legitimer Nachfrage aussehen kann.
Organisationen, die Unterstützung bei der Überprüfung dieser betrieblichen und sicherheitsbezogenen Verantwortlichkeiten suchen, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsleistungen. Die übertragbare Erkenntnis aus Cloudflares Einordnung des dritten Quartals 2026 lautet, dass die Vorbereitung auf DDoS sowohl verteilte und wiederholte Störungen als auch außergewöhnlich große Angriffe berücksichtigen sollte. Schutz-, Überwachungs- und Reaktionsverfahren müssen darauf ausgelegt sein, den Dienst nutzbar zu halten, und nicht lediglich darauf, eine öffentlichkeitswirksame Zahl zum Datenverkehr zu überstehen.