Call-of-Duty-Server vor DDoS-Angriffen schützen

Einen Call-of-Duty-Server vor DDoS-Angriffen zu schützen ist bei den klassischen Titeln eine erfreulich konkrete Aufgabe: Es geht um genau einen UDP-Port, um eine Handvoll Dvars in der server.cfg und um einen Verstärkungsvektor, den die Engine seit 2003 mitbringt. Ein Server, der abends mitten in der Runde alle Spieler gleichzeitig verliert, hat dagegen selten ein Hardwareproblem. Meistens läuft ein Angriff, und er läuft genau dann, wenn der Server voll ist.

Dieser Beitrag zeigt zuerst, für welche Titel er überhaupt gilt, danach, was Sie ohne Zusatzkosten selbst absichern können, anschließend, wo diese Maßnahmen technisch aufhören, und zum Schluss, was dann im Netz vor dem Server passieren muss. Die Befehle sind für Debian 12, Debian 13, Ubuntu 22.04 LTS und Ubuntu 24.04 LTS geschrieben und setzen root voraus, als normaler Benutzer stellen Sie sudo voran.

Wenn der Angriff gerade läuft: Ändern Sie jetzt nichts an der server.cfg und starten Sie den Server nicht neu. Sichern Sie zuerst die Messwerte (siehe Abschnitt "Protokollieren"), nach dem Angriff sind sie weg.

Für welche Call-of-Duty-Titel Sie einen Server vor DDoS schützen können

Einen Call-of-Duty-Server vor DDoS schützen können Sie nur bei den Titeln, die eigene dedizierte Server erlauben. Das sind die Originalfassungen von Call of Duty (2003), Call of Duty United Offensive, Call of Duty 2, Call of Duty 4 Modern Warfare und Call of Duty World at War, dazu die Community-Plattformen Plutonium (World at War, Black Ops, Black Ops II, Modern Warfare 3), IW4x (Modern Warfare 2) und CoD4X (Call of Duty 4). Alle diese Titel bringen dasselbe Muster mit: eine server.cfg, einen offenen UDP-Port und einen Eintrag in einer öffentlichen Serverliste.

Für die modernen Teile gilt dieser Beitrag ausdrücklich nicht. Warzone, Modern Warfare (2019), Black Ops Cold War, Vanguard, Modern Warfare II, Modern Warfare III und Black Ops 6 kennen keine mietbaren dedizierten Server: Die Partien laufen auf der Matchmaking-Infrastruktur von Activision, es gibt keine server.cfg, keinen Serverbrowser und keinen Port, den Sie freigeben oder absichern könnten. Die Portlisten, die Activision für diese Titel veröffentlicht (unter anderem TCP 3074 und 27014 bis 27050 sowie UDP 3074, 3478 und 27000 bis 27031), beschreiben Client- und Plattformports, keine Serverports. Wer in Warzone Verbindungsabbrüche hat, hat ein Problem auf der eigenen Leitung oder eines bei Activision, aber keines, das ein gemieteter Server lösen würde.

Warum ausgerechnet Call-of-Duty-Server angegriffen werden

Call-of-Duty-Server vereinen vier Eigenschaften, die sie zu einem bequemen Ziel machen. Erstens veröffentlicht jeder gelistete Server seine Adresse selbst: Der Eintrag in der Serverliste enthält IP-Adresse und Port im Klartext, sonst könnte ihn niemand betreten. Zweitens läuft der gesamte Verkehr über UDP, und UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, Absenderadressen lassen sich fälschen. Drittens beantwortet die Engine Statusabfragen von jedem, ohne dass jemand das Spiel starten muss. Viertens liegt die Fernsteuerung RCON auf demselben Port wie das Spiel selbst.

Dazu kommt der soziale Teil: gebannte Spieler, Konkurrenz zwischen Clans, Streit in einer Community, die sich seit Jahren kennt. Ein Angriff kostet den Auslöser weder Können noch nennenswertes Geld, sogenannte Booter und Stresser werden als Abonnement für wenige Euro im Monat verkauft, und Verstärkungsangriffe über Spieleserver gehören dort zum Standardangebot. Was ein DDoS-Angriff im Detail ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es tatsächlich geht

