Was ist ein DDoS-Angriff? Technik, Ebenen und Abwehr

Ein DDoS-Angriff ist der Versuch, einen Dienst durch künstlich erzeugte Überlast unerreichbar zu machen, ausgeführt gleichzeitig von sehr vielen verschiedenen Absendern. Die Abkürzung steht für Distributed Denial of Service, also für eine verteilt herbeigeführte Dienstverweigerung. Angegriffen wird dabei weder der Inhalt eines Servers noch eine Sicherheitslücke in seiner Software, sondern eine Ressource, die endlich ist: die Bandbreite der Leitung, die Paketrate der Netzwerkkarte, ein Platz in einer Zustandstabelle des Kernels oder die Rechenzeit, die die Anwendung für eine einzige Anfrage aufwendet. Ist eine dieser vier Ressourcen belegt, kommen echte Nutzer nicht mehr durch, und zwar ohne dass jemand in das System eingebrochen wäre.

Dieser Beitrag ist der Einstieg in das Thema. Er erklärt die drei Ebenen, auf denen Angriffe stattfinden, mit welchen Verstärkungsfaktoren aus einem Byte Anfrage 51.000 Byte Antwort werden, woher die Angriffskapazität kommt und was sie auf dem Markt kostet, woran Sie einen Angriff an Ihren eigenen Messwerten erkennen, was auf dem Server selbst noch hilft und wo diese Grenze genau verläuft. Alle Zahlen sind mit Quelle benannt, damit Sie sie nachprüfen können. Wenn Ihr Dienst gerade steht, lesen Sie zuerst den Abschnitt "Was im Angriffsfall zu tun ist" und messen, statt zu schrauben.

Was ein DDoS-Angriff technisch ist

Jeder DDoS-Angriff lebt von einer Asymmetrie: Ein Paket zu senden muss den Angreifer weniger kosten als es das Ziel kostet, dieses Paket zu verarbeiten. Alles andere ist nur die Frage, an welcher Stelle diese Asymmetrie am größten ist. Es gibt genau vier Stellen, und jede hat eine harte Obergrenze, die sich ausrechnen lässt.

Die Bandbreite der Leitung. Ein Anschluss mit 1 Gbit/s transportiert 125 Megabyte pro Sekunde, mehr nicht. Wer mehr schickt, erzeugt Verluste, und die Verluste treffen die Pakete Ihrer Nutzer genauso wie die des Angreifers, weil ein voller Anschluss nicht auswählt.

Die Paketrate. Das kleinste zulässige Ethernet-Paket ist 64 Byte lang und belegt mit Präambel und Paketlücke 84 Byte auf der Leitung. In 1 Gbit/s passen davon rund 1,49 Millionen pro Sekunde. Ein gewöhnlicher Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend, bevor er beginnt zu verwerfen. Die Paketrate ist deshalb fast immer die Grenze, die vor der Bandbreite erreicht wird.

Die Zustandstabellen. Der Kernel merkt sich halb geöffnete TCP-Verbindungen und Paketflüsse. Diese Tabellen sind zahlenmäßig begrenzt, nicht in Bit pro Sekunde. Sie lassen sich mit sehr wenig Bandbreite füllen, wenn jedes Paket eine neue Absenderadresse trägt.

Die Rechenzeit der Anwendung. Eine Suchanfrage, ein Anmeldeversuch mit Passwortprüfung oder eine Serverabfrage, die eine ganze Mod-Liste zurückgibt, kostet das Ziel tausendfach mehr als den Absender. Hier braucht ein wirksamer Angriff oft nicht einmal 10 Mbit/s.

DoS und DDoS: der Unterschied, den man messen kann

Die begriffliche Grundlage liefert RFC 4732, "Internet Denial-of-Service Considerations", eine informationelle Veröffentlichung der IETF vom November 2006. Dort heißt es wörtlich: "A Denial-of-Service (DoS) attack is an attack in which one or more machines target a victim and attempt to prevent the victim from doing useful work." Ein DoS-Angriff ist also über die Wirkung definiert, nicht über die Anzahl der Quellen. Verteilt, also DDoS, ist er dann, wenn diese Quellen zahlreich und voneinander unabhängig sind.

Praktisch zählt der Unterschied an genau einer Stelle: an der Länge Ihrer Sperrliste. Einen DoS-Angriff aus einer Quelle beenden Sie mit einer Regel. Cloudflare hat im Mai 2025 einen Angriff dokumentiert, der aus 122.145 verschiedenen Quelladressen aus 161 Ländern und 5.433 autonomen Systemen kam, im Schnitt 26.855 neue Adressen pro Sekunde, in der Spitze 45.097. Gegen so etwas gibt es keine Sperrliste, die schnell genug wächst, und jeder Eintrag in ihr kostet zusätzlich Speicher und Suchzeit auf dem Gerät, das ohnehin schon überlastet ist.

Der gemeinsame Leitfaden "Understanding and Responding to Distributed Denial-of-Service Attacks" von CISA, FBI und MS-ISAC unterteilt Angriffe in genau drei Techniken: volumetrisch, protokollbezogen und anwendungsbezogen. Diese Dreiteilung ist die nützlichste, die es gibt, weil sie zugleich beschreibt, welche Ihrer vier Ressourcen angegriffen wird und wo die Abwehr sitzen muss.

Die drei Ebenen eines DDoS-Angriffs

Volumetrische Angriffe auf Layer 3 und 4

Ein volumetrischer Angriff will nichts anderes, als die Leitung vor dem Ziel füllen. Gemessen wird in Bit pro Sekunde. Das Mittel ist in der Regel ein UDP-Flood, weil UDP keinen Verbindungsaufbau kennt, den man verlangen könnte, und weil sich Absenderadressen fälschen lassen.

Das aktuell größte öffentlich dokumentierte Beispiel: Cloudflare meldet für den Zeitraum bis Ende 2025 einen automatisch abgewehrten Angriff mit 31,4 Tbit/s, der 35 Sekunden dauerte. Das ist die Kapazität von rund 31.400 Serveranschlüssen mit 1 Gbit/s, gleichzeitig, für eine gute halbe Minute. Im selben Bericht steht ein zweiter Wert, der die Größenordnung besser greifbar macht als der Spitzenwert: Im Jahr 2025 hat derselbe Betreiber 47,1 Millionen DDoS-Angriffe abgewehrt, ein Plus von 121 Prozent gegenüber dem Vorjahr, im Schnitt 5.376 Angriffe pro Stunde.

