DDoS-Schutz für Game-Server: Ein Runbook für die Ära der 10-Minuten-Angriffe

Deine Matchmaking-Warteschlange stockt um 21:14 Uhr. Um 21:19 Uhr ist sie wieder da. Du prüfst den Graphen und findest einen 620-Mbps-Spike, sechs Minuten breit, schon verschwunden, bevor die Alert-Meldung dein Telefon erreicht hat. Niemand in deinem Zwei-Personen-Team hat es live gesehen, und deine Spieler haben es unter „Lag“ abgeheftet.

Diese Angriffsform ist inzwischen der Standard. Der Cloudflare DDoS Threat Report Q3 2026 zählte 18,2 Millionen auf Netzwerkebene abgewehrte Angriffe im Quartal – grob 8.226 pro Stunde, also einer alle 0,44 Sekunden. Davon endeten 96 % in unter 10 Minuten und 98 % blieben unter 1 Gbps. Hyper-volumetrische Angriffe über 1 Tbps fielen von 805 in Q2 auf 251 in Q3, ein Rückgang um ~69 %, den der Report auf die Zerschlagung der IoT-Botnetze Aisuru, KimWolf, JackSkid und Mossad durch Strafverfolgungsbehörden zurückführt.

Weniger Giganten. Mehr Schwärme. Und der Schwarm ist das Bedrohungsmodell, auf das ein kleines Game-Backend am schlechtesten vorbereitet ist, weil er gleichzeitig zu klein ist, um die Mitigation-Stufe deines Providers auszulösen, und groß genug, um eine einzelne Game-Instanz zu sättigen.

Das hier ist ein Runbook für genau dieses Bandbreiten-Band.

Was Q3 2026 wirklich verändert hat

Drei Verschiebungen sind relevant, wenn du Game-Server betreibst. Die erste ist die Dauer. Ein Anstieg von 208 % gegenüber dem Vorjahr bei kurzzeitigen Angriffen mit geringer Bandbreite ist die operative Signatur von DDoS-for-Hire-„Booter“-Diensten: billig, wiederholbar und in Salven abgefeuert. Erwarte 40 Angriffe an einem Abend, nicht einen.

Die zweite ist der Vektor-Wechsel. CLDAP-Reflection – missbrauchte öffentliche Domain-Controller über UDP 389 – brach im Quartalsvergleich um 99,5 % auf nur noch 0,05 % der Angriffe ein, nachdem es im H1 stark aktiv war. Die Angreifer hörten nicht auf; sie rotierten. DNS-Amplification sprang um 215 % auf 3,43 % der Angriffe auf Netzwerkebene, und allgemeine UDP-Floods stiegen von 14,06 % auf 31,31 %.

Die dritte ist, dass sich die Ziele ausgeweitet haben. Medien blieben die am stärksten angegriffene Branche, verloren aber etwa drei Viertel ihres Q2-Anteils. Internet-Infrastruktur stieg von außerhalb der Top 10 auf Platz 6, und Consumer Services sowie Adult Entertainment kamen auf Platz 8 und 9. Games liegen genau in diesem Cluster aus nutzerorientierten, latenzempfindlichen Zielen.

Die Lehre für Verteidiger: Baue dein Playbook nicht um den Vektor des letzten Quartals. Baue es um die vier Kategorien – UDP-Flood, DNS-Amplification, Reflection-Missbrauch und SYN-Exhaustion – und geh davon aus, dass sich die Gewichte weiter verschieben.

Was in einem Game-Backend zuerst bricht

Nicht alles fällt gleichzeitig aus, und die Reihenfolge zu kennen, bewahrt dich davor, am falschen Feuer zu löschen.

