DDoS-Angriffe erklärt: Arten, Erkennung und Abwehr (2026)

Ein DDoS-Angriff (Distributed Denial of Service) macht einen Server, einen Dienst oder ein ganzes Netzwerk für legitime Nutzer unerreichbar, indem er es mit einer Flut aus Anfragen oder Datenverkehr überlastet. Das Prinzip ist einfach, die Wirkung drastisch: Wenn tausende Geräte gleichzeitig dieselbe Website ansteuern, bleibt für echte Besucher keine Kapazität mehr übrig. Die Seite lädt nicht mehr, Nutzer sehen bestenfalls eine Fehlermeldung wie "HTTP 503 Service Unavailable".

Dieser Artikel erklärt DDoS von Grund auf und geht dabei bewusst tiefer als die meisten Übersichten. Sie erfahren nicht nur, welche drei Angriffsklassen es gibt, sondern auch mit welchen exakten Verstärkungsfaktoren volumetrische Angriffe arbeiten (von DNS mit Faktor 28 bis 54 bis Memcached mit dem 10.000- bis 51.000-Fachen), wie der neuartige HTTP/2-Rapid-Reset-Mechanismus (CVE-2023-44487) technisch funktioniert und wie sich die Rekord-Angriffe der Jahre 2024 und 2025 bis auf 31,4 Tbit/s hochgeschraubt haben.

Vor allem aber bekommen Sie etwas, das kaum ein anderer Grundlagenartikel liefert: echten, lauffähigen Abwehr-Code. Wir zeigen Rate-Limiting mit nginx wörtlich aus der offiziellen Dokumentation, SYN-Cookie- und iptables-Konfiguration gegen Protokollangriffe sowie eine Snort-Erkennungsregel direkt aus einem CISA-Advisory. Am Ende ordnen wir DDoS rechtlich ein (§ 303b StGB, ausdrücklich keine Rechtsberatung).

Was ist ein DDoS-Angriff?

Ein Denial-of-Service-Angriff (DoS) zielt darauf ab, einen Dienst so zu überlasten oder zu stören, dass er seine eigentliche Aufgabe nicht mehr erfüllen kann. Ein einfacher DoS-Angriff stammt aus einer einzelnen Quelle und lässt sich deshalb meist leicht blockieren: Man sperrt die eine störende IP-Adresse, und die Sache ist erledigt.

Ein distributed Denial of Service verteilt genau diese Last auf hunderte oder tausende Quellen gleichzeitig. Damit fällt die einfachste Abwehr weg, denn es gibt nicht mehr die eine IP, die man blockieren könnte. Die angreifenden Systeme sind über die ganze Welt verstreut, und ihr Datenverkehr sieht auf den ersten Blick oft wie ganz normaler Traffic aus.

Botnetze, die Infrastruktur der Angreifer

Die verteilten Quellen bilden in aller Regel ein Botnetz: ein Netzwerk aus mit Schadsoftware infizierten Geräten, die ein Angreifer aus der Ferne fernsteuert. Ein einzelnes gekapertes Gerät heißt Bot oder Zombie. Besonders beliebt sind schlecht abgesicherte IoT-Geräte wie Router, Überwachungskameras, Netzwerkspeicher oder inzwischen sogar smarte Fernseher, weil sie zahlreich, dauerhaft online und oft mit Standard-Passwörtern versehen sind.

Wer selbst kein Botnetz betreiben will, kann Angriffskapazität schlicht mieten. Sogenannte Booter- oder Stresser-Dienste bieten DDoS als Dienstleistung an, teils getarnt als legitime "Lasttest"-Werkzeuge. Damit sinkt die technische Einstiegshürde für einen Angriff auf nahezu null.

Warum jemand angreift

Die Motive sind vielfältig und reichen von finanziell bis politisch:

• Erpressung: Angreifer legen einen Dienst lahm oder drohen damit und fordern Lösegeld, oft in Kryptowährung (Ransom-DDoS).
• Sabotage durch Wettbewerber: Ein Konkurrent soll während einer wichtigen Phase, etwa im Weihnachtsgeschäft, ausfallen.
• Ideologie und Hacktivismus: politisch motivierte Angriffe gegen Regierungen, Behörden oder Unternehmen.
• Ablenkung: Ein lauter DDoS-Angriff bindet die Aufmerksamkeit des Sicherheitsteams, während parallel ein leiserer Angriff läuft, etwa Datendiebstahl oder Ransomware.
• Vandalismus und Geltungsdrang: Angriffe ohne konkretes Ziel, oft von wenig erfahrenen Tätern ("Script-Kiddies") über gemietete Booter-Dienste.

Die drei Klassen von DDoS-Angriffen