Der besser dokumentierte Fall vom Mai 2025 zeigt, wie ein solcher Angriff aussieht, wenn man ihn zerlegt: 7,3 Tbit/s in der Spitze, 37,4 Terabyte Daten in 45 Sekunden, das sind im Schnitt rund 830 Gigabyte pro Sekunde. Eine Leitung mit 1 Gbit/s hätte für dieselbe Datenmenge gut drei Tage gebraucht. 99,996 Prozent des Verkehrs waren reine UDP-Floods, verteilt über durchschnittlich 21.925 Zielports gleichzeitig, in der Spitze 34.517. Diese Verteilung über alle Ports ist typisch: Der Angreifer weiß nicht, welcher Port wichtig ist, also nimmt er alle.

Protokollangriffe: die Tabellen, nicht die Leitung

Ein Protokollangriff nutzt aus, dass der Kernel sich Zustände merken muss. Das Standardbeispiel ist der SYN-Flood: Der Angreifer sendet TCP-Pakete mit gesetztem SYN-Bit und gefälschter Absenderadresse, der Server legt für jedes einen Eintrag in seiner Warteschlange für halb geöffnete Verbindungen an, antwortet mit SYN-ACK an eine Adresse, die nie geantwortet hat, und wartet. Gemessen wird hier in Paketen pro Sekunde, nicht in Gigabit.

Die Länge dieser Warteschlange steht in net.ipv4.tcp_max_syn_backlog und liegt auf einem gewöhnlichen Server im vierstelligen Bereich. Eine Warteschlange mit 1.024 Plätzen ist bei 1,49 Millionen SYN-Paketen pro Sekunde in weniger als einer Millisekunde voll. Dafür genügen rein rechnerisch 1 Gbit/s, und wenn nur die Tabelle das Ziel ist, genügt ein Bruchteil davon.

Zur selben Familie gehört ein Verfahren, das erst 2021 beschrieben wurde: die TCP-Reflexion über zustandsbehaftete Mittelgeräte. Die Arbeit "Weaponizing Middleboxes for TCP Reflected Amplification" zeigt, dass Firewalls und Zensurinfrastruktur, die den TCP-Zustand nur halb mitverfolgen, auf ein einzelnes gefälschtes Paket mit ganzen Seiten Antwort reagieren. Damit lässt sich erstmals auch TCP zur Verstärkung missbrauchen, was bis dahin als praktisch unmöglich galt.

Anwendungsangriffe auf Layer 7

Ein Anwendungsangriff sieht wie gewöhnlicher Verkehr aus, weil er gewöhnlicher Verkehr ist, nur in falscher Menge. Gemessen wird in Anfragen pro Sekunde. Er kommt über eine vollständig aufgebaute Verbindung, überlebt also jede Prüfung, die nur den Verbindungsaufbau bewertet, und er braucht wenig Bandbreite: 10.000 HTTP-Anfragen pro Sekunde sind je nach Anfragegröße weniger als 50 Mbit/s und trotzdem genug, um eine Datenbank in die Knie zu zwingen.

Der Maßstab dafür heißt HTTP/2 Rapid Reset, offengelegt am 10. Oktober 2023 als CVE-2023-44487. Die Schwachstelle liegt in der Multiplex-Fähigkeit von HTTP/2: Der Angreifer öffnet einen Datenstrom, schickt die Anfrage und bricht den Strom sofort wieder ab. Der Server hat die Arbeit bereits begonnen, der Angreifer aber sofort wieder einen freien Platz im Fenster. Die damit erreichten Werte lagen bei 201 Millionen Anfragen pro Sekunde (Cloudflare), 398 Millionen (Google) und 155 Millionen (Amazon). Zum Vergleich: Cloudflares bis dahin höchster gemessener Layer-7-Angriff lag bei 71 Millionen Anfragen pro Sekunde.

Bei Spieleservern ist die Layer-7-Ebene der Verbindungsaufbau selbst. Nullping, QuietException und Fake-Handshake-Floods gegen Minecraft-Netzwerke brauchen fast keine Bandbreite und legen ganze Proxy-Verbünde lahm, weil jedes Paket den Proxy zu einer teuren Zustandsentscheidung zwingt. Wie diese Muster genau aussehen, steht in Minecraft-DDoS-Schutz und Nullping-Schutz.

Die drei Ebenen im Vergleich

Echte Angriffe halten sich nicht an diese Einteilung. Der in der Praxis unangenehmste Fall ist der mehrschichtige Angriff: ein volumetrischer Anteil, der die Leitung beschäftigt, dazu ein Layer-7-Anteil, der in dem Moment durchkommt, in dem die Aufmerksamkeit auf der Bandbreite liegt. Einer der weiter unten gezeigten, bei KernelHost gefilterten Angriffe bestand aus über zwölf verschiedenen Hauptmustern gleichzeitig.

Verstärkungsangriffe: wie aus einem Byte 51.000 werden

Ein Verstärkungsangriff ist ein Angriff, bei dem der Angreifer nicht selbst auf das Ziel schießt, sondern fremde, öffentlich erreichbare Dienste dazu bringt, es für ihn zu tun. Er sendet eine kleine Anfrage an einen offenen Dienst und trägt als Absender die IP-Adresse des Opfers ein. Der Dienst antwortet pflichtgemäß, nur eben an das Opfer, und die Antwort ist ein Vielfaches der Anfrage größer.

Das Verhältnis zwischen Antwortgröße und Anfragegröße heißt Bandwidth Amplification Factor, kurz BAF. Ein BAF von 50 bedeutet, dass ein Angreifer mit 1 Gbit/s eigener Anbindung 50 Gbit/s auf das Ziel lenkt. Zwei Dinge gehören zusammen, damit das funktioniert: ein Protokoll über UDP, das mehr antwortet als es gefragt wird, und die Möglichkeit, die Absenderadresse zu fälschen. Deshalb ist IP-Spoofing die Voraussetzung jedes Verstärkungsangriffs und nicht bloß eine Verschleierungstaktik.