• Der Game-Port. Ein UDP-Flood auf deinen autoritativen Server-Port verbraucht die NIC-Warteschlangen vor der CPU. Dein Server erscheint für den Orchestrator-Healthcheck als „up“, weil der Prozess lebt, während Pakete im Kernel verworfen werden.
• Session- und Login-Endpunkte. HTTP-Floods treffen die Authentifizierung. Spieler, die mitten im Burst die Verbindung verlieren, kommen nicht mehr rein, und die bereits im Spiel befindlichen brechen ab, weil die Reconnect-Schleife scheitert.
• Leaderboard-Reads. Das ist der am stärksten verstärkte Lesepfad in den meisten Game-Backends: Eine Client-Anfrage fächert in einen Datenbank-Range-Scan auf. 5.000 Requests pro Sekunde sind trivial zu senden und teuer zu bedienen.
• Telemetrie-Ingestion. Oft unauthentifiziert oder nur locker rate-limitiert, oft der billigste Endpunkt, den es zu attackieren gilt.
• Die Conntrack-Tabelle. Wenn sie voll läuft, reißt sie jeden Dienst auf dem Host mit, einschließlich deines SSH-Zugangs – so wird aus einem Vier-Minuten-Angriff ein Vier-Stunden-Ausfall.

Reflection-Angriffe verdienen eine besondere Anmerkung: Der Traffic kommt von legitimen DNS-Resolvern und anderen Drittanbieter-Servern, daher schlägt IP-Reputation-Blocking per Design fehl. Du wirst von unschuldiger Infrastruktur getroffen.

Erkennung: Die Signale, die vor den Graphen auslösen

Deine Dashboards hinken hinterher. Kernel-Zähler nicht. Der wichtigste Frühindikator ist das Verhältnis von Paketen pro Sekunde zu Bits pro Sekunde. Ein legitimer Game-Traffic von 300 Mbps entspricht bei typischen Payload-Größen grob 25.000–40.000 Paketen pro Sekunde. Ein 300-Mbps-UDP-Flood mit 64-Byte-Paketen liegt eher bei 500.000 pps. Gleiche Bandbreite, 15-mal so viele Pakete – und es killt den Host, während dein Bandbreiten-Graph moderat aussieht.

Führe das auf dem verdächtigen Host aus:

# socket and memory pressure summary
ss -s

# per-protocol counters and the ones that predict a lockup
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|TcpExtListenDrops|TcpExtTCPReqQFullDrop'

# current conntrack table occupancy vs max
conntrack -C && sysctl net.netfilter.nf_conntrack_max

# what is actually arriving on the wire
tcpdump -nn -i eth0 'udp and not port 7777' -c 200

Lies sie so:

• UdpInDatagrams steigt, während deine Game-Loop niedrigere Spielerzahlen meldet = Flood.
• UdpNoPorts schnellt hoch = ein Scanner fegt deinen Port-Bereich ab, oft ein Vorbote.
• TcpExtTCPReqQFullDrop ungleich null = SYN-Queue-Überlauf, das heißt, du verlierst bereits legitime Handshakes.
• conntrack -C über 70 % von nf_conntrack_max = du bist Minuten von einem kompletten Host-Ausfall entfernt, nicht nur vom Game-Server-Ausfall.

Wenn du eher die Sicht pro Endpunkt als die Kernel-Sicht willst: Das UEFN-Server-Crash-Diagnoseprotokoll führt durch die Unterscheidung zwischen einem Stillstand auf Netzwerkebene und einem auf Engine-Ebene – das ist die erste Entscheidung in jedem Triage.

Für die In-Process-Verteidigung gegen den Müll, der durchkommt, ist ein Pro-Quelle-Token-Bucket auf der Socket-Ebene billig und effektiv. Dieses C#-Beispiel filtert eingehende Pakete, bevor sie deinen Simulations-Tick erreichen:

using System.Diagnostics;
using System.Net;

public sealed class PacketGate
{
    private readonly Dictionary<IPAddress, Bucket> _buckets = new();
    private readonly int _ratePerSecond;
    private readonly int _burst;