Ein klassischer Call-of-Duty-Server belegt genau einen UDP-Port, und zwar 28960. Auf diesem einen Port laufen drei Dinge gleichzeitig: der Spielverkehr, die Statusabfragen der Serverliste und die Fernsteuerung RCON. Einen eigenen Query-Port und einen eigenen RCON-Port gibt es nicht. Die Startzeile eines dedizierten Servers sieht bei allen Titeln gleich aus, nur der Name der ausführbaren Datei unterscheidet sich:

+set dedicated 2 +set net_ip 0.0.0.0 +set net_port 28960 +set sv_maxclients 32 +exec server.cfg +map_rotate

Die Masterserver-Ports gehören nicht in Ihre Firewall-Freigaben. 20810 und 20800 sind Zielports auf der Gegenseite, keine Lauschports auf Ihrer Maschine: Ihr Server spricht die Liste von sich aus an. Viele Portfreigabe-Anleitungen empfehlen trotzdem, sie eingehend zu öffnen. Das vergrößert die Angriffsfläche ohne jeden Gegenwert.

Übliche Größenordnungen bei Call of Duty

Die zweite Tabelle ist die wichtigere, wenn Sie einschätzen wollen, ob Sie es noch selbst in den Griff bekommen. Sie stellt die normale Last eines vollen Servers den Zahlen gegenüber, um die es bei einem Angriff geht.

Warum Spiel, Query und RCON auf demselben Port liegen

Das ist die für Call of Duty entscheidende Besonderheit. Die id-Tech-3-Engine, auf der alle klassischen Call-of-Duty-Titel aufbauen, kennt keine getrennten Ports für Spiel, Abfrage und Fernsteuerung. Alles läuft über sogenannte verbindungslose Pakete auf dem einen UDP-Port. Ein verbindungsloses Paket ist ein UDP-Paket, das mit vier Bytes 0xFF beginnt und danach den Befehlsnamen im Klartext trägt: getstatus, getinfo, getchallenge, connect oder rcon.

Die praktische Folge ist unbequem: Sie können RCON nicht per Firewall vom Spiel trennen, ohne das Spiel mitzusperren. Eine Regel auf Port 28960 trifft immer alles. Wer Query-Floods und RCON-Angriffe gezielt aussortieren will, muss in den Paketinhalt schauen und nicht nur auf die Portnummer. Genau deshalb kommen portbasierte Firewallregeln bei Call of Duty früher an ihre Grenze als bei Spielen mit getrenntem Query-Port.

Was ist die getstatus-Reflection bei Call of Duty?

Die getstatus-Reflection ist ein Verstärkungsangriff, bei dem ein Angreifer kleine Statusabfragen mit gefälschter Absenderadresse an viele Spieleserver schickt, damit deren deutlich größere Antworten beim eigentlichen Opfer landen. Die Spieleserver sind dabei nicht das Ziel, sondern der Verstärker. Dieser Vektor ist für die id-Tech-3-Engine seit über einem Jahrzehnt dokumentiert und betrifft Call of Duty genauso wie Quake 3 und dessen übrige Ableger.

Doppelt trifft es Sie aus zwei Richtungen. Als Angegriffener bekommen Sie eine Flut von getstatus-Anfragen, die Rechenzeit und ausgehende Bandbreite verbrauchen, und Ihre Spieler bemerken es als Lag-Spikes. Als unfreiwilliger Verstärker verschicken Sie Antworten an ein fremdes Opfer, und die Abuse-Beschwerde landet bei Ihnen. Beides passiert auf demselben Port, mit denselben Paketen, und beides sieht in der Auslastungsgrafik zunächst harmlos aus.

Wie ein getstatus-Paket aussieht

Die Anfrage besteht aus vier Bytes 0xFF und dem Wort getstatus, zusammen 13 Byte Nutzlast. Mit IP- und UDP-Kopf sind das 41 Byte auf der Leitung. Genau darauf zielt die Längenprüfung in den Firewallregeln, die in Call-of-Duty-Foren seit Jahren herumgereicht werden:

iptables -A INPUT -p udp -m length --length 41:45 -m recent --set --name getstatus_cod
iptables -A INPUT -p udp -m string --algo bm --string "getstatus" -m recent --update --seconds 1 --hitcount 20 --name getstatus_cod -j DROP

Die Antwort ist ungleich größer. Ein statusResponse enthält die gesamte Serverkonfiguration als Zeichenkette plus eine Zeile je verbundenem Spieler, bei vollem Server also mehrere Kilobyte. Die CISA führt das Quake-Netzwerkprotokoll in ihrer Übersicht der UDP-Verstärkungsangriffe (TA14-017A) mit einem Verstärkungsfaktor von 63,9 und benennt als missbrauchten Befehl ausdrücklich den Austausch von Serverinformationen. Aus 1 Mbit/s gefälschter Anfragen werden damit rund 64 Mbit/s beim Opfer. Zum Vergleich: DNS liegt in derselben Übersicht bei 28 bis 54, NTP bei 556,9.

Die eingebaute Bremse: sv_queryIgnoreTime und sv_queryIgnoreMegs

Call of Duty 4 hat seit der Serverversion 1.7 eine eingebaute Query-Bremse. Sie merkt sich jede Adresse, die eine Statusabfrage geschickt hat, und ignoriert weitere Abfragen derselben Adresse für eine einstellbare Zeit. Vier Dvars steuern das, mit diesen Voreinstellungen:

sv_queryIgnoreMegs        1
sv_queryIgnoreTime        2000
sv_queryBounceIgnoreTime  12000
sv_queryIgnoreDebug       0

sv_queryIgnoreMegs bestimmt, wie viel Arbeitsspeicher die Ignorierliste belegen darf. 1 Megabyte fasst rund 65.000 Adressen, jedes weitere Megabyte etwa 87.000 zusätzliche. Der Wert 0 schaltet die Bremse vollständig ab, und genau das ist auf vielen Servern der Fall, weil die Konfiguration aus einer alten Vorlage stammt. sv_queryIgnoreTime ist die Sperrzeit in Millisekunden. sv_queryBounceIgnoreTime greift, wenn eine Antwort mit "ICMP Port Unreachable" zurückkommt, also genau dann, wenn Ihr Server gerade gegen ein fremdes Opfer als Verstärker missbraucht wird. sv_queryIgnoreDebug 1 schreibt die Treffer ins Protokoll, damit Sie überhaupt sehen, ob etwas passiert.

Wer CoD4X einsetzt, hat zusätzlich feste Obergrenzen im Servercode: höchstens 20 getstatus-Antworten je 20 Sekunden, höchstens 100 getinfo-Antworten je 100 Sekunden und höchstens eine RCON-Fehlermeldung je 100 Millisekunden. Der Kommentar im Quelltext benennt die Absicht klar: Der Server darf sich ruhig überfluten lassen, aber er soll dabei keine ausgehende Bandbreite verschwenden. Das ist die richtige Prioritätensetzung, ersetzt aber keine Filterung vor dem Server.

Warum RCON bei Call of Duty historisch ein Problem ist

RCON ist die Fernsteuerung des Servers, und bei Call of Duty ist sie ein unverschlüsseltes UDP-Paket auf dem Spielport. Ein RCON-Befehl sieht auf der Leitung so aus: vier Bytes 0xFF, dann das Wort rcon, dann das Passwort im Klartext, dann der eigentliche Befehl. Es gibt keine Verschlüsselung, keine Sitzung, kein Benutzerkonto und keinen zweiten Faktor. Daraus folgen drei Probleme, die alle real sind:

• Mitlesen. Wer den Verkehr an irgendeiner Stelle des Weges sieht, liest Ihr RCON-Passwort im Klartext mit. Das gilt für jedes Netz zwischen Ihnen und dem Server und für jedes Werkzeug, dem Sie das Passwort geben.
• Raten. Es gibt keine Anmeldung, die sich sperren ließe, und keine Kontosperre nach zehn Fehlversuchen. Ein Angreifer probiert Passwörter in beliebiger Geschwindigkeit durch. Der Originalserver bremst das gar nicht, CoD4X bremst lediglich die Antwort auf eine Fehlermeldung je 100 Millisekunden und protokolliert den Versuch als "Bad rcon".
• Reflection. Auch eine RCON-Fehlermeldung ist eine Antwort auf ein gefälschtes Paket. Wer Ihren Server mit gefälschten RCON-Paketen beschießt, benutzt ihn als kleinen Verstärker, und Ihr Server schreibt sich nebenbei das Protokoll voll.

Die praktische Konsequenz: Setzen Sie rcon_password nur, wenn Sie RCON wirklich brauchen. Wenn ja, dann lang und zufällig. CoD4X verlangt mindestens acht Zeichen, das ist eine Untergrenze und keine Empfehlung. Administrieren Sie im Alltag über SSH und die Serverkonsole statt über RCON aus dem offenen Netz. Und wenn Sie ein Verwaltungswerkzeug wie IW4MAdmin betreiben, das seinerseits über RCON spricht, gehört dessen Weboberfläche auf Port 1624 nicht ins offene Netz.

Was Sie selbst tun können, bevor Sie Geld ausgeben

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter Call-of-Duty-Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht.

1. Bestandsaufnahme: was lauscht überhaupt?

Bevor Sie eine einzige Regel schreiben, sehen Sie nach, was Ihr Server nach außen anbietet. Nicht raten, nachsehen:

ss -lntup

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:28960 und [::]:28960 bedeuten "aus dem ganzen Internet erreichbar", 127.0.0.1:3306 bedeutet "nur lokal" und braucht keine Firewall-Regel. Neben dem Spiel tauchen dort oft IW4MAdmin, ein Webserver für den Fast Download, eine Datenbank für Statistiken und eine vergessene zweite Spielinstanz auf. Die Sicht des Angreifers liefert ein Portscan von außen:

nmap -Pn -sU -p 28960-28970,4976,27016 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Nur offen lassen, was das Spiel wirklich braucht

Für einen einzelnen Call-of-Duty-Server reicht eine einzige Freigabe nach außen, alles andere wird eingeschränkt oder gar nicht erst veröffentlicht. Mit UFW sieht das so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 28960/udp comment 'Call of Duty'
ufw allow from 203.0.113.10 to any port 1624 proto tcp comment 'IW4MAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Bei Plutonium T6 tritt 4976/udp an die Stelle von 28960/udp, bei Plutonium IW5 ist es 27016/udp. Betreiben Sie mehrere Instanzen, geben Sie ausschließlich den tatsächlich genutzten Bereich frei, also zum Beispiel 28960:28962/udp und nicht pauschal 28960 bis 28970. Jeder Port, auf dem nichts lauscht, ist zwar kein Einfallstor, kostet den Kernel im Angriffsfall aber trotzdem Arbeit. Die vollständige Anleitung samt Rettungsweg finden Sie unter UFW-Firewall einrichten, ohne sich selbst auszusperren.

3. Die Query-Bremse in der server.cfg einschalten

Diese vier Zeilen gehören in jede server.cfg eines Call-of-Duty-4-Servers und kosten nichts außer ein paar Megabyte Arbeitsspeicher:

set sv_queryIgnoreMegs "4"
set sv_queryIgnoreTime "2000"
set sv_queryBounceIgnoreTime "12000"
set sv_queryIgnoreDebug "0"

4 Megabyte fassen rund 326.000 Adressen, das reicht auch für einen ernsthaften Flood. Erhöhen Sie sv_queryIgnoreTime nur vorsichtig über die voreingestellten 2000 Millisekunden hinaus: Die Serverliste und jeder Serverbrowser fragen Ihren Server über denselben Mechanismus ab, und wer die Sperrzeit zu hoch setzt, verschwindet aus der Liste. Setzen Sie sv_queryIgnoreDebug vorübergehend auf 1, wenn Sie wissen wollen, ob die Bremse überhaupt greift, und danach wieder auf 0, damit Ihnen das Protokoll nicht die Platte füllt.

4. Query-Floods in der Firewall aussortieren