Für den Verteidiger folgt daraus eine unangenehme Eigenschaft: Der Verkehr kommt von echten, legitimen Servern. Es sind reale DNS-Resolver, reale Zeitserver, reale Spieleserver. Eine Sperrliste nach Quelladresse sperrt also entweder halbe Länder aus oder wirkt nicht.

Die Verstärkungsfaktoren der missbrauchten Protokolle

Die folgenden Faktoren stammen aus der Warnmeldung TA14-017A von US-CERT beziehungsweise CISA, "UDP-Based Amplification Attacks", die seit 2014 laufend erweitert wird. Sie ist die Referenz, auf die sich die gesamte Branche bezieht.

Die Tabelle erklärt, warum die Liste der gesperrten Ports in jeder gut gepflegten Firewall ähnlich aussieht. Was Sie selbst tun können, ist überschaubar, aber wichtig: Prüfen Sie mit ss -lnup, ob auf Ihrem Server ein Dienst aus dieser Tabelle offen im Netz steht. Ein memcached, das nicht auf 127.0.0.1 gebunden ist, macht Ihren Server zur Waffe gegen Dritte, kostet Sie Ihre eigene Ausgangsbandbreite und bringt Ihre IP-Adresse auf Sperrlisten, aus denen sie schwer wieder herauskommt.

Warum Spielabfrageprotokolle dazugehören

Spieleserver stehen mit zwei Rollen in dieser Tabelle. Sie sind Verstärker, weil ihr Abfrageport auf ein kleines Paket mit Name, Karte, Spielerzahl und der kompletten Mod-Liste antwortet. Und sie sind Opfer, weil dieselbe Abfrage Rechenzeit kostet, oft auf genau dem Kern, der die Spielsimulation trägt.

Der Verstärkungsfaktor des Steam-Protokolls liegt mit 5,5 niedrig, der des älteren Quake-Protokolls mit 63,9 hoch. Die Wirkung hängt aber nicht am Faktor allein, sondern an der Antwortgröße im Einzelfall: Ein Server mit 200 Mods liefert eine deutlich größere Antwort als einer ohne. Bohemia Interactive dokumentiert für Arma 3 unter dem Ticket T83469 seit 2015, dass bereits 4 Mbit/s gefälschter Abfragen an den Steam-Query-Port genügten, um einen Server einzufrieren. Vier Megabit pro Sekunde sind weniger, als ein einzelner Haushaltsanschluss aufbringt.

Daraus folgt die Regel, die für jedes Spiel gilt: Den Abfrageport begrenzen, nicht sperren. Wer ihn sperrt, verschwindet aus der Serverliste und wird von neuen Spielern nicht mehr gefunden. Welcher Port das je Spiel ist und wie eng er gefahren werden darf, steht in den spielspezifischen Beiträgen weiter unten, etwa für Arma 3, CS2 und die Source-Titel oder Rust.

Der Fall memcached: 1,35 Tbit/s gegen GitHub

Am 28. Februar 2018 war GitHub von 17:21 bis 17:26 UTC nicht erreichbar und bis 17:30 UTC nur zeitweise. Der Angriff erreichte 1,35 Tbit/s bei 126,9 Millionen Paketen pro Sekunde und kam aus über 1.000 verschiedenen autonomen Systemen und zehntausenden einzelnen Endpunkten. Verstärkt wurde er über memcached, mit einem Faktor von bis zu 51.000: Ein Byte des Angreifers erzeugte bis zu 51 Kilobyte in Richtung Ziel.

Dieser Fall ist bis heute das beste Lehrstück, weil er drei Dinge auf einmal zeigt. Erstens: Verstärkung schlägt Botnetzgröße. Der Angreifer brauchte keine hunderttausend Geräte, er brauchte offene memcached-Instanzen, von denen damals weltweit mehr als 90.000 im Netz standen. Zweitens: 126,9 Millionen Pakete pro Sekunde sind rund 85-mal so viel, wie eine Leitung mit 1 Gbit/s überhaupt transportieren kann. Keine Einstellung auf dem Server ändert daran etwas. Drittens: Die Abwehr funktionierte, weil der Verkehr in ein Filternetz umgelenkt wurde und die Ausfallzeit damit bei neun Minuten endete statt bei neun Stunden.

Woher die Kapazität für einen DDoS-Angriff kommt

Botnetze aus übernommenen Geräten

Ein Botnetz ist ein Verbund fremder, mit Schadsoftware übernommener Geräte, die ein Angreifer zentral fernsteuert. Die Besitzer merken davon in der Regel nichts, weil das Gerät weiterhin tut, wofür es gekauft wurde. Angegriffen werden vor allem Geräte, die dauerhaft am Netz hängen, selten aktualisiert werden und Standardpasswörter tragen: Router, Überwachungskameras, Netzwerkrekorder, Fernsehboxen.

Der Maßstab ist Mirai, dessen Quellcode Ende September 2016 veröffentlicht wurde. Die Arbeit "Understanding the Mirai Botnet" (USENIX Security 2017) verfolgt das Netz über sieben Monate und beziffert den Höchststand auf über 600.000 infizierte Geräte. Der Angriff auf die Seite von Brian Krebs im September 2016 erreichte 620 Gbit/s und kam aus mehr als 175.000 Geräten. Beim Angriff auf den DNS-Betreiber Dyn am 21. Oktober 2016, der Twitter, Spotify und Reddit gleichzeitig unerreichbar machte, wurden rund 107.000 angreifende IP-Adressen gezählt.

Neun Jahre später ist die Größenordnung eine andere. Cloudflare führt den Rekordangriff von 31,4 Tbit/s auf ein Botnetz mit einer geschätzten Größe von einer bis vier Millionen infizierten Geräten zurück, überwiegend Android-Fernsehboxen. In der Angriffswelle vom Dezember 2025 wurden 902 hypervolumetrische Angriffe gezählt, im Schnitt 53 pro Tag, mit Spitzenwerten von 9 Milliarden Paketen pro Sekunde, 24 Tbit/s und 205 Millionen Anfragen pro Sekunde. Die Botnetzgröße ist damit binnen eines Jahrzehnts um den Faktor 5 gewachsen, die erreichte Bandbreite um den Faktor 50.