    // A legit client at 30 Hz sends ~30 packets/s. 120/s allows
    // headroom for retransmits without letting a flood through.
    public PacketGate(int ratePerSecond = 120, int burst = 240)
    {
        _ratePerSecond = ratePerSecond;
        _burst = burst;
    }

    public bool Allow(IPAddress source)
    {
        long now = Stopwatch.GetTimestamp();

        if (!_buckets.TryGetValue(source, out var bucket))
        {
            bucket = new Bucket { Tokens = _burst, LastRefill = now };
            _buckets[source] = bucket;
        }

        double elapsed = (now - bucket.LastRefill) / (double)Stopwatch.Frequency;
        bucket.Tokens = Math.Min(_burst, bucket.Tokens + elapsed * _ratePerSecond);
        bucket.LastRefill = now;

        if (bucket.Tokens < 1.0) return false;
        bucket.Tokens -= 1.0;
        return true;
    }

    private sealed class Bucket
    {
        public double Tokens;
        public long LastRefill;
    }
}

Sei dir darüber im Klaren, was das tut und was nicht. Es filtert Pro-Quelle-Müll, der in deine verfügbare Bandbreite passt. Es tut nichts, sobald die Leitung voll ist – dann werden die Pakete ohnehin upstream von deinem Prozess verworfen, egal was dein Code entscheidet.

Gegenmaßnahmen-Runbook: Die ersten zehn Minuten

Da 96 % der Angriffe enden, bevor ein Mensch reagieren kann, besteht die Aufgabe des Runbooks nicht darin, den Angriff zu beheben. Sondern darin, Beweise zu sichern und den Blast Radius zu verkleinern, während der Angriff ausbrennt.

T+0 bis T+2 Minuten – bestätigen, nicht skalieren. Widersteh dem Reflex, Instanzen hinzuzufügen. In einen Flood hinein zu skalieren multipliziert deine Rechnung und deine Angriffsfläche. Bestätige den Vektor mit den obigen Zählern, notiere pps und Bandbreite und prüfe, ob sich die Conntrack-Tabelle füllt. Wenn ja, wechsle sofort in den T+0-Notfall-Hostschutz.

T+2 bis T+5 Minuten – nicht essenzielle Last abwerfen. Deaktiviere alles, was nicht Gameplay ist: Telemetrie-Batching, Leaderboard-Refresh, Storefront-Polling, Social-Feeds. Wenn dein Backend Remote-Konfiguration unterstützt, ist das ein einzelner Flag-Umschalter statt eines Deploys.

T+5 bis T+10 Minuten – Rate-Limits auf Host-Ebene anwenden. Kernel-Filterung ist um Größenordnungen billiger als Anwendungsfilterung:

table inet gameguard {
    set udp_flood {
        type ipv4_addr
        flags dynamic, timeout
        timeout 60s
    }

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

        iif lo accept
        ct state established,related accept
        tcp dport { 22, 443 } accept
        tcp dport 7777-7800 accept
        udp dport 7777-7800 accept

        # drop fragmented UDP - your game protocol should never need it
        ip frag-off & 0x1fff != 0 udp drop

        # per-source UDP cap well above a real client's send rate
        udp dport 7777-7800 update @udp_flood \
            { ip saddr limit rate over 200/second burst 400 packets } drop
    }
}

Lade mit nft -f gameguard.nft. Verifiziere mit nft list ruleset und nft list set inet gameguard udp_flood. Wenn du das falsch machst und dich aussperrst, hast du einen Netzwerkvorfall in einen Physical-Access-Vorfall verwandelt – teste es zuerst auf Staging und halte die Regeln unter Versionskontrolle.

T+10 Minuten und danach – an deinen Upstream eskalieren. Du brauchst Scrubbing- oder Blackhole-Fähigkeiten am Netzwerkrand, nicht auf dem Host. Die meisten Managed-Game-Hosting-Anbieter bieten das an; wenn deiner es nicht tut, ist das ein Procurement-Problem, das du vor dem nächsten Angriff lösen solltest. Frag gezielt nach ihrer UDP-Mitigation-Schwelle unter 1 Gbps, denn die meisten veröffentlichten SLAs sind für Terabit-Angriffe geschrieben, die du nie sehen wirst.