Fachlich etabliert und von Cloudflare, Imperva, Check Point und anderen einheitlich verwendet ist eine Einteilung in drei Klassen, orientiert an den Schichten des OSI-Modells. Jede Klasse erschöpft eine andere Ressource, und genau deshalb hilft eine Abwehr gegen die eine Klasse nicht automatisch gegen die andere. Verstärkungs- und Reflection-Techniken sind dabei keine eigene vierte Hauptklasse, sondern eine Methode innerhalb der volumetrischen und Protokollangriffe.

Volumetrische Angriffe (Layer 3/4)

Volumetrische Angriffe sättigen schlicht die Bandbreite zwischen dem Ziel und dem Internet. Sie sind die häufigste und, gemessen in Bit pro Sekunde, die spektakulärste Angriffsform. Der Server muss dabei gar nicht "besiegt" werden: Es reicht, die Leitung dorthin zu verstopfen.

• UDP-Flood: UDP ist verbindungslos, es gibt keinen Handshake. Der Angreifer schickt große Mengen UDP-Pakete an zufällige Ports. Der Server sucht für jeden Port nach einem lauschenden Dienst, findet keinen und antwortet mit einer "Destination Unreachable"-ICMP-Nachricht. Beides, das Nachschlagen und das Antworten, kostet Ressourcen.
• ICMP-Flood (Ping-Flood): Das Ziel wird schneller mit ICMP-Echo-Anfragen überschwemmt, als es sie beantworten kann.
• DNS-Amplification und andere Verstärkungsangriffe: die effizienteste Methode, um mit wenig eigener Bandbreite viel Schaden anzurichten (siehe nächster Abschnitt).

Verstärkung und Reflection: die Amplification-Faktoren

Bei einem verstärkten Reflection-Angriff (Distributed Reflective Denial of Service, DRDoS) nutzt der Angreifer öffentlich erreichbare UDP-Server als unfreiwillige Verstärker. Der Trick beruht auf zwei Eigenschaften von UDP: Es ist verbindungslos, und es prüft die Absenderadresse nicht. Der Angreifer fälscht (spooft) die Quell-IP auf die Adresse des Opfers und sendet eine kleine Anfrage an einen offenen Server. Dieser antwortet mit einer erheblich größeren Antwort, und zwar an das Opfer statt an den Angreifer.

Wie groß dieser Hebel ist, quantifiziert das CISA-Advisory TA14-017A über den sogenannten Bandwidth Amplification Factor (BAF), also das Verhältnis von Antwortgröße zu Anfragegröße. Die folgende Tabelle ist wörtlich aus diesem Advisory übernommen (die BAF-Daten selbst stammen aus der Forschung von Christian Rossow):

Der Spitzenreiter Memcached ist deshalb so extrem, weil ein einziges gefälschtes Paket eine Antwort auslösen kann, die zehntausendfach größer ist. Ein Angreifer mit bescheidener eigener Anbindung kann so einen Angriff im Terabit-Bereich erzeugen. Genau dieser Effekt macht Verstärkungsangriffe zur bevorzugten Waffe für Rekordwerte.

Protokollangriffe (Layer 3/4)

Protokollangriffe sättigen nicht die Bandbreite, sondern erschöpfen die Ressourcen, mit denen Server, Firewalls und Load Balancer Verbindungen verwalten. Sie können deshalb gefährlich sein, ohne besonders "groß" zu wirken: Ein Server, der problemlos 10 Gbit/s legitimen Traffic verkraftet, kann von einer SYN-Flood mit nur 500 Mbit/s in die Knie gehen.

• SYN-Flood: Beim normalen TCP-Verbindungsaufbau sendet der Client ein SYN, der Server antwortet mit SYN-ACK und reserviert Speicher, der Client bestätigt mit ACK (der Drei-Wege-Handshake). Bei einer SYN-Flood schickt der Angreifer massenhaft SYN-Pakete, sendet aber nie das abschließende ACK. Der Server hält die Verbindungen halb offen und wartet, bis seine Verbindungstabelle voll ist und keine legitimen Verbindungen mehr angenommen werden.
• Ping of Death: Überlange Pakete jenseits des IPv4-Limits von 65.535 Bytes können bei der Reassemblierung Pufferüberläufe auslösen. In modernen Systemen ist dies weitgehend behoben.
• Smurf- und Fraggle-Angriffe: Reflektion über Broadcast-Adressen, heute weitgehend durch Deaktivieren von Directed Broadcasts auf Routern entschärft.

Die klassische Gegenmaßnahme gegen SYN-Floods sind SYN-Cookies: Statt für jede halboffene Verbindung Speicher zu reservieren, kodiert der Server den Verbindungszustand kryptografisch in die Sequenznummer des SYN-ACK. Er muss sich also nichts merken. Erst wenn ein gültiges ACK zurückkommt, rekonstruiert er den Zustand aus dem Cookie. Damit läuft die Verbindungstabelle nicht mehr voll. Die konkrete Aktivierung zeigen wir im Abwehr-Abschnitt.

