935 Angriffe jenseits von 1 Tbps sind kein Randphänomen mehr
935 Netzwerk-DDoS-Angriffe mit mehr als 1 Tbps in einem halben Jahr: Diese Zahl aus dem Cloudflare DDoS-Report H1 2026 beschädigt den Komfort vieler Sicherheitspläne. Cloudflare beschreibt kein einzelnes Rekordwochenende, sondern ein Muster über Januar bis Juni 2026. Der Anbieter meldet zusätzlich einen Anstieg um 519 Prozent von Q1 auf Q2 bei Angriffen dieser Größenordnung. Das ist ein Hinweis auf Normalisierung: Bandbreite, Paketrate und Anwendungsdruck wachsen gleichzeitig.
Für KI-Dienste ist das besonders relevant. Chatbots, Agenten, Such-Overviews, RAG-Systeme und medizinische Assistenzfunktionen sehen nach Software aus, hängen aber an banaler Erreichbarkeit. Wenn DNS, API-Gateways oder Edge-Regeln unter Last versagen, diskutiert niemand mehr über Modellqualität. Die eleganteste KI-Architektur ist wertlos, wenn sie ihre eigene Eingangstür nicht verteidigen kann.
Die unbequeme Lehre lautet: Resilienz ist kein Add-on für später, sondern Teil des Produkts. Wer KI-Funktionen öffentlich anbietet, muss Lastspitzen, bösartigen Traffic und fehlerhafte Wiederholungen als realistische Betriebszustände einplanen. Alles andere ist Schönwetter-Engineering mit hübscher Modellkarte und sehr realer Ausfallrechnung.
Zusätzlich verschiebt die Zahl die interne Diskussion von Wahrscheinlichkeit zu Auswirkung. Ein einzelner Angriff über 1 Tbps muss nicht jedes Unternehmen direkt treffen, aber die Abwehrkapazität der Gegenseite prägt Preise, Verträge, Architektur und Recovery-Ziele. Wer das ignoriert, überlässt die Risikoannahmen faktisch seinem Provider.
Was Cloudflare wirklich gemessen hat
Cloudflare nennt den Bericht die 25. Ausgabe seiner DDoS-Threat-Report-Reihe und zugleich die erste Halbjahresausgabe: Statt getrennten Q1- und Q2-Berichten bündelt der Anbieter erstmals Januar bis Juni 2026. Die Analyse stammt laut Cloudflare von Cloudforce One, der Threat-Intelligence-Organisation des Unternehmens, und basiert auf Daten aus dem Cloudflare-Netzwerk. Der Report ist damit wertvoll, aber kein globaler Zensus aller Angriffe.
Die Kennzahlen sind hart genug. Cloudflare spricht von 5.300 DDoS-Angriffen pro Stunde in H1 2026. April 2026 markierte einen Spitzenmonat mit 6,46 Billionen Requests und 165 Petabyte Volumen. Im zweiten Quartal mitigierte Cloudflare 805 Netzwerkangriffe über 1 Tbps; das beschreibt der Anbieter als mehr als sechsfache Zunahme gegenüber dem Vorquartal.
Für Betreiber zählt daran weniger der Superlativ als die Größenordnung. Solche Werte sind nicht mit einem zusätzlichen Webserver oder einem hektisch hochgedrehten Autoscaler zu beantworten. Die Abwehr liegt vor der Anwendung, in Netzwerkarchitektur, Provider-Verträgen, Notfallprozessen und in der Frage, ob Logs im Angriff noch lesbar bleiben. Beobachtbarkeit wird unter Last selbst zur knappen Ressource.
DNS und CLDAP verschieben die Angriffslogik
Der spannendste Teil liegt nicht in der größten Zahl, sondern im Muster dahinter. Cloudflare schreibt, das Gewicht habe sich von Botnet-Fluten zu Reflection und Amplification verschoben. DNS-basierte Angriffe, also DNS Flood und DNS Amplification, machten im ersten Halbjahr 34,3 Prozent der Netzwerk-Layer-Aktivität aus. DNS Floods allein stiegen von 25,7 Prozent auf 40,0 Prozent der Netzwerkangriffe im Quartalsvergleich.
CLDAP verschärft das Bild. Cloudflare meldet für CLDAP Floods einen Quartalsanstieg um 580 Prozent; im zweiten Quartal wurde dieser Vektor zum drittgrößten Netzwerkangriffstyp. Connectionless LDAP läuft über UDP, erlaubt Quelladress-Spoofing und kann schlecht abgesicherte Verzeichnisdienste als Verstärker missbrauchen. Für Unternehmen heißt das: eigene exponierte Dienste bereinigen und vorgelagerte Schutzpfade prüfen.
Gerade DNS wird intern oft unterschätzt, weil es im Normalbetrieb unsichtbar ist. Unter Angriff wird es zum ersten Dominostein. Ein Portal kann sauber programmiert, ein Modell sauber evaluiert und ein Authentifizierungsfluss sauber gehärtet sein; wenn die Domain nicht mehr zuverlässig auflöst, kommt beim Nutzer trotzdem nur Ausfall an. Das ist banal, aber genau deshalb gefährlich.
Die Verteidigung gegen Reflection und Amplification ist zudem ein Solidaritätstest des Netzes. Jedes offen erreichbare, falsch konfigurierte UDP-System kann Teil fremder Angriffe werden. Saubere Filter, Abschaltung unnötiger Dienste und Provider-seitige Egress-Kontrollen sind deshalb keine akademische Hygiene, sondern konkrete Schadensbegrenzung.
Warum KI-Stacks Traffic-Realität brauchen
KI-Sicherheit wird gern über Prompt-Injection, Datenabfluss und Modellmissbrauch diskutiert. Das ist richtig, aber unvollständig. Der Cloudflare DDoS-Report erinnert daran, dass KI-Produkte dieselben Grundlagen brauchen wie jede andere digitale Leistung: DNS, Routing, TLS, WAF-Regeln, Rate Limits, Logging und belastbare Notfallpfade. Wer Agenten in Kundenportale, Supportsysteme oder interne Analyseketten einbaut, erzeugt mehr API-Oberfläche und mehr extern erreichbare Endpunkte.
Genau dort wird Traffic zur Governance-Frage. Ein KI-Agent, der bei Latenzspitzen falsch eskaliert, mehrfach retryt oder Workflows dupliziert, kann eine Störung vergrößern. Die Verteidigung beginnt deshalb nicht erst beim DDoS-Provider, sondern beim Produktdesign: Timeouts, Backoff, harte Quoten und klare Degradationsmodi gehören in die KI-Architektur, nicht in die Nachtragsfolie der Sicherheitsabteilung.
Besonders kritisch sind Integrationen, die im Namen eines Nutzers handeln. Wenn ein Agent Tickets schreibt, Zahlungen vorbereitet oder Daten synchronisiert, darf er bei Verbindungsproblemen nicht blind nachlegen. Idempotenz ist dann keine Entwicklerlaune, sondern Sicherheitskontrolle. Das wirkt trocken, ist aber die Linie zwischen robuster Automatisierung und selbstgebautem Störverstärker.
Für KI-Teams ist das unbequem, weil es Zuständigkeiten verschiebt. Modellmetriken allein beantworten nicht, wie sich ein Produkt unter Angriff verhält. Ein Security Review muss deshalb die gesamte Anfragekette sehen: vom DNS-Lookup über Edge-Regeln bis zum letzten Tool-Aufruf des Agenten.
Geopolitik macht Lastspitzen planbarer, nicht bequemer
Cloudflare verbindet die beobachteten Angriffe auch mit geopolitischen und globalen Ereignissen. Media, Production & Publishing blieb laut Report in beiden Quartalen die am stärksten attackierte Branche im HTTP-DDoS-Blick und stand für 14,2 Prozent aller mitigierten HTTP-DDoS-Requests. Außerdem stieg die Türkei vor dem Hintergrund des NATO-Gipfels in Ankara auf Rang drei der am stärksten attackierten Länder; der Regierungssektor sprang während Operation Epic Fury von Platz 29 auf Platz 9.
Das ist keine Einladung zum Spekulieren über einzelne Täter. Es ist ein Planungsargument. Organisationen mit Medienpräsenz, politischem Bezug, kritischer Infrastruktur oder aufmerksamkeitsstarken KI-Diensten sollten Kalenderereignisse in ihre Last- und Sicherheitsplanung aufnehmen. Wenn eine öffentliche Debatte vorhersehbar ist, darf der Schutzpfad nicht überrascht wirken. Entscheidend bleibt beobachtbare Exposition, nicht die dramatischste Überschrift.
Für Medien- und Publishing-Angebote ist der Befund besonders trocken. Sichtbarkeit ist Geschäftsmodell und Angriffsmagnet zugleich. Wer Reichweite sucht, muss Verfügbarkeit budgetieren. Das gilt für klassische Nachrichtenlagen ebenso wie für KI-getriebene Such- und Empfehlungsfunktionen, die plötzlich zum Einstiegspunkt ganzer Nutzerströme werden.
Auffällig ist auch die Branchenspur. Wenn Media, Production & Publishing im HTTP-DDoS-Blick vorn liegt, betrifft das nicht nur klassische Redaktionen. Plattformen, Creator-Tools, KI-Suchinterfaces und Empfehlungsdienste hängen alle an öffentlicher Aufmerksamkeit. Genau diese Aufmerksamkeit kann in kurzer Zeit vom Wachstumssignal zum Belastungstest kippen.
Was Betreiber jetzt prüfen sollten
Der erste Prüfpunkt ist DNS. Sind autoritative Nameserver redundant, DDoS-geschützt und außerhalb derselben Fehlerdomäne betrieben? Der zweite Prüfpunkt ist UDP-Exposition. CLDAP, offene Resolver und schlecht gefilterte Legacy-Dienste sind nicht nur ein Risiko für die eigene Verfügbarkeit, sondern können als Verstärker gegen andere missbraucht werden. Der dritte Prüfpunkt ist Telemetrie: Ohne getrennte Sicht auf Netzwerk-Layer, HTTP-Layer und Applikationsfehler verschwimmt ein Angriff schnell mit einem normalen Incident.
Für KI-Angebote kommt ein vierter Punkt hinzu: kontrollierte Degradation. Wenn Ihr Assistenzsystem nicht erreichbar ist, muss der Kernprozess weiterlaufen. Wenn ein Agent externe Aktionen auslöst, braucht er Lastgrenzen und Idempotenz. In unserem Kontext zu KI-Agenten und Firewall-Regeln war genau dieser Punkt schon sichtbar: Automatisierung ohne Begrenzung verwandelt Tempo in Angriffsfläche.
Der fünfte Punkt ist Kommunikation. DDoS ist nicht nur ein NOC-Ereignis. Support, Management, Datenschutz, Vertrieb und gegebenenfalls Behörden brauchen vorab definierte Rollen. In der Krise noch zu diskutieren, wer Kunden informiert oder Schutzmaßnahmen priorisiert, ist die teuerste Form von Improvisation. Schutzgrenzen müssen messbar sein: Request-Raten, Upstream-Abwürfe, Statusseiten, Eskalationsfenster.
Ein weiterer Prüfpunkt ist Vertragsrealismus. Viele Teams wissen, welchen Modellpreis sie zahlen, aber nicht, welche DDoS-Leistung ihr Edge- oder Hosting-Vertrag tatsächlich umfasst. Enthalten sind oft Schutzversprechen, nicht aber garantierte Kommunikationswege, klare Eskalationszeiten oder belastbare Nachweise nach einem Vorfall.
Die unbequeme Grenze des Reports
Cloudflare misst aus einer starken Position, aber auch aus einer bestimmten Position. Die Zahlen zeigen mitigierte Angriffe im eigenen Netzwerk. Andere Provider, regionale Netzbetreiber, kleine Hostings, direkte Origin-Treffer oder nicht öffentlich sichtbare Erpressungsversuche können anders aussehen. Wer den Report seriös nutzt, behandelt ihn deshalb als Frühwarnsignal und Vergleichsfolie, nicht als vollständige Risikoakte. Das schmälert die Bedeutung nicht; es verhindert nur falsche Gewissheit.
Für Digital-Magazin-Leser mit Verantwortung für Plattformen, Shops oder KI-Services ist die Konsequenz simpel und wenig glamourös. Prüfen Sie, ob Ihre Annahmen zur Angriffsstärke noch aus 2023 stammen. Prüfen Sie, ob DNS, Edge, API-Gateway und Anwendung dieselbe Schutzlogik teilen. Sicherheit ist hier kein schönes Dashboard. Sicherheit ist die Fähigkeit, unter schmutzigem Traffic kontrolliert langweilig zu bleiben.
Ein passender interner Vergleich ist der Beitrag zum Cloud-Pilotprojekt und Risikoaufsicht. Dort ging es um Kontrolle vor Skalierung. Beim DDoS-Thema gilt dasselbe, nur lauter: Wer erst nach dem Wachstum über Belastbarkeit spricht, hat die Reihenfolge verwechselt.
Der Bericht sollte deshalb in eine Übung münden. Simulieren Sie eine nicht erreichbare Domain, ein überlastetes Gateway und einen Agenten, der Antworten mehrfach versucht. Wenn danach niemand genau weiß, welche Funktion abgeschaltet wird und welche Nutzerinformation sichtbar bleibt, ist die Architektur noch nicht fertig.
Das kostet Zeit, aber weniger als ein Blindflug im echten Angriff. Die trockenste Kennzahl aus jedem DDoS-Test ist nicht die maximale Paketlast, sondern die Frage, wie viele Entscheidungen ohne Ad-hoc-Meeting funktioniert haben. Wer das messen kann, hat gewonnen.
Was halten Sie von dem Thema? Hier können Sie mit anderen Leserinnen und Lesern ins Gespräch gehen.
Mitreden & diskutieren
Ihre Meinung zählt — teilen Sie Gedanken, Fragen oder Erfahrungen zu diesem Artikel.