Booter- und Stresser-Dienste und was ein Angriff kostet

Zwischen dem Botnetz und dem Auftraggeber sitzt ein Dienst, der die Angriffskapazität im Abonnement verkauft. Diese Dienste treten als "Booter", "Stresser" oder "IP-Stresser" auf und behaupten in ihren Nutzungsbedingungen, sie dienten dem Belastungstest eigener Systeme. Sie prüfen dabei nie, ob das eingetragene Ziel dem Nutzer gehört, und genau das ist der Unterschied zwischen einem Werkzeug und einem Angebot.

Die Bedienung ist eine Weboberfläche mit drei Feldern: Ziel, Port, Dauer. Es gibt Bezahlvorgänge, Kundenbetreuung und Wiederverkäuferprogramme. Die Einstiegspakete liegen bei rund 10 bis 20 Euro im Monat, größere Pakete mit mehr Bandbreite und längerer Angriffsdauer bei einigen hundert Euro im Monat. Damit ist die Frage beantwortet, warum es auch kleine Projekte trifft: Ein Angriff, der einem Gameserver den Samstagabend kostet, kostet den Auslöser weniger als zwei Kinokarten und kein technisches Wissen.

Auf der anderen Seite steht ein permanenter Verfolgungsdruck. In der Aktionswoche der internationalen Operation PowerOFF im April 2026 haben Behörden aus 21 Ländern 53 Domains solcher Dienste übernommen, vier Personen verhaftet und 25 Hausdurchsuchungen durchgeführt. Dabei erlangten die Ermittler Zugriff auf die Daten von über drei Millionen Nutzerkonten, und mehr als 75.000 identifizierte Nutzer wurden angeschrieben. Im Dezember 2024 waren in derselben Operation 27 Plattformen abgeschaltet worden. Wer einen solchen Dienst bezahlt, hinterlässt also eine Zahlungsspur in einer Datenbank, die früher oder später beschlagnahmt wird.

Woran Sie einen DDoS-Angriff erkennen

Was die Nutzer melden, und was das schon aussagt

Die erste Information kommt fast immer von den Nutzern, und sie ist verwertbarer, als sie klingt. Vier Meldungen haben eine klare Bedeutung:

• "Alle sind gleichzeitig rausgeflogen." Ein gleichzeitiger Abbruch bei allen Nutzern spricht für die Leitung oder den Dienstprozess, nicht für einzelne Verbindungen. Ein Lastproblem trifft Nutzer nacheinander.
• "Der Ping springt von 20 auf 400 und zurück." Schwankende Laufzeit bei weiterhin bestehender Verbindung ist das Muster einer überfüllten Warteschlange vor dem Ziel, nicht eines überlasteten Prozesses.
• "Die Serverliste zeigt uns als offline, aber ich kann mich verbinden." Das ist der Fingerzeig auf einen Abfrage-Flood: Der Abfrageport antwortet nicht mehr, der Spielport noch.
• "Über Mobilfunk komme ich rein, über meinen Anschluss nicht." Unterschiedliches Verhalten je Zugangsnetz deutet darauf hin, dass nicht Ihr Server, sondern ein Weg dorthin gesättigt ist.

Die vier Messwerte am Server

Danach wird gemessen, und zwar in dieser Reihenfolge: Paketrate, Bandbreite, Verbindungszustände, Verwurfszähler. Die Auslastungsanzeige der CPU kommt zuletzt, weil sie bei einem Netzangriff oft unauffällig bleibt.

sar -n DEV 1 10
ip -s link show eth0
ss -s
ss -tn state syn-recv | wc -l
nstat -az TcpExtListenDrops TcpExtListenOverflows TcpExtTCPReqQFullDrop UdpRcvbufErrors UdpInErrors UdpNoPorts
cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max

sar -n DEV 1 10 liefert Pakete und Bytes pro Sekunde je Schnittstelle über zehn Sekunden. Entscheidend ist das Verhältnis: Viele Pakete bei wenig Bytes bedeutet kleine Pakete, also einen Protokollangriff. Wenige Pakete bei sehr vielen Bytes bedeutet große Pakete, also einen Verstärkungsangriff. ip -s link show zeigt in den Spalten dropped und overrun, ob der Kernel schon verwirft. ss -tn state syn-recv zählt halb geöffnete Verbindungen: Ein dreistelliger Wert ist normal, ein fünfstelliger ist ein SYN-Flood. Und nstat liefert die Zähler, die bleiben, auch wenn der Angriff vorbei ist.

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles normal läuft. Ohne Normalwert können Sie nicht sagen, ob 40.000 Pakete pro Sekunde viel sind oder einfach Samstagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit. Die ausführliche Anleitung zur Auswertung steht in DDoS-Angriff erkennen.

Die Logzeilen, die eindeutig sind

Vier Meldungen im Kernelprotokoll und im Webserverprotokoll sind praktisch beweisend. dmesg -T | tail -50 zeigt die ersten drei:

kernel: TCP: request_sock_TCP: Possible SYN flooding on port 443. Sending cookies.  Check SNMP counters.
kernel: nf_conntrack: nf_conntrack: table full, dropping packet
kernel: net_ratelimit: 2247 callbacks suppressed
nginx: [alert] 1123#1123: 768 worker_connections are not enough

Die erste Zeile bedeutet, dass die Warteschlange für halb geöffnete Verbindungen übergelaufen ist und der Kernel auf SYN-Cookies umgeschaltet hat. Steht dort stattdessen Dropping request, ist net.ipv4.tcp_syncookies auf 0 gesetzt, und der Server verwirft Anfragen einschließlich der echten. Die zweite Zeile bedeutet, dass die Verbindungsverfolgung voll ist, und ab diesem Moment verwirft der Server auch legitimen Verkehr. Die dritte Zeile ist ein Nebeneffekt: Der Kernel unterdrückt Meldungen, weil er sonst mit Protokollieren beschäftigt wäre. Die vierte Zeile verlagert das Problem in die Anwendung.