Angriffe auf die Anwendungsschicht (Layer 7)

Layer-7-Angriffe sind die tückischsten, weil ihr Datenverkehr auf den unteren Schichten völlig legitim aussieht. Sie zielen nicht auf Bandbreite oder Verbindungstabellen, sondern auf die teure Arbeit, die eine Anwendung pro Anfrage leistet: eine Datenbankabfrage, das Rendern einer Seite, eine Suchoperation. Eine einzige HTTP-Anfrage kann den Server ein Vielfaches dessen kosten, was sie den Angreifer kostet.

• HTTP-Flood: scheinbar normale GET- oder POST-Anfragen in großer Zahl, die jeweils echte Verarbeitung auslösen. Weil sie wie legitimer Traffic aussehen, sind sie mit reinen Netzwerkwerkzeugen kaum zu unterscheiden.
• Slowloris: das Gegenteil einer Flut. Der Angreifer öffnet viele Verbindungen und sendet die HTTP-Header absichtlich extrem langsam und nie vollständig. Der Server hält jede Verbindung offen und wartet, bis sein Verbindungspool erschöpft ist, und das mit minimaler Bandbreite.
• HTTP/2 Rapid Reset: der bedeutendste neue Layer-7-Mechanismus seit Jahren, dem wir einen eigenen Abschnitt widmen.

HTTP/2 Rapid Reset (CVE-2023-44487) im Detail

Kein einziger der gängigen DDoS-Übersichtsartikel erklärt diesen Angriff, obwohl er die schwerwiegendste neue DDoS-Technik seit 2023 ist und den bis dahin gültigen Rekord für Anfragen pro Sekunde nahezu verdreifachte. Grund genug, hier tief einzusteigen.

Warum HTTP/2 den Angriff überhaupt ermöglicht

HTTP/1.1 verarbeitet Anfragen über eine Verbindung im Wesentlichen seriell: eine Anfrage, eine Antwort, die nächste Anfrage. HTTP/2 führt Stream-Multiplexing ein: Über eine einzige TCP-Verbindung laufen viele gleichzeitige Streams, jeder mit eigener Stream-ID. Der Server kündigt dabei ein Limit an gleichzeitigen Streams an, typischerweise 100 pro Verbindung, um sich vor Überlastung zu schützen.

Genau dieses Limit hebelt der Angriff aus. HTTP/2 kennt einen RST_STREAM-Frame, mit dem ein Client einen einzelnen Stream sofort abbrechen kann, ganz legitim gedacht, etwa wenn ein Nutzer eine Seite verlässt, bevor sie fertig geladen ist.

Der Mechanismus

Der Angriff kombiniert beides zu einem simplen, brutal effizienten Muster: Der Client öffnet einen Stream (sendet einen HEADERS-Frame, also die Anfrage) und bricht ihn im selben Moment wieder ab (sendet RST_STREAM). Sobald der Reset eintrifft, gilt der Stream als geschlossen und zählt nicht mehr gegen das Concurrency-Limit. Der Client kann also sofort den nächsten Stream öffnen, ohne je auf eine Antwort zu warten.

Auf dem Server aber ist die Arbeit längst angestoßen: Anfrage lesen, weiterreichen, Backend belasten. Cloudflare beschreibt es so, dass ein bösartiger Client "eine gewaltige Kette aus Anfragen und Resets" gleich zu Beginn der Verbindung sendet und die Server diese "eifrig alle lesen und die Upstream-Server belasten". Das offiziell angekündigte Limit von 100 gleichzeitigen Streams wird faktisch bedeutungslos, weil jeder Stream sofort wieder freigegeben wird.

In einer Wireshark-Analyse von 1.000 bösartigen Anfragen zeigte Cloudflare, wie kompakt das ist: Der erste HEADERS-Frame war 26 Bytes groß, jeder weitere dank HPACK-Kompression nur noch 9 Bytes. Ein einzelnes Netzwerkpaket enthielt 525 Anfragen, bis hinauf zu Stream 1051, obwohl der Server nur 100 gleichzeitige Streams erlaubt hatte.

Warum das so gefährlich ist

Klassische Layer-7-Floods brauchen entweder viele Verbindungen oder müssen auf die serielle Verarbeitung warten. Rapid Reset umgeht beides. Eine einzige Verbindung erzeugt tausende Anfragen pro Sekunde. Deshalb genügte Cloudflare zufolge ein vergleichsweise winziges Botnetz von nur rund 20.000 Maschinen, um einen Rekordangriff zu fahren, ein Bruchteil dessen, was ein volumetrischer Angriff dieser Größe erfordern würde.