Die Bremse in der Engine wirkt erst, nachdem das Paket den Spielprozess erreicht hat. Eine Firewallregel entscheidet früher und kostet weniger. Diese beiden Zeilen begrenzen getstatus je Quelladresse:

iptables -A INPUT -p udp --dport 28960 -m length --length 41:45 -m recent --set --name cod_query --rsource
iptables -A INPUT -p udp --dport 28960 -m string --algo bm --string "getstatus" -m recent --update --seconds 2 --hitcount 4 --name cod_query --rsource -j DROP

Die erste Zeile merkt sich jede Quelladresse, die ein Paket in der typischen Länge einer Statusabfrage schickt. Die zweite verwirft jede weitere getstatus-Anfrage, sobald dieselbe Adresse innerhalb von zwei Sekunden mehr als vier davon geschickt hat. Vier Anfragen je zwei Sekunden reichen jedem Serverbrowser aus. In Foren kursieren auch Varianten mit 20 Anfragen je Sekunde, die deutlich großzügiger sind und eher gegen grobe Bots wirken als gegen eine saubere Reflection-Welle.

Reine iptables-Regeln sind nach einem Neustart weg, unter Debian und Ubuntu sichert man sie so:

apt-get install -y iptables-persistent
netfilter-persistent save

Unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden. Prüfen Sie anschließend mit iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht.

5. RCON abschalten oder eng führen

Der sicherste RCON-Zugang ist der, den es nicht gibt. Ein leeres rcon_password lehnt jedes RCON-Paket ab:

set rcon_password ""

Beachten Sie dabei eine Feinheit: Der Server antwortet auch dann noch, nämlich mit einer Fehlermeldung, und bleibt damit ein kleiner Verstärker. Wer das ausschließen will und RCON ohnehin nur von einer festen Adresse braucht, verwirft die Pakete vorher:

iptables -A INPUT -p udp --dport 28960 ! -s 203.0.113.10 -m string --algo bm --string "rcon " -j DROP

Diese Regel hat einen Nebeneffekt, den Sie kennen sollten: Die Zeichenkette rcon kann theoretisch auch in einem Chatpaket eines verbundenen Spielers auftauchen, das Paket würde dann ebenfalls verworfen. In der Praxis ist das verschmerzbar. Wer den Nebeneffekt nicht will, lässt die Regel weg und arbeitet nur mit einem leeren oder sehr langen Passwort.

6. Beitritts-Flood und Slot-Erschöpfung abwehren

Ein Beitritts-Flood zielt nicht auf die Leitung, sondern auf die Spiellogik: Der Angreifer schickt in schneller Folge getchallenge- und connect-Pakete, bis alle Slots mit halbfertigen Verbindungen belegt sind. Echte Spieler bekommen dann "Server is full", obwohl im Spiel niemand steht. Dagegen wirken diese Einstellungen:

set sv_maxclients "32"
set sv_reconnectLimit "3"
set sv_floodProtect "1"
set sv_connectTimeout "30"
set sv_timeout "120"

sv_reconnectLimit begrenzt, wie oft sich derselbe Spieler hintereinander neu verbinden darf. sv_floodProtect begrenzt, wie viele Client-Befehle der Server je Spieler verarbeitet, und verhindert damit, dass ein einzelner Client den Server mit Kommandos ausbremst. sv_connectTimeout und sv_timeout bestimmen, wie lange eine halbfertige beziehungsweise eine stumme Verbindung einen Slot blockiert: Wer hier großzügige Werte aus einer alten Vorlage stehen lässt, macht dem Angreifer die Slot-Erschöpfung leicht.

Auf CoD4X kommt sv_authorizemode dazu. Der Wert 1 lässt nur Spieler mit gültiger Kopie herein, 0 nur Spieler ohne, und -1 beide. Wer 1 setzt, sperrt einen großen Teil der Wegwerf-Clients aus, verliert aber auch echte Spieler ohne Originalkopie. Das härteste Mittel ist ein Serverpasswort über g_password, das gegen alles wirkt, was den regulären Beitrittsweg nutzt. Und eines muss klar sein: Ein Passwort schützt Ihre Spiellogik, nicht Ihre Leitung. Ein Angreifer, der Ihren Server flutet, will gar nicht beitreten. Seine Pakete werden abgelehnt, sind aber trotzdem angekommen, und genau das ist der Punkt.