Durchgehend: Führe ein Zeitstempel-Log. Angriffsbeginn, Vektor, Peak-pps, Peak-Gbps, was du wann geändert hast. Das Postmortem ist mehr wert als die Mitigation.

Vektor-Playbook: Die Antwort an die Angriffsform anpassen

UDP-Flood (31,31 % der Angriffe). Zufällige oder gezielte Ports, die den Host zwingen, nach einem Listener zu suchen und ICMP-unreachable zu erzeugen. Der Artikel zur Network-Layer-Fallback-Architektur zeigt, wie du einen degradierten, aber spielbaren Modus verfügbar hältst, wenn der primäre Transport gehämmert wird. Antwort: nftables-Rate-Limit pro Quelle, alle UDP-Ports schließen, die nicht dein Game-Port sind, und ICMP-unreachable-Erzeugung auf dem Host deaktivieren.

DNS-Amplification (3,43 %, +215 %). Queries mit gefälschter Quelle an offene Resolver, große Antworten, die auf dich zielen. Antwort: Du kannst nicht nach Quelle blocken, weil die Quellen legitime Resolver sind. Du kannst nur absorbieren oder nach Antwortgröße und -rate filtern. Prüfe, ob du nicht selbst einen offenen Resolver betreibst, mit dig +short txt chaos version.bind @your.ip – wenn er antwortet, schließe ihn noch heute.

CLDAP (auf 0,05 % eingebrochen). Aktuell ruhig, historisch enorm. Die Erinnerung: CLDAP-Amplification läuft über UDP 389. Wenn du also kein LDAP brauchst, halte es sowohl in der Host-Firewall als auch in der Cloud-Firewall gefiltert. Angreifer kehren zu ungeschützten Ports zurück, wenn sie wieder rotieren.

SYN-Flood. Selten Volumen, immer Exhaustion. Aktiviere SYN-Cookies (sysctl -w net.ipv4.tcp_syncookies=1), erhöhe net.core.somaxconn und stelle sicher, dass die Conntrack-Tabelle für deinen schlechtesten realistischen Fall dimensioniert ist, nicht für den Standard.

Prävention: Architektur, die einen Vier-Minuten-Burst übersteht

Zuerst die Kapazitätsrechnung, denn sie tötet viel Wunschdenken. Ein 64-Spieler-100-Tick-Server bewegt grob 15–20 KB/s pro Spieler – nennen wir es 1,2 MB/s, also etwa 10 Mbps pro Instanz. Ein 400-Mbps-Angriff ist das 40-fache des legitimen Traffics dieser Instanz. Da 98 % der Angriffe unter 1 Gbps liegen, ist fast jeder Angriff in der aktuellen Verteilung groß genug, um eine einzelne Game-Instanz zu plätten, aber viel zu klein, um die Auto-Mitigation eines Tier-1-Scrubbing-Providers zu interessieren.

Das schränkt deine Architektur auf drei Arten ein.

Trenne die Account-Ebene von der Game-Ebene. Wenn dein Login-Endpunkt, Leaderboard-Reads und Spieler-Saves auf demselben Host wie deine Game-Server laufen, reißt ein Flood auf dem Game-Port auch die Accounts mit runter, und Spieler erreichen nicht einmal einen „Wir sind gleich zurück“-Screen. Wenn du diese accountgebundenen Dienste auf horizOn betreibst – Authentifizierung, Cloud Save und Leaderboards werden dort verwaltet –, bedeutet ein Burst auf deinen Game-Port nur degradiertes Gameplay, ohne jeden Spieler aus seinem Profil auszusperren.