Abwehr

• Patchen: Server- und Proxy-Software aktualisieren, sobald Hersteller-Patches vorliegen. CISA veröffentlichte das Advisory am 10. Oktober 2023 gemeinsam mit den koordinierten Hinweisen von Cloudflare, Google, AWS, NGINX und Microsoft. Die Lücke wurde bereits vor Verfügbarkeit eines Patches ausgenutzt, von August bis Oktober 2023.
• RST_STREAM-Rate überwachen: Verbindungen, die auffällig viele Streams sofort zurücksetzen, gezielt schließen, ohne legitime Stornierungen zu bestrafen.
• Concurrency-Limit senken: Cloudflare reduzierte das Limit an gleichzeitigen Streams vorübergehend von 100 auf 64, bevor es aus Kompatibilitätsgründen wieder angehoben wurde.
• Wiederholungstäter aussperren: Cloudflares "IP Jail" sperrt eine auffällige IP nicht nur vom angegriffenen Dienst, sondern verbietet ihr für eine Weile HTTP/2 zu jeder anderen Domain auf der Plattform.

Rekord-Angriffe: eine belegte Chronologie

Über Rekord-Angriffe kursieren viele Zahlen, die oft durcheinandergeworfen werden. Deshalb hier zwei getrennte Chronologien, jede Zahl mit eigenem Datum und eigenem Kontext. Wichtig: Anfragen pro Sekunde (rps) und Bit pro Sekunde (bps) messen zwei völlig verschiedene Dinge und dürfen nicht verglichen werden.

Rapid Reset in Zahlen (2023, gemessen in rps)

Als CVE-2023-44487 im Oktober 2023 offengelegt wurde, veröffentlichten mehrere Anbieter ihre eigenen Peak-Werte desselben Angriffsphänomens, jeweils auf ihrer eigenen Infrastruktur gemessen. Es handelt sich also nicht um widersprüchliche Angaben zu einer Zahl, sondern um unabhängige Messungen:

• Cloudflare: 201 Millionen rps (Angriffsfenster 25. bis 29. August 2023). Das war damals fast das Dreifache des vorherigen Rekords von 71 Millionen rps, erzeugt von einem Botnetz aus nur rund 20.000 Maschinen.
• Google: 398 Millionen rps (Peak über 2 Minuten, Zeitraum Ende August bis September 2023). Das ist der höchste primärbelegte Rapid-Reset-Wert und übertraf Googles eigenen vorherigen Rekord von 46 Millionen rps um mehr als das Achtfache.
• AWS: rund 155 Millionen rps. Diese Zahl kursiert breit als dritter Vergleichswert, steht aber ausdrücklich nicht im offiziellen AWS-Security-Bulletin AWS-2023-011, das keine konkrete rps-Zahl nennt. Sie ist daher nur als Sekundärbericht zu behandeln, nicht als offizielle AWS-Aussage.

Volumetrische Rekorde (2024 bis 2025, gemessen in bps)

Parallel dazu explodierten die rein volumetrischen Rekorde. Cloudflare meldete innerhalb von rund 14 Monaten dreimal in Folge einen neuen Höchstwert:

• 5,6 Tbit/s am 29. Oktober 2024, Dauer 80 Sekunden. UDP-DDoS gegen einen Magic-Transit-Kunden (ein ostasiatischer Internetanbieter), Quelle war eine Mirai-Variante aus über 13.000 IoT-Geräten.
• 7,3 Tbit/s Mitte Mai 2025, Dauer 45 Sekunden. UDP-Floods machten 99,996 % des Angriffstraffics aus; insgesamt wurden 37,4 Terabyte in dieser knappen Dreiviertelminute zugestellt, verteilt über 122.145 Quell-IPs aus 161 Ländern.
• 31,4 Tbit/s am 19. Dezember 2025, Dauer nur 35 Sekunden. Zugeschrieben wird der Angriff dem Aisuru-Kimwolf-Botnet, das laut Cloudflare vorwiegend aus mit Schadsoftware infizierten Android-TV-Geräten besteht, geschätzt 1 bis 4 Millionen infizierte Hosts.

Zur Einordnung des Gesamttrends: Cloudflare zählte 2025 insgesamt 47,1 Millionen DDoS-Angriffe, ein Plus von 121 % gegenüber 2024. Auffällig ist die extreme Kürze der Rekord-Angriffe von 35 bis 80 Sekunden. Solche Kurzangriffe sind absichtlich so ausgelegt, dass sie ihr Ziel erreichen, bevor ein von Menschen ausgelöster Alarm überhaupt greifen kann. Genau deshalb braucht wirksame Abwehr eine stets aktive, automatisierte Erkennung statt einer reaktiven Handarbeit.