7. Der Eintrag in der Serverliste und Ihre eigene Adresse

Hier lohnt sich Ehrlichkeit statt Wunschdenken: Ihre IP-Adresse lässt sich nicht geheim halten. Jeder Spieler, der einmal verbunden war, kennt sie, und der Listeneintrag veröffentlicht sie ohnehin, mitsamt Port. Sie können den Eintrag abschalten, indem Sie in der server.cfg keinen Masterserver setzen (die Dvars heißen sv_master1, sv_master2 und so weiter). Das kostet allerdings sämtliche Sichtbarkeit für neue Spieler und hilft nur gegen den bequemsten aller Angreifer.

Ein Hinweis zur Lage der Listen: Die ursprünglichen Masterserver von Activision (codmaster.activision.com auf 20510, cod2master.activision.com auf 20710, cod4master.activision.com auf 20810) beantworten für die alten Titel nichts mehr. Wer heute gelistet sein will, nutzt die Community-Listen: CoD4X betreibt eine eigene und verlangt dafür ein Token in sv_authtoken, Plutonium bringt eine eigene Serverliste mit. An der Sache selbst ändert das nichts, die Adresse steht dort genauso im Klartext.

Zwei Gewohnheiten wirken trotzdem. Veröffentlichen Sie die rohe IP-Adresse nirgends selbst, also nicht im Discord-Kanal und nicht auf der Clanseite. Und verbinden Sie Ihre Spieler über einen Hostnamen, damit Sie im Ernstfall die Adresse wechseln können, ohne dass alle Verweise brechen. Der Klassiker ist dabei ein vergessener A-Eintrag auf die alte Adresse: Er macht jeden Wechsel wirkungslos.

8. Weboberflächen, Datenbank und Fast Download aus dem offenen Netz nehmen

Neben dem Spiel läuft auf den meisten Call-of-Duty-Servern noch mehr: IW4MAdmin mit seiner Weboberfläche auf Port 1624, ein Webserver für den Fast Download der Karten, manchmal eine Datenbank für Statistiken. Jeder dieser Dienste ist eine eigene Angriffsfläche, und keiner davon gehört unbegrenzt ins offene Netz.

Beschränken Sie 1624 auf Ihre eigene Adresse oder erreichen Sie die Oberfläche über eine SSH-Weiterleitung und öffnen danach lokal http://127.0.0.1:1624:

ssh -N -L 1624:127.0.0.1:1624 root@IHRE.SERVER.IP.ADRESSE

Die Datenbank binden Sie auf 127.0.0.1, sie hat im offenen Netz in keinem Fall etwas verloren. Und legen Sie den Fast Download auf einen eigenen Webserver statt in den Spielprozess: Ein Webserver unter Last nimmt dem Spiel sonst genau die Rechenzeit weg, die es für die Simulation braucht.

9. Protokollieren, damit Sie im Ernstfall Daten haben

Der wichtigste Schritt ist der, den fast niemand vorher macht: eine Vergleichsbasis anlegen, solange alles normal läuft. Ohne Normalwert können Sie nach einem Vorfall nicht sagen, ob 40.000 Pakete pro Sekunde viel waren oder einfach Freitagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit. Während eines Vorfalls genügen vier Befehle:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 udp port 28960 -c 200 -q

Für Call of Duty gibt es einen fünften, der die entscheidende Frage beantwortet. Dieser Mitschnitt zeigt ausschließlich die verbindungslosen Pakete, also genau getstatus, getinfo, getchallenge, connect und rcon:

tcpdump -ni eth0 'udp port 28960 and udp[8:4] = 0xffffffff' -c 200 -A

Steht dort hundertfach getstatus aus immer neuen Adressen, haben Sie einen Query-Flood. Steht dort rcon, versucht jemand Ihr Passwort zu raten. Steht dort nur getchallenge und connect, ist es ein Beitritts-Flood. Bei tcpdump gilt immer: mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen.