Im Zugriffsprotokoll des Webservers sind zwei Dinge aussagekräftig. Ein plötzlicher Anteil des Statuscodes 499 bedeutet, dass der Client die Verbindung schließt, bevor die Antwort fertig ist, und genau das macht ein Layer-7-Angriff, der nur Arbeit auslösen und nicht lesen will. Und ein leeres Referrer-Feld bei fast allen Anfragen unterscheidet einen Angriff von einem echten Besucheransturm, der Referrer von Suchmaschinen und sozialen Netzwerken mitbringt.

Die Gegenprobe: Angriff, Ansturm oder eigener Fehler

Was am Server selbst hilft

Auf dem Server lässt sich mehr erreichen, als oft behauptet wird, und zwar gegen alles, was klein bleibt: unsaubere Bots, einzelne Quellen, Abfrage-Floods und Anwendungsangriffe. Die Werkzeuge dafür sind nftables, die Verbindungsverfolgung, die SYN-Cookies und eine Ratenbegrenzung je Quelladresse. Alle folgenden Angaben gelten für Debian 12, Debian 13, Ubuntu 22.04 LTS und Ubuntu 24.04 LTS und sind für root geschrieben.

nftables: früh verwerfen, wenig rechnen

Der Grundsatz lautet: Ein Paket, das verworfen wird, soll so früh und so billig wie möglich verworfen werden. Jede Regel, die davor läuft, kostet Rechenzeit mal Paketrate. Das folgende Regelwerk für /etc/nftables.conf lässt einen Webserver und einen Spieldienst durch und verwirft den Rest, mit einer Ratenbegrenzung für neue TCP-Verbindungen je Quelladresse:

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set newconn {
        type ipv4_addr
        size 131072
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority filter; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid counter drop

        ip saddr @adminips tcp dport 22 accept

        tcp dport { 80, 443 } ct state new add @newconn { ip saddr limit rate over 30/second burst 60 packets } counter drop
        tcp dport { 80, 443 } accept

        udp dport 25565 accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward { type filter hook forward priority filter; policy drop; }
    chain output  { type filter hook output  priority filter; policy accept; }
}

Tragen Sie unter adminips Ihre eigene feste Adresse ein, bevor Sie laden, sonst sperren Sie sich aus SSH aus. Geprüft und aktiviert wird so:

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset
nft list set inet filter newconn

Drei Punkte entscheiden über die Wirkung. ct state established,related accept steht bewusst als zweite Regel, damit bestehende Verbindungen nicht durch den gesamten Regelsatz laufen. ct state invalid counter drop entfernt fehlerhafte Flag-Kombinationen und verspätete Fragmente, ohne dass Sie sie einzeln beschreiben müssen. Und counter vor jedem drop ist der Grund, warum Sie hinterher wissen, welche Regel gegriffen hat: Bleiben die Zähler bei null, wird die Regel nicht erreicht, und das ist eine völlig andere Diagnose als ein wirkungsloser Regelsatz.

SYN-Cookies und die Grenze des Backlog

SYN-Cookies sind ein Verfahren, bei dem der Server sich eine halb geöffnete Verbindung nicht merkt, sondern die nötigen Angaben verschlüsselt in die eigene Antwortnummer schreibt. Kommt das dritte Paket des Verbindungsaufbaus zurück, rechnet er daraus den Zustand wieder aus. Damit läuft die Warteschlange nicht mehr über, denn es gibt für diese Verbindungen keine Warteschlange.

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216

Diese Werte gehören in eine Datei unter /etc/sysctl.d/ und werden mit sysctl --system übernommen, sonst sind sie nach dem nächsten Neustart weg. Auf Debian und Ubuntu steht tcp_syncookies ab Werk auf 1, was richtig ist. Der Wert 1 bedeutet nicht "immer Cookies", sondern "Cookies, sobald die Warteschlange überläuft".

Der Preis dafür ist real und wird selten genannt. In einem Cookie ist kein Platz für die TCP-Optionen der Gegenseite. Linux rettet Fenstervergrößerung und selektive Bestätigung nur dann, wenn net.ipv4.tcp_timestamps auf 1 steht, weil die Angaben dann im Zeitstempel mitreisen. Ohne Zeitstempel fallen sie weg, und die Verbindung läuft für den Rest ihrer Lebensdauer langsamer. Außerdem stehen für die maximale Paketgröße nur drei Bit zur Verfügung, also acht grobe Stufen statt des exakten Werts. SYN-Cookies sind ein Notbetrieb, der Verbindungen rettet, keine Einstellung für den Normalfall.

conntrack: die Tabelle, die als erste voll ist

Die Verbindungsverfolgung des Kernels legt für jeden Paketfluss einen Eintrag an, auch für UDP, obwohl UDP keine Verbindungen kennt. Genau diese Tabelle ist bei einem verteilten Angriff die erste Ressource, die zu Ende geht, und sie geht sehr schnell zu Ende: Bei 1,49 Millionen Paketen pro Sekunde mit jeweils neuer Absenderadresse ist eine Tabelle mit 262.144 Plätzen in weniger als einer Fünftelsekunde gefüllt.

net.netfilter.nf_conntrack_max = 524288
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20

Ein Eintrag belegt rund 300 Byte, 524.288 Einträge also etwa 150 Megabyte Kernelspeicher. Die Größe der Hashtabelle wird nicht per sysctl, sondern als Modulparameter gesetzt, üblicherweise auf ein Viertel der Obergrenze, in /etc/modprobe.d/nf_conntrack.conf:

options nf_conntrack hashsize=131072

Für einen reinen Spiel- oder Voiceserver ist die elegantere Lösung, den Spielverkehr gar nicht verfolgen zu lassen. Das spart die Tabelle vollständig:

nft add table ip raw
nft add chain ip raw prerouting '{ type filter hook prerouting priority raw; }'
nft add rule ip raw prerouting udp dport 25565 notrack

Achtung: notrack und zustandsbehaftete Regeln schließen einander aus. Wer einen Port von der Verfolgung ausnimmt, darf für diesen Port keine Regel mit ct state mehr verwenden, sonst greift die Freigabe nicht mehr und der Dienst ist zu.

Ratenbegrenzung je Quelladresse

Eine Ratenbegrenzung je Quelladresse ist die wirksamste Einzelmaßnahme auf dem Server, weil sie genau das trifft, was ein Angreifer tut, und genau das durchlässt, was ein Nutzer tut. Der Unterschied ist groß: Ein echter Serverbrowser fragt einige Male pro Minute ab, ein Angreifer hunderte Male pro Sekunde. Mit nftables arbeitet man dafür mit dynamischen Mengen, wie im Regelwerk oben, mit klassischem iptables mit hashlimit:

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27015 -m length --length 0:27 -j DROP