Ein Vorbehalt zur Aktualität: Der 31,4-Tbit/s-Wert ist der zum Rechercheschluss (Anfang 2026) jüngste bekannte Rekord. Da Cloudflare in kurzer Folge mehrfach neue Höchstwerte meldete, kann dieser Stand schnell überholt sein.

Das Mirai-Botnet als Lehrstück

Wenn ein einzelnes Botnetz stellvertretend für die IoT-DDoS-Ära steht, dann Mirai. Die peer-reviewte USENIX-Studie "Understanding the Mirai Botnet" (2017) liefert dazu ungewöhnlich präzise Zahlen, die über das übliche "es gibt Botnetze"-Niveau weit hinausgehen.

Mirai ist wurmartige Schadsoftware, die schlecht gesicherte IoT-Geräte kapert. Der Ablauf: Zuerst durchsucht Mirai per schnellem, zustandslosem TCP-SYN-Scan zufällige IPv4-Adressen auf den Telnet-Ports 23 und 2323. Bei einem Treffer folgt ein Brute-Force-Login mit Kombinationen aus einer fest einprogrammierten Liste von 62 Standard-Zugangsdaten, genau die Werkskombinationen, die Hersteller von Routern und Kameras massenhaft ausliefern. Der Vorgänger BASHLITE kam noch mit 6 Benutzernamen und 14 Passwörtern aus.

Die Wachstumsdynamik war beeindruckend: Innerhalb der ersten 10 Minuten waren 11.000 Geräte infiziert, nach 20 Stunden bereits 64.500. Der Peak lag Ende November 2016 bei rund 600.000 gleichzeitig infizierten Geräten. Insgesamt wurde Mirai mit über 15.000 Angriffen in Verbindung gebracht.

Drei Vorfälle machten Mirai berühmt:

• KrebsOnSecurity, 21. September 2016: ein Angriff jenseits von 600 Gbit/s, einer der größten damals dokumentierten (dieser Wert stammt aus dem Blog von Brian Krebs, den die USENIX-Studie zitiert).
• Dyn, 21. Oktober 2016: Der Angriff auf den DNS-Anbieter Dyn riss zahlreiche bekannte Websites in den Ausfall, weil deren Namensauflösung nicht mehr funktionierte.
• Deutsche Telekom, 26. November 2016: Eine Mirai-Variante versuchte über das CPE-WAN-Management-Protokoll (TR-069/CWMP, Port TCP/7547), rund 900.000 Telekom-Router zu übernehmen. Die Speedport-Router waren gegen diesen Exploit jedoch gar nicht verwundbar, der Infektionsversuch schlug fehl. Unter der Flut fehlerhafter Exploit-Anfragen stürzten die Geräte allerdings ab, und rund 900.000 Anschlüsse fielen als Kollateralschaden aus. Der dafür verantwortliche Täter wurde im Februar 2017 verhaftet.

Die Lehre aus Mirai ist unbequem einfach: Der Angriff war nur möglich, weil Millionen Geräte mit Standard-Passwörtern am Netz hingen. Konsequentes Ändern von Werkszugangsdaten, Firmware-Updates und das Abschalten unnötiger Dienste hätten dem Botnetz die Grundlage entzogen.

DDoS-Angriffe erkennen

Je früher ein Angriff auffällt, desto eher lässt er sich eindämmen. Die folgenden Anzeichen deuten auf einen laufenden DDoS-Angriff hin, wobei einzelne davon auch harmlose Ursachen haben können.

• Ungewöhnliche Traffic-Spitzen, besonders wenn sie sich auf einen einzelnen Endpunkt konzentrieren, während legitimer Traffic normalerweise breit verteilt ist.
• Geografische Auffälligkeiten: ein plötzlicher Schwall aus einer Region, die sonst kaum Nutzer stellt.
• Uniforme Anfragesignaturen: identische User-Agents, Header oder Anfragemuster in großer Zahl, ein Hinweis auf automatisierten statt organischen Traffic.
• CPU- oder Speicherauslastung am Anschlag, ohne dass die Bandbreite gesättigt ist, ein typisches Zeichen für einen Layer-7-Angriff.
• Fehler bei der DNS-Auflösung oder gehäufte "HTTP 503"-Antworten.
• Langsame oder ganz unerreichbare Dienste ohne erkennbaren betrieblichen Grund.

Praktisch heißt das: Wer keine kontinuierliche Überwachung mit sinnvollen Schwellenwerten je Endpunkt betreibt, bemerkt den Angriff oft erst, wenn Kunden sich beschweren. Logs sollten über Netzwerk-, Anwendungs- und CDN-Ebene korreliert und in ein SIEM gestreamt werden, damit Muster früh sichtbar werden.

DDoS abwehren: Konzepte und lauffähiger Code