Mach Feature-Shedding zu einer Konfigurationsänderung, nicht zu einem Deploy. Wenn der Flood trifft, hast du Sekunden. Remote-Konfiguration erlaubt es dir, teure Lesepfade sofort abzuschalten. Wenn deine einzige Option ein Build-Push ist, wirst du sie nicht nutzen.

Baue den Healthcheck so, dass er Netzwerkausfälle sieht. Ein Prozess-Check meldet „healthy“, während der Kernel 90 % der Pakete verwirft. Prüfe die tatsächliche Gameplay-Erreichbarkeit – einen synthetischen Client, der einen echten Handshake durchführt und innerhalb von 250 ms eine Antwort erwartet – und lass das dein Failover steuern.

Best Practices: Fünf Änderungen, die sich diese Woche lohnen

1. Alarmiere auf Paketrate, nicht nur auf Bandbreite. Setze einen Schwellenwert bei dem 2,5-fachen deines 95. Perzentils der pps. Reines Bandbreiten-Alerting übersieht kurze Bursts komplett; pps-Anomalieerkennung fängt einen 300-Mbps-Flood auf einem Host mit 1-Gbps-Link, den kein Bandbreiten-Graph markieren würde.
2. Dimensioniere die Conntrack-Tabelle bewusst. Setze net.netfilter.nf_conntrack_max basierend auf den Spitzen gleichzeitiger Sessions, nicht auf dem Distro-Standard, und alarmiere bei 70 % Auslastung. Diese eine Änderung verhindert die häufigste Eskalation von „Angriff wurde zum Ausfall“.
3. Schreibe das nftables-Regelwerk vorab und teste es vierteljährlich. Lege es in dein Repo neben die Deploy-Konfiguration. Eine ungetestete Firewall-Regel, die während eines Vorfalls angewendet wird, ist ein zweiter Vorfall.
4. Veröffentliche einen Degraded-Mode-Vertrag für deine Spieler. Wenn Leaderboards und Chat während der Mitigation zehn Minuten dunkel sind, sag das in den Patch Notes und auf der Statusseite. Stille wirkt wie ein totes Spiel. Wenn du ein Vorbild dafür willst: Die Resilienz-Muster im Backend-Architektur-Breakdown nach Kompromittierung lassen sich direkt auf Verfügbarkeitsvorfälle übertragen.
5. Logge jeden Angriff als strukturiertes Event. Zeitstempel, Vektor, Peak-pps, Peak-Gbps, Dauer, angewendete Mitigation. Nach fünf Angriffen siehst du dein eigenes Muster – die meisten Indie-Backends werden am selben Wochentag, zur selben Stunde, vom selben Booter getroffen.

Das Fazit

Das Bedrohungsprofil 2026 ist feindlich gegenüber Teams, die für Terabit-Angriffe planen und den 400-Mbps-Sechs-Minuten-Burst ignorieren. Die Giganten sind um 69 % zurückgegangen; die Schwärme sind um 208 % gestiegen. Deine Mitigation muss automatisiert, billig und im Kernel sein, denn kein Mensch wird innerhalb eines Angriffs handeln, der endet, bevor die Alert-Meldung gelesen ist.

Starte mit den Zählern, nicht mit den Dashboards. Füge das Pro-Quelle-Rate-Limit hinzu, dimensioniere die Conntrack-Tabelle, trenne deine Account-Ebene von deiner Game-Ebene und übe das Zehn-Minuten-Runbook, bis es langweilig ist.

Wenn ein Teil dieser Trennung unglamouröse Arbeit ist, die du lieber nicht selbst machst – Spieler-Authentifizierung, revisionsbewusstes Cloud Save, Leaderboards, Remote-Konfiguration, die du mitten im Vorfall umschalten kannst –, dann ist das der Teil, den horizOn übernimmt, damit deine Bereitschaftszeit stattdessen in die Game-Server fließt. Teste es kostenlos oder lies die Doku vor deinem nächsten Launch-Fenster.

---

Quelle: Cloudflare DDoS Threat Report 2026 Q3: Mehr Schwärme, weniger Giganten