Warum 2026 ein Rekordjahr für DDoS ist
Die Größenordnung von DDoS-Angriffen hat sich innerhalb weniger Jahre vervielfacht. Cloudflare meldete für das gesamte Jahr 2025 rund 47,1 Millionen abgewehrte Angriffe - ein Anstieg von 121 Prozent gegenüber dem Vorjahr - und im Schnitt 5.376 abgewehrte DDoS-Angriffe pro Stunde (Cloudflare 2025). Auf der Netzwerkebene haben sich die Vorfälle mehr als verdreifacht: von 11,4 Millionen (2024) auf 34,4 Millionen (2025), wobei sie im vierten Quartal 2025 bereits 78 Prozent aller DDoS-Angriffe ausmachten (Cloudflare 2025). Die schiere Frequenz bedeutet, dass auch kleinere Websites statistisch in Reichweite geraten - nicht weil sie das Ziel sind, sondern weil sie das gleiche Hosting, denselben Upstream oder dieselbe IP-Range mit einem eigentlichen Ziel teilen.
Auch die absolute Spitze ist gewachsen. Der Rekord von 31,4 Tbps Ende 2025 übertraf den vorherigen Bestwert von 5,6 Tbps deutlich, und die Angriffsgrößen wuchsen um über 700 Prozent gegenüber den großen Angriffen von Ende 2024 (Cloudflare 2025). Hinzu kommt eine Verschiebung im Charakter: Große Kampagnen kombinieren zunehmend mehrere Angriffsfamilien gleichzeitig - der Rekordangriff bündelte etwa SYN-Flood, Mirai-Traffic und mehrere Reflexionsvektoren in einer einzigen Welle (Cloudflare 2025). Solche Multi-Vektor-Angriffe sind schwerer zu filtern - und für den Betreiber von außen ununterscheidbar von einem schlichten Serverausfall. Wer wissen will, ob die eigene Seite gerade erreichbar ist, braucht eine Messung von außen, nicht nur den Blick auf die Server-Last.
Eine verbreitete Annahme lautet: Wir sind zu klein, um Ziel zu sein. 59 Prozent der Kleinunternehmer glauben das - und rund 51 Prozent haben keinerlei Schutzmaßnahmen gegen DDoS getroffen (SentinelOne 2026). Gleichzeitig verzeichnen kleine und mittlere Unternehmen einen zwölffachen Anstieg API-basierter DDoS-Angriffe (SentinelOne 2026). Die Größe schützt nicht; die fehlende Vorbereitung erhöht das Risiko.
Wie DNS-Amplification funktioniert
DNS-Amplification ist ein Reflexions- und Verstärkungsangriff. Der Angreifer sendet kleine DNS-Anfragen an öffentlich erreichbare, offene Resolver - fälscht dabei aber die Absenderadresse und trägt stattdessen die IP-Adresse des Opfers ein. Der Resolver antwortet pflichtgemäß, schickt die deutlich größere Antwort aber an das Opfer statt an den Angreifer. Da eine kompakte Anfrage eine vielfach größere Antwort auslösen kann, wirkt jeder missbrauchte Resolver wie ein Verstärker: Der für DNS dokumentierte Verstärkungsfaktor liegt beim 28- bis 54-fachen der ursprünglichen Anfrage (CISA TA14-017A). Bei tausenden parallel missbrauchten Resolvern summiert sich das zu einer Datenflut, die die Anbindung des Opfers überlastet.
- Spoofing der Quell-IP - der Angreifer trägt die Adresse des Opfers als Absender ein, sodass die Antworten dorthin laufen
- Kleine Anfrage, große Antwort - eine Abfrage nach allen Einträgen einer Zone (ANY) oder großen Records erzeugt ein Vielfaches an Antwortdaten
- Reflexion über offene Resolver - jeder missbrauchte Server addiert sein Antwortvolumen, ohne dass der Angreifer selbst große Bandbreite braucht
- Bandbreiten-Überlastung - die gebündelten Antworten sättigen die Anbindung des Opfers, die Website wird unerreichbar
Der Reiz für Angreifer liegt in der Hebelwirkung: Mit wenig eigener Bandbreite lassen sich große Datenmengen erzeugen, und die wahre Quelle bleibt hinter den Resolvern verborgen. Genau deshalb ist die Verfügbarkeit offener Resolver der entscheidende Faktor. Wie stark dieser Vektor wieder im Vordergrund steht, zeigen die Messungen von 2025: DNS-Floods waren der häufigste Angriffsvektor auf Netzwerkebene und machten knapp ein Drittel aller L3/4-Angriffe aus (Cloudflare 2025). Damit ist DNS - lange durch andere Reflexionsverfahren überlagert - wieder zum dominierenden Verstärkungsvektor geworden.
Offene Resolver und das BCP38-Problem
Zwei strukturelle Schwächen machen DNS-Amplification überhaupt erst möglich. Die erste sind offene DNS-Resolver: Server, die rekursive Anfragen aus dem gesamten Internet beantworten, statt nur aus dem eigenen Netz - und damit als Reflektor missbraucht werden können (CISA). Viele davon sind nicht bewusst betriebene Dienste, sondern fehlkonfigurierte Heim-Router und IoT-Geräte, die ungeschützt aus dem Internet erreichbar bleiben. Solange solche offenen Resolver in großer Zahl existieren, behält DNS-Amplification ihre Schlagkraft.
Die zweite Schwäche ist das Fehlen der Quelladressvalidierung. BCP38 ist die seit langem etablierte Empfehlung (Best Current Practice 38), die Netzbetreibern nahelegt, Pakete mit offensichtlich gefälschter Absenderadresse am Netzrand zu verwerfen (Heimdal 2026). Würde diese Filterung flächendeckend umgesetzt, liefe Spoofing ins Leere - denn ein Paket mit der IP des Opfers als Absender würde gar nicht erst das Netz des Angreifers verlassen. Da viele Netze BCP38 nicht durchsetzen, bleibt das Fälschen der Quell-IP technisch trivial. Der einzelne Website-Betreiber kann weder die offenen Resolver der Welt schließen noch fremde Netze zur Filterung zwingen - was bleibt, ist die Fähigkeit, einen Angriff schnell zu bemerken und zu reagieren.
| Schwachstelle | Wer kann sie beheben | Was Betreiber tun können |
|---|---|---|
| Offene DNS-Resolver | Betreiber der Resolver, ISPs | Eigene Resolver schließen, Rekursion einschränken |
| Fehlende BCP38-Filterung | Netzbetreiber am Netzrand | Kaum direkt - Druck über Hoster/Provider |
| Große DNS-Antworten (ANY) | DNS-Betreiber | ANY-Antworten begrenzen, Response Rate Limiting |
| Späte Ausfall-Erkennung | Website-Betreiber selbst | Externes Multi-Location-Monitoring mit Sofort-Alert |
Die letzte Zeile ist die einzige, die vollständig in der eigenen Hand liegt. Wer schon die Resolver-Konfiguration im Blick behalten will, findet im Beitrag zur Multi-Resolver-DNS-Propagation verwandte Prüfmuster. Wie eng DNS-Sicherheit und Verfügbarkeit zusammenhängen, zeigt auch der Beitrag zur DNSSEC-Validierung als DNS-Härtung.
Warum kurze Angriffe so gefährlich sind
Die wichtigste Entwicklung für Website-Betreiber ist nicht die Rekordgröße, sondern die Verkürzung. Angreifer verlagern sich von langen Kampagnen auf kurze Stossangriffe (SentinelOne 2026). 89 Prozent der Angriffe auf Netzwerkebene enden binnen 10 Minuten, viele hochvolumige Wellen sind sogar nur 35 bis 45 Sekunden lang (Cloudflare 2025); ein erheblicher Teil ist also vorbei, bevor jemand überhaupt hinsieht. Ein Stossangriff testet Abwehr aus, lenkt von anderen Aktivitäten ab oder reicht schlicht, um Umsatz und Vertrauen zu beschädigen - und ist vorbei, bevor ein klassischer Alarm überhaupt greift.
Ein Monitoring, das nur alle fünf Minuten prüft, kann einen 90-Sekunden-Ausfall vollständig verpassen: Die Prüfung vorher war grün, die Prüfung danach ist grün - der Ausfall fällt durch das Raster. Genau in diesem Zeitfenster operieren moderne Stossangriffe. Je enger das Prüfintervall und je mehr Standorte parallel messen, desto kleiner wird das blinde Fenster.
Hinzu kommt ein psychologischer Effekt: Weil ein kurzer Ausfall sich oft nicht reproduzieren lässt, wird er schnell als Einzelfall abgetan oder dem Endgerät des Beschwerdeführers zugeschrieben. Ohne objektive Aufzeichnung von außen bleibt unklar, ob es sich um ein lokales Problem des Nutzers oder um einen realen, breit wirksamen Ausfall handelte. Genau diese Unsicherheit verzögert die Reaktion - und kostet bei einer Serie kurzer Stoßangriffe wertvolle Zeit. Eine lückenlose, zeitgestempelte Historie aus mehreren Standorten beendet die Spekulation und macht aus einem diffusen Verdacht eine belastbare Tatsache, auf deren Basis sich Hosting und Schutzdienst gezielt ansprechen lassen.
Die wirtschaftlichen Folgen sind selbst bei kurzen Ausfällen real. 91 Prozent der Unternehmen beziffern den Schaden auf mehr als 30.000 US-Dollar pro Stunde Ausfallzeit durch DDoS (SentinelOne 2026). Kleine und mittlere Unternehmen geben für die Erholung nach einem Angriff im Schnitt rund 120.000 US-Dollar aus (Kaspersky Lab IT Security Risks Survey). Diese Zahlen entstehen nicht nur durch lange Komplettausfälle, sondern auch durch wiederholte kurze Störungen, die Conversion, Suchmaschinen-Crawling und Kundenvertrauen beschädigen. Wer Verfügbarkeit als Geschäftsgrundlage versteht, sollte den Zusammenhang von Ausfallzeit und Kosten kennen - der Beitrag zur Berechnung des Monitoring-ROI rechnet das durch.
Warum hauseigene Dashboards kurze Ausfälle übersehen
Ein internes Dashboard misst meist die Sicht des Servers auf sich selbst: CPU, Speicher, Antwortzeiten der Anwendung. Genau das ist bei einem volumetrischen DDoS aber blind. Wenn die Anbindung gesättigt ist, kommt der Datenverkehr gar nicht erst bis zur Anwendung - der Server fühlt sich gesund, während Besucher draußen vor einer nicht erreichbaren Seite stehen. Das Dashboard zeigt grün, weil es die fehlende Erreichbarkeit von außen schlicht nicht sehen kann. Diese Lücke zwischen Server läuft und Website erreichbar ist der Kern des Problems.
Interne Metriken messen den Server, nicht den Weg dorthin. Eine überlastete Anbindung oder ein DNS-Problem bleibt unsichtbar, solange der Prozess selbst läuft.
Prüfungen im Fünf-Minuten-Takt verpassen Stossangriffe unter einer Minute komplett. Erst ein enges Intervall verkleinert das blinde Fenster spürbar.
Ein einzelner Prüfpunkt kann selbst betroffen sein oder einen regionalen Ausfall für global halten. Mehrere Standorte trennen echten Ausfall von lokalem Rauschen.
Ein Log, das niemand in dem Moment liest, ist kein Alarm. Ohne sofortige Benachrichtigung ist der Angriff vorbei, bevor jemand reagiert.
Hinzu kommt die DNS-Ebene selbst. Richtet sich ein Amplification-Angriff gegen die autoritativen Nameserver einer Domain, ist die Website nicht wegen eines Serverproblems weg, sondern weil ihr Name nicht mehr aufgelöst werden kann. Ein internes Dashboard auf dem Webserver bemerkt das gar nicht - der Server ist ja erreichbar, nur findet ihn niemand mehr. Wie folgenreich Störungen auf der Auflösungsebene sein können, beleuchtet der Beitrag zur Resilienz von DNS-Resolvern bei einem TLD-Ausfall.
Was XICTRAQ überwacht
Gegen kurze, von außen sichtbare Ausfälle hilft eine kontinuierliche Prüfung von mehreren Standorten aus, kombiniert mit sofortiger Benachrichtigung. XICTRAQ misst Ihre Website so, wie ein Besucher sie erlebt - von außen, über mehrere geografisch getrennte Knoten und in engem Intervall.
Prüfungen von mehreren Standorten gleichzeitig (Nürnberg, Helsinki, Falkenstein). Erst wenn mehrere Knoten denselben Ausfall sehen, gilt er als bestätigt - das trennt echten Ausfall von lokalem Rauschen. Mehr dazu im Multi-Location-Monitoring.
Fällt die Seite aus, geht in Sekunden eine Benachrichtigung per E-Mail, Slack, Discord oder Telegram raus - schnell genug, um auch einen kurzen Stossangriff noch zu sehen.
Eine adaptive Baseline erkennt ungewöhnlich langsame Antworten, wie sie bei beginnender Überlastung auftreten - ein Frühsignal, bevor die Seite ganz wegbricht.
Neben der reinen Erreichbarkeit wird die DNS-Auflösung beobachtet, sodass auch ein Angriff auf die Nameserver-Ebene auffällt, nicht nur ein Webserver-Ausfall.
Jeder Vorfall wird mit Dauer und betroffenen Standorten protokolliert. Daraus entsteht eine belastbare Verfügbarkeitshistorie statt flüchtiger Logzeilen - Grundlage für SLA-Berechnungen.
Bleibt ein Alert unbestätigt, eskaliert die Benachrichtigung an die nächste Stufe. Geplante Wartungen lassen sich ausnehmen, damit echte Vorfälle nicht im Rauschen untergehen.
Da viele Angriffe unter einer Minute liegen, ist das Prüfintervall der entscheidende Hebel. Für geschäftskritische Seiten empfiehlt sich das engste verfügbare Intervall in Kombination mit mehreren Standorten - so schrumpft das blinde Zeitfenster, in dem ein kurzer Ausfall unbemerkt vorbeigeht.
Monitoring richtig einrichten - ohne Alarmmüdigkeit
Mehr Standorte und ein engeres Intervall erhöhen die Empfindlichkeit - und damit das Risiko von Fehlalarmen, wenn die Schwellen schlecht gesetzt sind. Der Schlüssel ist die Bestätigung über mehrere Knoten: Erst wenn unabhängige Standorte denselben Ausfall melden, löst der Alarm aus. Ein einzelner Knoten mit lokalem Netzproblem führt so nicht zu einem falschen Alarm. Wie sich Alerts so konfigurieren lassen, dass sie zuverlässig melden, ohne im Rauschen unterzugehen, beschreibt der Beitrag zu Monitoring-Alerts richtig konfigurieren.
Sinnvoll ist es außerdem, das Monitoring an Service-Level-Ziele zu koppeln. Wer ein Verfügbarkeitsbudget definiert, kann auf dessen Verbrauch reagieren, statt auf jeden einzelnen kurzen Zucker - ein Ansatz, den der Beitrag zu Error-Budget-Burn-Rate-Alerts vertieft. So entsteht eine Eskalation mit Augenmass: Ein einmaliger 30-Sekunden-Ausfall wird protokolliert, aber ein Muster wiederholter Stossangriffe löst die volle Aufmerksamkeit aus.
Wichtig ist die realistische Einordnung dessen, was Monitoring leistet. Externes Uptime-Monitoring wehrt einen DDoS nicht ab - das ist Aufgabe von Netz- und Hosting-Ebene. Was es leistet, ist die schnelle, objektive Feststellung, dass eine Störung vorliegt, samt Dauer, Umfang und betroffenen Standorten. Diese Information ist die Voraussetzung für jede Reaktion: das Hosting informieren, Schutzmechanismen aktivieren, Kunden über den Status informieren. Ohne diese Aussensicht bleibt ein kurzer Ausfall ein Gerücht; mit ihr wird er zu einem dokumentierten Vorfall, auf den sich reagieren lässt.
Der praktische Wert liegt im Zeitfaktor. Ohne externes Monitoring fällt ein kurzer DDoS-Ausfall erfahrungsgemäß erst auf, wenn ein Kunde sich beschwert oder eine Bestellung ausbleibt - oft Stunden später, wenn der Vorfall nicht mehr nachvollziehbar ist. Mit Multi-Location-Monitoring wird derselbe Ausfall in Sekunden sichtbar, mit Zeitstempel und Standortbezug. Diese Verkürzung von Stunden auf Sekunden ist der eigentliche Gewinn - sie verwandelt einen unsichtbaren Datenstrom in ein klares, dokumentiertes Signal.
Dieser Artikel basiert auf Daten von: Cloudflare DDoS Threat Report 2025 (31,4-Tbps-Rekord in 35 Sekunden, 47,1 Mio. Angriffe, 5.376 pro Stunde, Netzwerk-Layer-Verdreifachung, +700 % Angriffsgröße, DNS-Floods als häufigster L3/4-Vektor mit knapp einem Drittel Anteil, Multi-Vektor-Charakter großer Kampagnen), CISA TA14-017A UDP-Based Amplification Attacks und DNS Amplification Attacks (Verstärkungsfaktor 28 bis 54 für DNS, offene rekursive Resolver, gefälschte Quelladressen), Cloudflare DDoS Threat Report 2025 Q1 (89 % der Angriffe auf Netzwerkebene enden binnen 10 Minuten, hochvolumige Angriffe oft nur 35 bis 45 Sekunden), Kaspersky Lab IT Security Risks Survey (~120.000 USD durchschnittliche DDoS-Erholungskosten für KMU), SentinelOne DDoS Attack Statistics 2026 (44.000 Angriffe täglich, 91 % >30.000 USD pro Stunde, 59 %/51 % Kleinunternehmer-Annahme, 12-facher API-DDoS-Anstieg), Heimdal Most Common DNS Security Risks 2026 (BCP38, offene Resolver, Antwort-zu-Anfrage-Verhältnis).