Alle Zahlen in solchen Regeln sind Startwerte, keine Wahrheiten. Messen Sie erst eine Woche im Normalbetrieb, sonst werfen Sie eigene Nutzer heraus, und das im schlechtesten Moment. Beachten Sie außerdem, dass reine iptables-Regeln nach einem Neustart weg sind (apt-get install -y iptables-persistent, dann netfilter-persistent save) und dass sie unter UFW nach /etc/ufw/before.rules gehören, weil sie sonst beim nächsten ufw reload verschwinden. Der vollständige Regelsatz für den laufenden Betrieb steht in Server vor DDoS-Angriffen schützen.

Wo jede Filterung am Server aufhört

Jetzt der Teil, den keine Konfigurationsdatei löst. Alle bisherigen Maßnahmen laufen auf Ihrem Server, also am Ende der Leitung. Eine Firewall-Regel entscheidet über ein Paket, das bereits über das Kabel gelaufen ist. Sie können es verwerfen, aber nicht ungesendet machen. Ist die Leitung davor voll, kommen die Pakete Ihrer Nutzer schon vorher nicht mehr an, und zwar unabhängig davon, wie gut Ihr Regelsatz ist.

Diese Tabelle beantwortet die Frage, ob Eigenschutz reicht, für jeden Einzelfall. Der Angriff auf GitHub mit 126,9 Millionen Paketen pro Sekunde passt in der Paketrate knapp auf einen Anschluss mit 100 Gbit/s, bei 1,35 Tbit/s Volumen bräuchte man davon aber vierzehn gleichzeitig. Der Rekordangriff mit 31,4 Tbit/s entspricht 314 vollständig gesättigten Anschlüssen mit 100 Gbit/s. Ein Gameserver hängt typischerweise an 1 Gbit/s oder an zweimal 1 Gbit/s: Die Grenze des Eigenschutzes liegt damit bei rund 1,5 bis 3 Millionen Paketen pro Sekunde, und praktisch deutlich darunter, weil der Kernel vorher aufgibt.

Es gibt noch eine zweite, unangenehmere Grenze. Sobald die Leitung gesättigt ist, erreicht Sie unter Umständen nicht einmal mehr die SSH-Sitzung, mit der Sie messen wollten. Wer dann keinen netzunabhängigen Zugang hat, etwa eine VNC-Konsole im Kundenbereich, kann nicht einmal mehr nachsehen, was passiert.

Was nur vor dem Server hilft: Filterung im Netz und Scrubbing

Wirksam filtern kann nur, wer mehr Kapazität hat als der Angriff. Das setzt eine Stelle voraus, an der viele Leitungen zusammenlaufen, also ein Netz, nicht eine Maschine. Dort gibt es zwei Verfahren, die sich ergänzen.

Echtzeitfilterung im Netz. Der gesamte Verkehr läuft dauerhaft durch eine Filterstufe, die jedes Paket bewertet, bevor es zum Server weitergegeben wird. Der Vorteil ist, dass es keine Umschaltung gibt: Der Schutz muss einen Angriff nicht erst erkennen, um zu wirken. Genau das entscheidet bei Spielen, denn eine Umschaltzeit von zwei Minuten ist eine verlorene Runde, und eine Umschaltzeit von zwei Minuten bei einem Angriff, der 35 Sekunden dauert, ist überhaupt keine Abwehr.

Scrubbing. Erkennt das Netz einen großen volumetrischen Angriff, wird der betroffene Verkehr auf Filterzentren umgeleitet, dort von den schädlichen Anteilen befreit und anschließend in Richtung Ziel ausgeliefert. Der Sinn dieser Umleitung ist Nähe: Der Angriffsverkehr endet an der Stelle, an der er eintritt, statt erst am Rechenzentrum. Die Filterregeln werden dafür im Netz verteilt, technisch beschrieben in RFC 8955 als Flow Specification.

Die strukturelle Gegenmaßnahme gegen gefälschte Absenderadressen ist übrigens seit dem Jahr 2000 bekannt und steht in RFC 2827, dem BCP 38: Wer einen Kunden anschließt, verwirft an dieser Grenze alle Pakete, deren Absenderadresse nicht zu diesem Kunden gehört. RFC 3704 erweitert das auf mehrfach angeschlossene Netze. Würden alle Netzbetreiber das umsetzen, wäre die gesamte Klasse der Verstärkungsangriffe erledigt. Sie ist es nicht, weil es genügt, dass einige es nicht tun.

Und es gibt eine dritte Methode, die man kennen muss, weil sie oft als Schutz verkauft wird: Nullrouting, technisch Remote Triggered Black Hole Filtering nach RFC 5635. Dabei wird die angegriffene IP-Adresse im Netz als unerreichbar angekündigt, der gesamte Verkehr zu ihr wird verworfen, der Angriffsverkehr ebenso wie der Ihrer Nutzer. Das schützt das Netz des Anbieters, für Sie ist das Ergebnis identisch mit einem erfolgreichen Angriff, und meist noch für Stunden danach. Fragen Sie im Zweifelsfall nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

Was KernelHost dagegen stellt

Der Dauerschutz, der in jedem Serverpaket enthalten ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und dauerhaft aktiv, ohne dass Sie etwas einschalten, bestellen oder konfigurieren müssen:

• Stufe 1: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk. Volumetrische Angriffe werden nah an ihrer Quelle bereinigt, bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster erkannt und verworfen, Paket für Paket.

Zwei Eigenschaften sind entscheidend. Der Schutz läuft permanent und ist ab der Bereitstellung des Servers aktiv, es gibt also keine Minuten am Anfang eines Angriffs, in denen der Dienst weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Welche Spiele und Protokolle eigene Filterprofile haben, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen, jeden Abend zur selben Zeit und mit wechselnden Mustern. Dafür gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. Der Unterschied liegt nicht in mehr Kapazität, sondern in der Kontrolle:

• Dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server im eigenen Netz umgestellt wird. Auf Ihrer Seite ist kein Umbau nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll im Kundenbereich: Sie stellen getrennt ein, was auf dem Spielport erlaubt ist und was auf dem Abfrageport, und können damit genau die Asymmetrie aus dem Abschnitt zu den Abfrageprotokollen ausnutzen.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt auf ein Wartungsfenster zu warten.
• Schutzprofil passend zum jeweiligen Dienst, ebenso für modifizierte und selbst geschriebene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die Advanced DDoS Protection richtet sich an KernelHost-Kunden und setzt einen Server bei KernelHost voraus. Wenn Ihr Projekt derzeit woanders läuft und dort regelmäßig unter Angriff steht, ist der Umzug hierher der Weg, nicht eine Fernbetreuung Ihrer bisherigen Adresse.

Die beiden Stufen im Vergleich

Sechs real gefilterte Angriffe aus dem Betrieb

Die folgenden sechs Angriffe trafen Server von KernelHost-Kunden und wurden vollständig in Echtzeit gefiltert, jeweils ohne Ausfall. Die Abbildungen stammen aus dem Live-Monitoring der Abwehr.

TeamSpeak-3-Voiceserver, Port 9987 UDP. Komplexer Angriff mit mehreren gleichzeitigen Mustern, über 473,4 Gbit/s und über 41,5 Millionen Pakete pro Sekunde. Das ist etwa die 28-fache Paketrate eines Anschlusses mit 1 Gbit/s.

ARK-Gameserver, Port 7777 UDP. Einfacher UDP-Flood ohne komplexe Struktur, dafür über 112,2 Gbit/s und über 8,7 Millionen Pakete pro Sekunde. Wie ein ARK-Cluster daneben selbst abgesichert wird, steht in ARK-Server vor DDoS schützen.

All-Port-Angriff, Ports 0-65535 TCP und UDP. Über zwölf verschiedene Hauptangriffsmuster gegen sämtliche Ports gleichzeitig, insgesamt über 21,3 Gbit/s und über 3,9 Millionen Pakete pro Sekunde. Dieser Fall zeigt die Streuung über alle Ports, die auch der Cloudflare-Fall vom Mai 2025 mit durchschnittlich 21.925 Zielports aufweist.

Minecraft und OpenVPN, Ports 25565 TCP und 1194 UDP. Kombinierter Angriff mit über sechzehn verschiedenen Hauptangriffsmustern, über 4 Millionen Paketen pro Sekunde und über 8,6 Gbit/s. Beide Dienste blieben durchgehend erreichbar, obwohl sie unterschiedliche Protokolle sprechen.

UDP-Flood auf einen einzelnen Dienstport, acht Minuten. Der härteste der sechs Fälle: 745,5 Gbit/s und 73,1 Millionen Pakete pro Sekunde, etwa die 49-fache Paketrate eines Anschlusses mit 1 Gbit/s. 99,93 Prozent des Verkehrs gingen auf einen einzigen Zielport, die Quellen waren vollständig verteilt. Nach acht Minuten war der Angriff vorbei, der Dienst blieb durchgehend erreichbar.

Dauerangriff über drei Stunden und 31 Minuten. 501,2 Gbit/s und 43,9 Millionen Pakete pro Sekunde, nicht als einzelne Spitze, sondern als Folge von Wellen ohne Pause. Sieben Angriffsmuster gleichzeitig, darunter SSDP-, MS-SQL-RS-, L2TP- und RIPv1-Verstärkung. Die Zielports streuten über den gesamten Bereich 1024 bis 65535, ein Portwechsel hätte also nichts gebracht. Mehr zu beiden Fällen in Wie lange dauert ein DDoS-Angriff.

Was im Angriffsfall zu tun ist, in dieser Reihenfolge

Die Reihenfolge ist wichtiger als die einzelnen Schritte, weil die häufigsten Fehler in den ersten fünf Minuten passieren.

1. Messen, nicht schrauben. Sichern Sie zuerst die Werte aus sar -n DEV 1 10, ip -s link show, ss -s und dmesg -T in eine Datei. Nach dem Angriff sind sie weg, und ohne sie kann Ihnen niemand helfen.
2. Nicht neu starten. Ein Neustart löscht alle Zähler, alle Verbindungszustände und jeden Beweis, und die Last ist nach wenigen Sekunden wieder da.
3. Feststellen, welche Ebene es ist. Bytes geteilt durch Pakete ergibt die mittlere Paketgröße. Unter 100 Byte deutet auf einen Protokollangriff, über 1.000 Byte auf einen Verstärkungsangriff, normale Größen bei hoher CPU-Last auf Layer 7.
4. Verwaltungsports zumachen. Panel, Datenbank, RCON und alles, was nicht öffentlich sein muss, gehört auf Ihre eigene Adresse begrenzt. Das reduziert die Angriffsfläche sofort und ohne Risiko für die Nutzer.
5. Ratenbegrenzung setzen, eng auf den Abfrageport, weit auf den Nutzport. Sperren Sie den Abfrageport nicht, sonst verschwinden Sie aus jeder Serverliste.
6. Die eigene Adresse nicht vorschnell wechseln. Ein Adresswechsel wirkt nur, solange die neue Adresse nicht wieder öffentlich steht, und ein vergessener alter DNS-Eintrag macht den Wechsel wirkungslos.
7. Den Anbieter mit Zahlen einbeziehen. Öffnen Sie ein Ticket mit Zeitpunkt, Zielport, Paketrate, Bandbreite und der mittleren Paketgröße. Diese fünf Angaben entscheiden darüber, wie schnell die Filterregeln für Ihre Adresse nachjustiert werden.
8. Danach dokumentieren. Halten Sie fest, wann es begann, wie lange es dauerte und welches Muster es war. Wiederkehrende Angriffe zur selben Uhrzeit sind das Kriterium dafür, ob ein Projekt eine dedizierte Schutz-IP braucht.

Der ausführliche Ablauf für einen schweren, länger laufenden Angriff steht in Schwerer DDoS-Angriff: was tun.

Rechtslage: ein DDoS-Angriff ist eine Straftat