Wirksame Abwehr ist mehrschichtig, weil jede Angriffsklasse eine andere Ressource trifft. Wir gehen von den konzeptionellen Bausteinen zu konkretem, lauffähigem Konfigurationscode über. Ein wichtiger Vorbehalt vorweg: Rate-Limiting auf dem eigenen Server hilft gegen Application-Layer-Floods, aber nicht gegen große volumetrische Angriffe. Wenn die Leitung zu Ihrem Rechenzentrum bereits gesättigt ist, kommt Ihr nginx gar nicht mehr zum Zug. Volumetrische Angriffe müssen deshalb weiter oben abgefangen werden, im Netz des Providers oder eines Scrubbing-Dienstes.

Die konzeptionellen Bausteine

• Anycast: Dieselbe IP-Adresse wird an vielen geografisch verteilten Standorten angekündigt. Angriffstraffic verteilt sich automatisch auf das nächstgelegene Rechenzentrum, sodass kein einzelner Standort die volle Last trägt. Cloudflare mitigierte den 7,3-Tbit/s-Angriff automatisch über 477 Rechenzentren an 293 Standorten.
• Scrubbing-Center: Der gesamte Traffic wird durch spezialisierte Reinigungszentren geleitet, die bösartigen Verkehr herausfiltern und nur legitimen an den Ursprung weiterreichen.
• CDN und Origin-Verschleierung: Ein Content Delivery Network cached statische Inhalte am Rand und verbirgt die echte IP des Ursprungsservers, sodass dieser nicht direkt angegriffen werden kann.
• Blackhole-Routing: eine Notfallmaßnahme, bei der aller Traffic zur angegriffenen IP in ein "schwarzes Loch" (eine Null-Route) geleitet und verworfen wird. Das stoppt den Angriff, sperrt aber auch alle legitimen Nutzer aus, also ausdrücklich ein letztes Mittel.
• BGP Flowspec und Remotely Triggered Blackhole (RTBH): erlauben es, Filterregeln beziehungsweise Blackhole-Anweisungen dynamisch über BGP an Upstream-Provider zu verteilen, idealerweise vorab mit dem ISP abgestimmt.
• Ingress-Filtering nach BCP 38 (RFC 2827): die Grundlagenmaßnahme gegen gefälschte Quelladressen. Netzbetreiber sollen an ihren Rändern nur Pakete durchlassen, deren Quelladresse zum tatsächlich zuständigen Adressbereich passt. Das eliminiert Spoofing und damit die Basis von Reflection-Angriffen und erschwert die Verschleierung erheblich. Der Standard stammt aus dem Jahr 2000 und ist bis heute die zentrale Anti-Spoofing-Empfehlung, auf die auch das CISA-Amplification-Advisory verweist.

Rate-Limiting mit nginx (Layer 7)

Gegen HTTP-Floods ist ein Rate-Limit pro Quell-IP eine wirksame und einfache Maßnahme. Das nginx-Modul ngx_http_limit_req_module arbeitet nach dem "Leaky Bucket"-Prinzip. Die folgende Basiskonfiguration stammt wörtlich aus der offiziellen nginx-Dokumentation:

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

    ...

    server {

        ...

        location /search/ {
            limit_req zone=one burst=5;
        }
    }
}

limit_req_zone legt im http-Kontext eine Shared-Memory-Zone namens one (10 MB) an und begrenzt auf eine Anfrage pro Sekunde je IP-Adresse. Der Schlüssel $binary_remote_addr wird bewusst gegenüber $remote_addr bevorzugt, weil die Binärform stets nur 4 Bytes (IPv4) oder 16 Bytes (IPv6) belegt und der Speicherbedarf damit exakt kalkulierbar bleibt. burst=5 erlaubt kurzzeitige Spitzen von bis zu fünf zusätzlichen Anfragen, die verzögert abgearbeitet werden; darüber hinausgehende Anfragen werden mit Statuscode 503 abgewiesen.

Wer Spitzen sofort und ohne Verzögerung durchlassen will, ergänzt nodelay:

limit_req zone=one burst=5 nodelay;

In der Praxis staffelt man oft mehrere Zonen, etwa ein striktes Limit pro IP und ein großzügigeres pro Server-Name:

limit_req_zone $binary_remote_addr zone=perip:10m rate=1r/s;
limit_req_zone $server_name zone=perserver:10m rate=10r/s;

server {
    ...
    limit_req zone=perip burst=5 nodelay;
    limit_req zone=perserver burst=10;
}

SYN-Cookies und iptables (Layer 3/4)

Gegen SYN-Floods aktivieren Sie unter Linux zuerst SYN-Cookies. Der Kernel kodiert dann den Verbindungszustand in die Sequenznummer, statt für jede halboffene Verbindung Speicher zu reservieren:

# Sofort aktivieren
sysctl -w net.ipv4.tcp_syncookies=1

# Dauerhaft in /etc/sysctl.conf eintragen
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
sysctl -p

Ergänzend lässt sich die Rate neuer SYN-Pakete mit iptables begrenzen. Das folgende Regelpaar akzeptiert im Schnitt ein neues SYN pro Sekunde mit einem kurzen Puffer von drei und verwirft alles Weitere:

iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --syn -j DROP

Passen Sie die Werte an Ihre legitime Last an, zu strenge Limits sperren echte Nutzer aus. Für stark frequentierte Dienste sind pro-IP-Limits mit dem hashlimit-Modul die bessere Wahl.

Erkennung von Amplification-Traffic mit Snort

Reflection-Angriffe lassen sich unter anderem daran erkennen, dass große UDP-Antworten eintreffen, ohne dass zuvor eine passende Anfrage hinausging (zustandsloser UDP-Verkehr). Das CISA-Advisory TA14-017A enthält dafür ein Snort-Regelbeispiel, das genau diesen Fall alarmiert. Es ist hier eng an dieses Advisory angelehnt und muss laut Advisory an die eigene Umgebung mit einer Whitelist bekannter Dienste angepasst werden:

var HOME_NET [10.10.10.20]

preprocessor stream5_global: track_ip yes, track_tcp yes, track_udp yes, track_icmp no, max_tcp 262144, max_udp 131072
preprocessor stream5_ip: timeout 180
preprocessor stream5_tcp: policy first, use_static_footprint_sizes
preprocessor stream5_udp: timeout 180, ignore_any_rules

alert udp HOME_NET 1024: -> any any (msg:"UDP Session start"; flowbits:set,logged_in; flowbits:noalert; sid: 1001;)
alert udp any any -> HOME_NET 1024: (msg:"UDP Stateless"; flowbits:isnotset,logged_in; sid: 1002)

Die Logik: Die erste Regel markiert eine UDP-Sitzung, die von innen (HOME_NET) ausgeht, mit einem Flowbit. Die zweite Regel schlägt Alarm, wenn eine UDP-Antwort von außen an einen hohen Port im eigenen Netz eintrifft, ohne dass zuvor dieses Flowbit gesetzt wurde, also ohne vorausgegangene eigene Anfrage.

Sofortmaßnahmen während eines Angriffs

Wenn ein Angriff läuft, zählt strukturiertes Vorgehen mehr als hektische Einzelaktionen. Ein bewährter Ablauf:

1. Krisenteam aktivieren: IT, Sicherheitsverantwortliche, Geschäftsleitung und Kommunikation koordinieren die Reaktion. Betroffene Systeme und verdächtige IP-Adressen sauber dokumentieren, das hilft später bei Analyse und möglicher Strafverfolgung.
2. Provider und Upstream kontaktieren: ISPs und Scrubbing-Dienste können schädlichen Traffic auf Netzwerkebene filtern, bevor er Ihre Systeme erreicht. Halten Sie die Notfallkontakte griffbereit, bevor der Ernstfall eintritt.
3. Server härten: Verbindungen pro IP begrenzen, SYN-Cookies aktivieren, Traffic auf notwendige Ports (etwa 80 und 443) beschränken, offensichtlich bösartige Quellen gezielt blackholen.
4. Angriffsmuster analysieren: Firewalls und Mitigation-Systeme können anhand wiederkehrender Muster in HTTP-Headern gezielt filtern.
5. Externe Spezialisten einbeziehen: Reicht die interne Kapazität nicht, sollten zertifizierte Incident-Response-Dienstleister unterstützen.

Vorbeugend gilt: kritische Dienste inventarisieren, Notfallpläne und Runbooks je Angriffstyp schreiben, das Netzwerk segmentieren, kontinuierlich überwachen und einen spezialisierten DDoS-Schutz vorhalten, bevor er gebraucht wird.

Rechtliche Einordnung in Deutschland

Hinweis: Der folgende Abschnitt ist eine allgemeine Einordnung und ausdrücklich keine Rechtsberatung. Die strafrechtliche Bewertung eines konkreten Sachverhalts obliegt Gerichten und Staatsanwaltschaften und hängt von den Umständen des Einzelfalls ab.

In Deutschland können DDoS-Angriffe als Computersabotage nach § 303b StGB strafbar sein. Die Norm stellt die Störung einer Datenverarbeitung von wesentlicher Bedeutung unter Strafe. Der Grundtatbestand (Absatz 1) sieht Freiheitsstrafe bis zu drei Jahren oder Geldstrafe vor. Ist die betroffene Datenverarbeitung für einen fremden Betrieb, ein Unternehmen oder eine Behörde von wesentlicher Bedeutung, erhöht sich der Rahmen auf bis zu fünf Jahre (Absatz 2). Bereits der Versuch ist strafbar (Absatz 3), und in besonders schweren Fällen reicht der Strafrahmen von sechs Monaten bis zu zehn Jahren (Absatz 4). Absatz 5 verweist über § 202c StGB auch auf die Strafbarkeit von Vorbereitungshandlungen, etwa das Bereitstellen entsprechender Werkzeuge.