Wo diese Maßnahmen aufhören

Jetzt der Teil, den keine Konfigurationsdatei lösen kann. 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.

Rechnen Sie einmal mit. Ein voller 32-Slot-Server erzeugt ausgehend rund 6,4 Mbit/s, das ist weniger als ein Prozent einer Gigabit-Leitung. Dieselbe Leitung ist voll, sobald jemand 125 Megabyte pro Sekunde schickt, und genau darauf sind die Angriffe ausgelegt, die man für zehn Euro im Monat bestellen kann. Ob Ihre iptables-Regel dahinter gut ist, spielt dann keine Rolle mehr, denn die Pakete Ihrer Spieler kommen schon vorher nicht durch.

Die zweite Größe ist die Paketrate, und sie schlägt bei Call of Duty regelmäßig früher zu als die Bandbreite. Bei kleinen Paketen von 64 Byte passen in eine Leitung mit 1 Gbit/s rund 1,49 Millionen Pakete pro Sekunde. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, bevor er anfängt zu verwerfen. Eine getstatus-Anfrage ist mit 41 Byte noch kleiner als das: Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, legt Ihren Server trotzdem lahm, weil die gesamte Rechenzeit in das Verwerfen geht. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg".

Bei Call of Duty kommt eine Besonderheit dazu, die die Rechnung verschärft. Weil Spiel, Query und RCON auf demselben Port liegen, können Sie 28960 nicht notfalls zumachen: Das wäre dasselbe, als würden Sie den Server abschalten. Und weil die Engine auf jede Statusabfrage mit einem Vielfachen der Anfragegröße antwortet, verbraucht ein Angreifer für dieselbe Wirkung weniger eigene Bandbreite als bei anderen Spielen.

Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde auf einen Voice-Server und ein UDP-Flood mit über 112,2 Gbit/s auf einen Gameserver gefiltert. Dafür gibt es keine lokale Einstellung. Volumetrische Angriffe müssen im Netz vor dem Server enden.

Was KernelHost dagegen stellt

Der Dauerschutz, der auf jedem Server inklusive 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 muss nicht erst auf einen Angriff reagieren, es gibt also keine Minuten am Anfang, in denen der Server weg ist. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Wer die IP-Adresse aus dem Netz nimmt, erreicht für Sie dasselbe Ergebnis wie der Angreifer. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Clans und Communities werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Dafür gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid und ohne Mindestlaufzeit. 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 ein, was auf 28960 UDP erlaubt ist, ohne dafür ein Ticket zu schreiben, und bei mehreren Instanzen je Port getrennt.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren.
• Schutzprofil passend zum jeweiligen Spiel, auch für modifizierte und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports. Das ist für Plutonium und CoD4X der relevante Punkt, weil deren Ports von den Voreinstellungen abweichen können.

Die Advanced DDoS Protection richtet sich an Server, die bei KernelHost stehen. Wenn Ihr Call-of-Duty-Server derzeit woanders läuft und dort regelmäßig aus dem Netz genommen wird, ist der Umzug zu KernelHost der Weg, der etwas ändert.

Die beiden Stufen im Vergleich

Für die meisten Call-of-Duty-Server reicht der inkludierte Dauerschutz zusammen mit einer sauberen server.cfg. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Häufige Fehler und Lösungen

"Ich habe die IP-Adresse gewechselt und war zwei Stunden später wieder offline": Der Angreifer hat die neue Adresse aus derselben Quelle wie die alte, meist dem Listeneintrag, einem Discord-Bot mit Statusanzeige oder einem alten DNS-Eintrag. Ein Adresswechsel ist Zeitgewinn, keine Lösung.

"Mein Anbieter schickt mir eine Abuse-Meldung, obwohl ich doch das Opfer bin": Dann ist Ihr Server nicht das Ziel, sondern der Verstärker. Jemand schickt gefälschte getstatus-Anfragen, und Ihr Server antwortet brav an ein fremdes Opfer. Prüfen Sie zuerst, ob sv_queryIgnoreMegs auf 0 steht, und setzen Sie die vier Query-Dvars sowie die Firewallregel aus Abschnitt 4.