In Österreich fällt ein DDoS-Angriff unter § 126b StGB, "Störung der Funktionsfähigkeit eines Computersystems". Der Grundtatbestand sieht Freiheitsstrafe bis zu sechs Monaten oder eine Geldstrafe bis zu 360 Tagessätzen vor. Dauert die Störung längere Zeit, sind es bis zu zwei Jahre. Werden viele Systeme mit einem Programm angegriffen, das erkennbar dafür geschaffen wurde, sind es bis zu drei Jahre. Und bei einem Schaden über 300.000 Euro, bei einem Angriff auf kritische Infrastruktur oder als Mitglied einer kriminellen Vereinigung liegt der Rahmen bei sechs Monaten bis fünf Jahren. Ergänzend stellt § 126c StGB bereits das Herstellen, Verbreiten und Zugänglichmachen der dafür bestimmten Programme unter Strafe.

In Deutschland greift § 303b StGB, "Computersabotage": bis zu drei Jahre Freiheitsstrafe oder Geldstrafe, bis zu fünf Jahre, wenn die Datenverarbeitung einem Betrieb, einem Unternehmen oder einer Behörde dient, und in besonders schweren Fällen sechs Monate bis zehn Jahre, etwa bei gewerbsmäßigem Handeln oder bei Beeinträchtigung kritischer Infrastruktur. Der Versuch ist strafbar, und für Vorbereitungshandlungen verweist § 303b Abs. 5 StGB auf § 202c StGB.

Booter- und Stresser-Dienste sind deshalb keine Grauzone, sondern der bezahlte Teil einer Straftat. Drei Punkte sind dabei regelmäßig missverstanden. Erstens macht der Hinweis "nur für Belastungstests eigener Systeme" nichts legal, weil die Dienste nicht prüfen, wem das eingetragene Ziel gehört. Zweitens ist auch der Auftraggeber strafbar, nicht nur der Betreiber: Europol hat nach der Aktionswoche im April 2026 ausdrücklich mehr als 75.000 identifizierte Nutzer angeschrieben, um genau das klarzustellen. Drittens ist ein Belastungstest auf den eigenen Server über einen solchen Dienst ebenfalls keine Lösung, weil der Angriffsverkehr durch das Netz des Anbieters und damit über die Leitungen anderer Kunden läuft, was jeder Hostingvertrag untersagt. Wer die Belastbarkeit seines Dienstes wirklich messen will, tut das angekündigt und in Absprache mit dem Anbieter. Dieser Abschnitt gibt den Gesetzesstand wieder und ist keine Rechtsberatung.

Der passende Leitfaden für Ihren Dienst

Dieser Beitrag erklärt das Prinzip. Welcher Port gehört offen, welche Konfigurationsdirektive begrenzt welche Abfrage, und wo liegt die Grenze beim jeweiligen Spiel: Das steht in den Beiträgen zum einzelnen Dienst, jeweils mit Fakten-Tabelle der Ports.

• Grundlagen und Ablauf: DDoS-Angriff erkennen, Server vor DDoS-Angriffen schützen, Schwerer DDoS-Angriff: was tun, Game-DDoS-Schutz mit Echtzeit-Filterung
• Minecraft und Voice: Minecraft und Nullping, Minecraft Bedrock, TeamSpeak 3, Hytale
• Rollenspiel auf GTA-Basis: FiveM, RedM, RAGE MP und alt:V, SA-MP und open.mp, MTA:SA
• Überleben und Aufbau: Rust, ARK, DayZ, Palworld, Conan Exiles, Project Zomboid, Terraria, Unturned
• Taktik und Schießen: CS2 und Source, Arma 3, Call of Duty, Team Fortress 2, Left 4 Dead 2, Garry's Mod, Mordhau, Lineage 2

Kurz zusammengefasst

• Ein DDoS-Angriff belegt eine von vier endlichen Ressourcen: Bandbreite, Paketrate, eine Zustandstabelle des Kernels oder die Rechenzeit der Anwendung. Er nutzt keine Sicherheitslücke, deshalb schützt Aktualisieren allein nicht.
• RFC 4732 definiert einen DoS-Angriff über die Wirkung, nicht über die Zahl der Quellen. Verteilt heißt er, wenn die Quellen zahlreich sind: im Cloudflare-Fall vom Mai 2025 waren es 122.145 Adressen aus 161 Ländern.
• CISA, FBI und MS-ISAC unterscheiden drei Techniken: volumetrisch in Gbit/s, protokollbezogen in Paketen pro Sekunde, anwendungsbezogen in Anfragen pro Sekunde. Jede braucht eine andere Abwehr.
• Verstärkungsangriffe missbrauchen offene UDP-Dienste. Die Faktoren reichen von 5,5 beim Steam-Protokoll über 30,8 bei SSDP und 556,9 bei NTP bis 51.000 bei memcached, nachzulesen in US-CERT TA14-017A.
• Die Kapazität kommt aus Botnetzen übernommener Geräte, von 600.000 bei Mirai im Jahr 2016 bis zu geschätzt einer bis vier Millionen hinter dem Rekordangriff mit 31,4 Tbit/s, und wird ab rund 10 Euro im Monat weiterverkauft.
• Auf dem Server wirken nftables, SYN-Cookies, angepasste conntrack-Grenzen und Ratenbegrenzung je Quelladresse. Sie enden bei rund 1,5 Millionen Paketen pro Sekunde, weil ein Anschluss mit 1 Gbit/s nicht mehr transportiert.
• Oberhalb dieser Grenze entscheidet ausschließlich die Filterung im Netz vor dem Server. Nullrouting ist keine Abwehr, sondern das Ergebnis, das der Angreifer wollte.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten und ab der Bereitstellung aktiv, ohne Nullrouting: 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk plus Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Die Advanced DDoS Protection ergänzt ihn ab 50,00 € im Monat um eine dedizierte Schutz-IP und selbst verwaltbare Regeln je Port.
• Ein DDoS-Angriff ist in Österreich nach § 126b StGB und in Deutschland nach § 303b StGB strafbar, für Auftraggeber ebenso wie für Betreiber der Dienste.

Läuft Ihr Projekt bereits bei KernelHost, ist die Filterung aktiv, ohne dass Sie etwas tun müssen. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket mit den fünf Angaben aus Schritt 7, damit die Filterregeln für Ihre IP-Adresse nachjustiert werden. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfallchat unter +43 650 8209883.