Der Begriff "DDoS" taucht im Gesetzestext selbst nicht auf. Die Einordnung als Fall des § 303b, typischerweise unter der Variante der Eingabe oder Übermittlung von Daten in Schädigungsabsicht (Absatz 1 Nummer 2), ist eine juristische Subsumtion aus der Kommentarliteratur, keine Aussage des Normtextes.

Wichtig auch: Das Mieten oder Betreiben von Booter- und Stresser-Diensten ist nicht etwa eine legale Grauzone. Nach Sekundärberichten haben Ermittlungsbehörden im Rahmen der internationalen "Operation PowerOFF" wiederholt solche Plattformen abgeschaltet und Nutzer identifiziert. Diese Angabe stammt aus Sekundärquellen und nicht aus einer amtlichen Primärquelle, die genauen Zahlen sind daher mit Vorsicht zu behandeln.

Häufige Fragen zu DDoS-Angriffen

Was ist der Unterschied zwischen DoS und DDoS?

Ein DoS-Angriff kommt aus einer einzigen Quelle und lässt sich meist durch Blockieren dieser Quelle stoppen. Ein DDoS-Angriff verteilt die Last auf viele Quellen (ein Botnetz), sodass einfaches IP-Blocking nicht mehr genügt.

Kann man einen DDoS-Angriff komplett verhindern?

Vollständig verhindern lässt er sich nicht, wohl aber wirksam abmildern. Eine Kombination aus Anycast, Scrubbing, CDN, Rate-Limiting und einer vorbereiteten Incident-Response reduziert Wahrscheinlichkeit und Auswirkung erheblich.

Reicht eine Firewall gegen DDoS?

Nein. Eine klassische Firewall filtert bekannte bösartige Muster, ist aber gegen große volumetrische Angriffe (die schon die Leitung sättigen) und gegen als legitim getarnte Layer-7-Angriffe wenig wirksam. Dafür braucht es spezialisierte, möglichst vorgelagerte Mitigation.

Sind kurze Angriffe harmlos?

Nein, im Gegenteil. Die jüngsten Rekord-Angriffe dauerten nur 35 bis 80 Sekunden. Solche Kurzangriffe sind gezielt so ausgelegt, dass sie zuschlagen, bevor eine manuelle Reaktion greift. Genau deshalb ist stets aktive, automatisierte Abwehr entscheidend.

Ist ein DDoS-Angriff strafbar?

Ja. In Deutschland können DDoS-Angriffe als Computersabotage nach § 303b StGB strafbar sein, mit Freiheitsstrafe bis zu drei Jahren, bei einer für einen Betrieb oder eine Behörde wesentlichen Datenverarbeitung bis zu fünf Jahren. Bereits der Versuch und Vorbereitungshandlungen (etwa das Bereitstellen von Angriffswerkzeugen) sind strafbar. Dies ist eine allgemeine Einordnung und keine Rechtsberatung, die Bewertung eines Einzelfalls obliegt den Gerichten.

Fazit

DDoS-Angriffe sind kein Randphänomen mehr, sondern ein alltägliches, industrialisiertes Werkzeug mit Millionen Vorfällen pro Jahr und Rekorden, die sich im Halbjahrestakt überbieten. Wer sie verstehen will, muss die drei Klassen auseinanderhalten: volumetrische Angriffe sättigen Bandbreite (mit Verstärkungsfaktoren bis zum 51.000-Fachen bei Memcached), Protokollangriffe erschöpfen Verbindungstabellen, und Layer-7-Angriffe treffen die teure Arbeit der Anwendung. Der HTTP/2-Rapid-Reset-Angriff zeigt, wie ein einzelner Protokolldetail-Missbrauch mit nur 20.000 Bots neue Rekorde bricht.

Die gute Nachricht: Die Abwehr ist ausgereift. Ingress-Filtering nach BCP 38 nimmt Reflection-Angriffen die Grundlage, SYN-Cookies neutralisieren SYN-Floods, Rate-Limiting bremst HTTP-Floods, und Anycast mit Scrubbing verteilt selbst Terabit-Angriffe auf hunderte Standorte. Entscheidend ist, diese Bausteine vorbereitet und automatisiert zu haben, bevor der Angriff kommt, denn moderne Kurzangriffe sind vorbei, bevor ein Mensch reagieren kann.