"Der Server steht in der Liste als voll, ist aber leer": Das ist ein Beitritts-Flood, und er trifft die Spiellogik, nicht die Leitung. Dagegen wirken sv_reconnectLimit, kürzere Werte für sv_connectTimeout und sv_timeout und im Zweifel ein Serverpasswort.

"Der Server verschwindet während des Angriffs aus der Serverliste": Das ist die Folge, nicht die Ursache. Die Serverliste prüft über dieselben Statusabfragen, ob Ihr Server lebt. Kommen die Antworten nicht durch oder wurden sie von Ihrer eigenen Bremse verworfen, gilt der Server als offline. Prüfen Sie, ob sv_queryIgnoreTime zu hoch steht, bevor Sie die Firewall verdächtigen.

"Meine iptables-Regeln greifen nicht": Drei Ursachen sind häufig. Die Regeln stehen hinter den UFW-Ketten und werden nie erreicht, sie waren nach dem letzten Neustart weg (dann helfen netfilter-persistent save oder ein Eintrag in /etc/ufw/before.rules), oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist. Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen.

"Der Server läuft, aber alle Spieler haben Lag-Spikes": Sehen Sie zuerst auf die Paketrate der Schnittstelle, nicht auf die CPU-Last. Bleibt sar -n DEV 1 10 unauffällig und ruckelt es trotzdem, liegt es meist an einem Mod, einer überzogenen sv_maxRate oder schlicht an zu vielen Bots in der Runde.

"Mein bisheriger Anbieter hat meine IP-Adresse gesperrt": Das ist Nullrouting. Der Anbieter schützt damit sein eigenes Netz, für Sie ist das Ergebnis identisch mit einem erfolgreichen Angriff, meist noch für Stunden danach. Fragen Sie im Zweifel nach, ob gefiltert oder nullgeroutet wird. Die Antwort entscheidet mehr über Ihre Verfügbarkeit als jede Hardwareangabe.

"Im tcpdump sehe ich nichts Auffälliges": Wenn der Verkehr schon im Netz davor gefiltert wird, kommt auf dem Server erwartungsgemäß nichts an. Das ist der Normalfall bei funktionierender Filterung. Umgekehrt gilt: Ist die Leitung gesättigt, erreicht Sie unter Umständen nicht einmal mehr die SSH-Sitzung, mit der Sie messen wollten. Nutzen Sie dann die VNC-Konsole im Kundenbereich, die unabhängig vom Netzwerk des Gastsystems funktioniert.

Kurz zusammengefasst

• Ein klassischer Call-of-Duty-Server braucht genau einen offenen Port: 28960 UDP. Bei Plutonium T6 ist es 4976 UDP, bei Plutonium IW5 27016 UDP.
• Spiel, Statusabfrage und RCON liegen bei Call of Duty auf demselben Port. Sie können RCON nicht per Portregel vom Spiel trennen, dafür brauchen Sie eine Regel, die in den Paketinhalt schaut.
• Die getstatus-Reflection ist der spieltypische Verstärkungsvektor: 41 Byte Anfrage, laut CISA-Warnung TA14-017A Faktor 63,9 beim Quake-Netzwerkprotokoll, also rund 2.600 Byte Antwort.
• Schalten Sie die Query-Bremse ein: sv_queryIgnoreMegs 4, sv_queryIgnoreTime 2000, sv_queryBounceIgnoreTime 12000. Auf vielen Servern steht sie auf 0 und ist damit aus.
• Setzen Sie rcon_password nur, wenn Sie RCON wirklich brauchen: Das Passwort läuft unverschlüsselt über UDP und lässt sich ohne Kontosperre beliebig oft raten.
• Die Masterserver-Ports 20810 und 20800 sind ausgehende Zielports und gehören nicht in Ihre eingehenden Freigaben.
• Ab etwa 1 Gbit/s oder einigen hunderttausend Paketen pro Sekunde entscheidet ausschließlich das Netz vor dem Server, nicht mehr Ihre Konfiguration.

Läuft Ihr Server 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, 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.