Team Fortress 2: TF2-Server vor DDoS-Angriffen schützen

Ein Team-Fortress-2-Community-Server, der abends mitten in der Runde alle Spieler gleichzeitig verliert und danach für Minuten aus dem Serverbrowser verschwindet, hat selten ein Hardwareproblem. In den meisten Fällen läuft ein Angriff auf 27015/UDP. Dieser Beitrag zeigt, wie Sie einen TF2-Server vor DDoS-Angriffen schützen: zuerst das, was Sie in den nächsten zehn Minuten ohne Zusatzkosten selbst tun können, danach die Stelle, an der diese Maßnahmen physikalisch enden, und zum Schluss, was davor im Netz passieren muss.

Alle Angaben beziehen sich auf einen mit SteamCMD installierten Source-Dedicated-Server (srcds_run -game tf) unter Debian 12, Debian 13, Ubuntu 22.04 LTS oder Ubuntu 24.04 LTS. Die Befehle sind für root geschrieben, als normaler Benutzer stellen Sie sudo voran. Läuft der Angriff gerade: Ändern Sie zuerst nichts und starten Sie den Server nicht neu, sondern sichern Sie die Messwerte aus Abschnitt 9. Nach dem Angriff sind sie weg.

Warum Team-Fortress-2-Server DDoS-Schutz brauchen

Team Fortress 2 ist seit 2011 kostenlos spielbar, und genau das verschiebt die Angriffsökonomie. Ein Angreifer hat unbegrenzt viele Wegwerf-Konten, muss für keines davon bezahlen und riskiert bei einer Sperre nichts. Was bei einem Kaufspiel Geld kostet, kostet hier eine Minute.

Dazu kommt eine Besonderheit, die TF2 von den meisten anderen Spielen unterscheidet: Seit dem Update "Meet Your Match" im Juli 2016 gibt es kein Quickplay mehr, das neue Spieler automatisch auf Community-Server verteilt hat. Neue Spieler landen im Casual-Modus auf Valve-Servern. Community-Server sind ausschließlich über den Serverbrowser auffindbar. Wer aus dieser Liste fällt, ist für neue Spieler praktisch nicht mehr vorhanden, selbst wenn der Serverprozess einwandfrei läuft. Ein Angriff, der Ihren Server nur aus der Liste drängt, hat sein Ziel deshalb schon erreicht.

Typische Ziele sind entsprechend: dauerhaft laufende Community-Server mit Stammspielern (2Fort rund um die Uhr, Trade, Jailbreak, Surf, Dodgeball, Mann vs. Machine), Ligaserver mit festem Matchtermin im Ligabetrieb von ETF2L, RGL und ozfortress, sowie Server, deren Betreiber gerade jemanden gesperrt haben. Der Auslöser ist fast nie technisch. Was ein DDoS-Angriff überhaupt ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es bei einem TF2-Server tatsächlich geht

Ein TF2-Server braucht genau einen Port nach außen: 27015/UDP. Alles andere ist entweder abschaltbar, gehört eingeschränkt oder läuft ohnehin nur ausgehend. Diese Tabelle ist die Grundlage für jede Firewall-Regel weiter unten:

Bei mehreren Instanzen auf einer Maschine zählen die Nummern hoch: 27016, 27017 und so weiter für das Spiel, 27021 und 27022 für SourceTV. Die Konfigurationsdatei liegt unter tf/cfg/server.cfg und wird bei jedem Kartenwechsel neu eingelesen.

Warum der geteilte Port 27015 der empfindlichste Punkt ist

Spielverkehr und Serverabfrage teilen sich bei TF2 denselben UDP-Port, einen getrennten Query-Port gibt es nicht. Eine A2S_INFO-Anfrage ist dabei genau 25 Byte lang: vier Byte FF FF FF FF, ein Byte 0x54 und die 20 Byte lange Zeichenkette "Source Engine Query" mit abschließender Null. Die Antwort mit Servername, Karte, Spielerzahl und Tags ist ein Vielfaches davon. Die US-Behörde CISA beziffert den Verstärkungsfaktor des Steam-Protokolls in Alert TA14-017A mit 5,5.

Weil UDP keinen Verbindungsaufbau kennt und Absenderadressen fälschbar sind, war das jahrelang eine offene Verstärkungslücke: Ein Angreifer fragte fremde Source-Server mit der Adresse seines Opfers als Absender ab, und die Server schickten ihre Antworten an das Opfer. A2S_PLAYER und A2S_RULES verlangten schon immer eine vorher abgeholte Challenge, A2S_INFO nicht. Erst im Dezember 2020 hat Valve auch für A2S_INFO eine Challenge nachgerüstet: Der Server darf statt der Antwort ein S2C_CHALLENGE zurückschicken, das der Abfragende wiederholen muss, womit er beweist, dass er die Absenderadresse nicht gefälscht hat.

Das entschärft die Reflexion, beendet den Ärger aber nicht. Jedes Abfragepaket kommt weiterhin bei Ihnen an und kostet Rechenzeit, bevor es beantwortet oder verworfen wird. Und ein Angreifer, der Ihren Server direkt flutet, braucht ohnehin keine Verstärkung.

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

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

1. Bestandsaufnahme: was lauscht, und mit welcher Startzeile

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

ss -lntup

Alles, was an 127.0.0.1 oder ::1 gebunden ist, braucht keine Freigabe. Alles auf 0.0.0.0 oder [::] ist aus dem Internet erreichbar, auch die MySQL-Datenbank, die ein Statistik-Plugin mitgebracht hat, und der Webserver, auf dem Ihre FastDL-Dateien liegen. Vergleichen Sie das Ergebnis mit Ihrer Startzeile:

./srcds_run -game tf -console \
  -port 27015 -steamport 26901 -nohltv \
  +maxplayers 24 +map ctf_2fort +sv_pure 1 \
  +sv_setsteamaccount IHR_GSLT_TOKEN

Jeder Port in dieser Zeile ist eine bewusste Entscheidung. Wie der Unterbau installiert wird, steht in Gameserver mit SteamCMD installieren.

2. Nur die Ports offen lassen, die TF2 wirklich braucht

Ein öffentlicher TF2-Server braucht genau eine Freigabe nach außen, plus RCON für Ihre eigene Adresse. Mit UFW, und zwar in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'TF2 Spiel und A2S'
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment 'RCON'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. SourceTV taucht hier bewusst nicht auf: Wer nicht überträgt, startet mit -nohltv und belegt 27020/UDP gar nicht erst. Das halbiert die von außen erreichbare UDP-Fläche eines TF2-Servers. Übertragen Sie Ligaspiele, kommt ufw allow 27020/udp dazu, und dann gehört ein tv_password gesetzt.

Die vollständige Anleitung samt Rettungsweg steht in UFW-Firewall einrichten, ohne sich selbst auszusperren. Falls es doch passiert: KVM-Rootserver und Dedicated Server von KernelHost erreichen Sie über die VNC-Konsole im Kundenbereich, die unabhängig vom Netzwerk des Gastsystems arbeitet.

3. A2S-Abfragen begrenzen, ohne aus dem Serverbrowser zu fallen

Hier liegt der teuerste Fehler in diesem Themenfeld: 27015/UDP pauschal sperren oder grob ratenbegrenzen wirft die eigenen Spieler heraus und beendet den Angriff im Sinne des Angreifers. Weil Spielverkehr und Abfrage denselben Port belegen, muss die Grenze zwischen den Paketarten verlaufen, nicht auf dem Port.

Die Engine bringt dafür drei Konsolenvariablen mit, die in die tf/cfg/server.cfg gehören:

sv_max_queries_sec 3
sv_max_queries_sec_global 60
sv_max_queries_window 30

Die erste begrenzt die beantworteten Abfragen je Absenderadresse, die zweite die Summe über alle Adressen, die dritte legt das Mittelungsfenster in Sekunden fest. Sie schützen die CPU davor, sinnlos Antworten zu erzeugen. Die Vorgabewerte unterscheiden sich je nach Spiel und Build, find sv_max_queries in der Serverkonsole zeigt, welche Werte Ihr Server kennt.

Der zweite Wert ist bei TF2 der heikle: Er deckelt die Antworten über alle Adressen hinweg. Setzen Sie ihn zu niedrig, beantwortet Ihr Server während einer Abfrageflut auch die Anfragen der Listendienste nicht mehr und verschwindet aus dem Serverbrowser, also aus dem einzigen Weg, auf dem neue Spieler Sie finden. Beginnen Sie großzügig und ziehen Sie erst nach, wenn Sie messen können, dass legitime Abfragen durchkommen.

Eine Ebene tiefer lässt sich derselbe Verkehr sauber abtrennen. Alle verbindungslosen Pakete der Source-Engine beginnen mit vier gesetzten Byte (0xffffffff), der Verkehr bereits verbundener Spieler hat diesen Kopf nicht. Darauf lässt sich eine Ratenbegrenzung legen, ohne den Spielverkehr anzufassen:

table inet tf2 {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Die Datei laden Sie mit nft -f. Die Priorität -10 sorgt dafür, dass die Regel vor der Filterkette von UFW greift, und @th,64,32 liest die ersten vier Byte hinter dem UDP-Kopf.

4. Split-Paket-Fluten abfangen, die im Protokoll als NET_GetLong auftauchen

Dieser Angriff ist eine Eigenheit der Source-Engine und trifft TF2 besonders, weil TF2 bis heute auf dem alten Engine-Zweig läuft. Neben den normalen verbindungslosen Paketen kennt die Engine zerlegte Pakete: Sie beginnen mit FE FF FF FF statt FF FF FF FF und kündigen an, dass eine größere Nachricht in mehreren Teilen folgt. Der Server muss die Teile zwischenspeichern und auf den Rest warten.

Genau das lässt sich missbrauchen. Ein Angreifer schickt massenhaft angekündigte, aber nie vollständige Teilpakete mit gefälschten Absenderadressen. Die CPU-Last steigt, das Spiel ruckelt, und im Serverprotokoll häufen sich Zeilen mit NET_GetLong. Ein einzelner Rechner reicht dafür aus, Bandbreite braucht es kaum. Betreiber melden das regelmäßig als DDoS-Angriff, obwohl die Leitung fast leer ist.

Weil ein regulärer TF2-Client kaum Anlass hat, dem Server zerlegte Pakete zu schicken, ist eine enge Begrenzung hier vertretbar:

udp dport 27015 @th,64,32 0xfffffffe \
    meter tf2split { ip saddr limit rate over 5/second burst 10 packets } drop

Die Zeile gehört in dieselbe Kette wie die Regel aus Abschnitt 3. Einen der wenigen legitimen Gründe für Client-Uploads nehmen Sie zusätzlich mit sv_allowupload 0 aus dem Spiel (siehe Abschnitt 7).

5. RCON aus dem offenen Netz nehmen

Das RCON-Protokoll der Source-Engine überträgt das Passwort im Klartext über TCP. Wer den Weg zwischen Ihnen und dem Server mitlesen kann, hat danach Ihr RCON-Passwort, und wer RCON hat, kann die Karte wechseln, alle Spieler sperren und den Server stoppen. Das ist kein DDoS-Problem, sondern eine Übernahme, wird aber regelmäßig als Angriff gemeldet.

Setzen Sie rcon_password nie leer und nie geraten, ein Wert aus openssl rand -base64 32 genügt. Dazu gehört eine Bremse gegen Anmeldeversuche:

rcon_password "HIER_DER_ZUFALLSWERT"
sv_rcon_maxfailures 3
sv_rcon_minfailures 3
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Damit sperrt der Server eine Adresse nach drei Fehlversuchen innerhalb von 30 Sekunden für 24 Stunden; find sv_rcon zeigt, welche Variablen Ihr Build kennt. Wirksamer bleibt trotzdem die Firewall-Regel aus Abschnitt 2, weil sie den Versuch gar nicht erst bis zur Anwendung durchlässt. Für den Zugriff von wechselnden Anschlüssen richten Sie eine lokale Weiterleitung über SSH ein und sprechen RCON danach auf 127.0.0.1 an:

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

6. Raten deckeln und die Hibernation eingeschaltet lassen

Team Fortress 2 läuft fest mit 66,67 Ticks je Sekunde. Wie viel Verkehr daraus wird, entscheidet nicht der Tick, sondern das, was ein einzelner Client anfordern darf. Ohne Obergrenze holt sich jeder Spieler so viel, wie sein Client verlangt, und das zahlen Sie mit Ihrer Ausgangsbandbreite:

sv_minrate 50000
sv_maxrate 100000
sv_mincmdrate 40
sv_maxcmdrate 66
sv_minupdaterate 40
sv_maxupdaterate 66

Rechnen Sie das einmal durch: Bei sv_maxrate 100000 darf jeder Spieler 100 Kilobyte pro Sekunde beziehen, auf 24 Plätzen sind das 2,4 Megabyte pro Sekunde oder rund 19 Mbit/s ausgehend. Setzen Sie sv_maxrate 0, gibt es keine Obergrenze. Ligaserver machen das bewusst, ein öffentlicher Server mit vielen Plätzen sollte es nicht tun. Plugins, die die Tickrate entsperren, vervielfachen die Paketrate je Spieler und damit dieselbe Rechnung.

Der zweite Punkt wird oft falsch gemacht. TF2 schläft ein, sobald niemand verbunden ist, und braucht in diesem Zustand fast keine CPU. Viele Betreiber schalten das ab, damit der Server sich "wach" anfühlt. Auf einer Maschine mit mehreren Instanzen bedeutet das, dass die CPU schon im Leerlauf ausgelastet ist und ein Angriff auf ein bereits volles System trifft. Lassen Sie die Voreinstellung stehen:

sv_hibernate_when_empty 1
sv_hibernate_postgame_delay 5
tf_allow_server_hibernation 1

7. FastDL trennen und Uploads abschalten

Community-Server leben von eigenen Karten, und genau daraus entsteht eine zweite Angriffsfläche. Ohne sv_downloadurl lädt jeder Spieler die Inhalte über den Netzkanal des Spiels, also über denselben Port und denselben Prozess, der gleichzeitig das Match rechnet. Das sind wenige Kilobyte je Sekunde und eine Datei nach der anderen, und bei einer 200 Megabyte großen Kartensammlung blockiert das Ihren Server minutenlang je Spieler:

sv_allowdownload 1
sv_allowupload 0
net_maxfilesize 64
sv_downloadurl "https://fastdl.example.org/tf/"

net_maxfilesize steht standardmäßig auf 15 und lässt sich auf maximal 64 Megabyte anheben. sv_allowupload 0 verhindert, dass Clients eigene Dateien (etwa Sprühbilder) zum Server schicken, und nimmt damit einen der wenigen legitimen Gründe für zerlegte Pakete aus Abschnitt 4 weg.

Entscheidend ist, wo der FastDL-Host steht. Liegt er auf derselben IP-Adresse wie der Spielserver, reicht eine HTTP-Flut gegen 443/TCP, um die Leitung zu füllen und damit auch 27015/UDP zu ersticken. Legen Sie den schnellen Download auf einen anderen Host oder hinter ein Content-Netzwerk, dann trifft ein Angriff auf die Dateien nicht das Spiel.

8. Vote-System, Beitritts-Fluten und Plugins begrenzen

Nicht jeder Ausfall ist Bandbreite. Weil TF2 kostenlos ist, kostet ein Angriff auf die Spiellogik nichts als Konten: Beitritts-Fluten, die jeden Platz belegen, Sprach- und Chat-Spam, und missbrauchte Abstimmungen, die reguläre Spieler hinauswerfen. Die Voreinstellungen von TF2 sind hier bereits vernünftig, werden aber häufig aufgeweicht:

sv_allow_votes 1
sv_vote_issue_kick_allowed 0
sv_vote_allow_spectators 0
sv_vote_creation_timer 150
sv_vote_failure_timer 300
sv_vote_quorum_ratio 0.6

Das sind die Standardwerte: Abstimmungen sind erlaubt, Kick-Abstimmungen nicht, Zuschauer stimmen nicht mit, zwischen zwei Abstimmungen liegen 150 Sekunden, nach einer gescheiterten 300, und eine Abstimmung braucht 60 Prozent Zustimmung. Wer sv_vote_issue_kick_allowed 1 setzt, sollte wissen, dass er damit ein Werkzeug öffnet, das auf einem öffentlichen Server zuverlässig missbraucht wird.

Alles, was darüber hinausgeht, kommt bei TF2 aus SourceMod und Metamod:Source. Beide liegen unter tf/addons/ und melden sich in der Konsole mit meta version und sm version. Anders als bei Counter-Strike 2 ist der Unterbau hier ausgereift, und Plugins für Sperrlisten, Beitrittsprüfung und Chat-Begrenzung sind der übliche Weg. Zwei Regeln dazu: Jedes Plugin ist Code im selben Prozess, ein abstürzendes Plugin nimmt den Server mit. Und Plugins, die eigene Webdienste mitbringen, öffnen weitere Ports und veröffentlichen mitunter genau die Adresse, die Sie schützen wollen. sm plugins list zeigt, was tatsächlich läuft.

Wie ernst die Engine-Seite zu nehmen ist, zeigt der April 2020: Nach dem Durchsickern älterer Quelltextstände von TF2 und CS:GO haben große Community-Betreiber wie Creators.TF und Red Sun ihre Server aus Sorge vor Ausnutzung vorübergehend abgeschaltet. Halten Sie das Serverbinary aktuell und die Erweiterungen zur Engine-Version passend.

9. Messen und protokollieren, bevor es brennt

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. Während eines Vorfalls genügen vier Befehle:

ip -s link show eth0
nstat -az | grep -i udp
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xffffffff"
tcpdump -ni eth0 -c 200 "udp port 27015 and udp[8:4] = 0xfffffffe"

Der erste Befehl zeigt Pakete, Fehler und Verworfenes je Schnittstelle; führen Sie ihn zweimal im Abstand von zehn Sekunden aus, dann haben Sie eine Rate statt eines Absolutwerts. Die beiden Mitschnitte trennen die Abfrageflut von der Split-Paket-Flut und beantworten damit die Frage, welche der beiden Regeln aus den Abschnitten 3 und 4 überhaupt greifen muss. Begrenzen Sie sie immer mit -c, ein Mitschnitt unter Volllast kostet selbst Rechenzeit.

Innerhalb des Servers liefert der Konsolenbefehl stats in einer Zeile die CPU-Last, die ein- und ausgehende Netzlast in Kilobyte je Sekunde, die Server-FPS und die Spielerzahl. Fallen die Server-FPS deutlich unter den Tickwert, während die Spielerzahl normal ist, arbeitet der Server an etwas anderem als am Spiel. Wie Sie die Werte einordnen, steht in DDoS-Angriff am Server erkennen.

Wo diese Maßnahmen aufhören: Bandbreite und Paketrate

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.

Stellen Sie den Normalbetrieb eines vollen TF2-Servers neben einen realen Angriff, dann wird das Verhältnis deutlich:

Ein typischer Gameserver hängt an 1 Gbit/s, das sind 125 Megabyte pro Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Die zweite Größe ist die Paketrate, und sie schlägt meist früher zu als die Bandbreite: Jedes Paket kostet einen Durchlauf durch den Netzwerkstack, auch wenn es danach verworfen wird. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, legt Ihren Server deshalb trotzdem lahm. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg".

Zur Einordnung, welche Größenordnungen real vorkommen: Auf KernelHost-Servern wurden unter anderem ein UDP-Flood gegen einen Gameserver mit über 112,2 Gbit/s bei über 8,7 Millionen Paketen pro Sekunde und ein Multi-Vektor-Angriff gegen einen Voice-Server mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen pro Sekunde in Echtzeit gefiltert. 473,4 Gbit/s sind rund das 470-Fache einer 1-Gbit/s-Anbindung. Dafür gibt es keine lokale Einstellung.

Die zwei verbreiteten Notbremsen helfen nicht weiter. Nullrouting nimmt die angegriffene IP-Adresse aus dem Netz und beendet den Angriff, aber auch Ihren Server. Eine reaktive Umleitung kostet in der Umschaltzeit genau die Minuten, in denen das Match entschieden wird. Wirksam ist nur eine Filterung, die dauerhaft im Netz vor dem Server läuft.

Was KernelHost gegen Angriffe auf TF2-Server stellt

Der Dauerschutz, der in jedem Serverpaket enthalten ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und ab der Bereitstellung dauerhaft aktiv, ohne dass Sie etwas bestellen, einschalten 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 für einen TF2-Server entscheidend. Die Filterung läuft permanent und muss nicht erst auf einen Angriff reagieren, es gibt also keine Umschaltzeit, in der Ihre Spieler herausfliegen und Ihr Server aus dem Serverbrowser fällt. Und es wird kein Nullrouting eingesetzt: Ihre IP-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Server

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen, mit wechselnden Mustern und immer genau zum Matchtermin. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR 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 in unserem 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 27015/UDP erlaubt ist, was auf 27020/UDP und was auf 27015/TCP, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, statt bis zum Ende des Matches zu warten.
• Schutzprofil passend zum Spiel, für Team Fortress 2 und die übrigen Source-Titel ebenso wie freie TCP- und UDP-Profile für eigene Anwendungen.

Das Angebot richtet sich an Server, die bei KernelHost laufen. Wenn Ihr TF2-Server derzeit woanders steht und regelmäßig beschossen wird, ist der Umzug der Weg zu diesem Schutz.

Die beiden Stufen im Vergleich

Für die meisten TF2-Community-Server reicht der inkludierte Dauerschutz zusammen mit einer sauberen Serverkonfiguration. Die Advanced DDoS Protection ist die Antwort darauf, dass jemand es persönlich nimmt.

Häufige Fehler und Lösungen

"Der Server läuft, steht aber nicht mehr im Serverbrowser": Prüfen Sie zuerst das Game Server Login Token. TF2-Server brauchen für den öffentlichen Eintrag ein Token, gesetzt über sv_setsteamaccount und erzeugt für die App-ID 440. Steam zieht Token zurück, die 30 Tage lang nicht benutzt wurden. Ein Server, der nach einer längeren Pause verschwindet, braucht also oft nur ein neues Token und wird gar nicht angegriffen. Erst danach kommen ein zu niedriges sv_max_queries_sec_global oder eine zu grobe Firewall-Regel auf 27015/UDP in Frage.

"Die CPU steht bei 100 Prozent, die Leitung ist fast leer": Das ist das typische Bild einer Abfrage- oder Split-Paket-Flut. Sehen Sie im Serverprotokoll nach Zeilen mit NET_GetLong und messen Sie mit den beiden tcpdump-Zeilen aus Abschnitt 9, welche Paketart ankommt.

"Meine nftables- oder iptables-Regeln greifen nicht": Drei Ursachen sind häufig. Die Regel steht hinter den UFW-Ketten und wird nie erreicht (deshalb die Priorität -10), sie war nach dem letzten Neustart weg, oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist. Prüfen Sie mit nft list ruleset, ob die Zähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht.

"Ich habe die IP-Adresse gewechselt und war am nächsten Tag wieder offline": Der Angreifer findet die neue Adresse aus derselben Quelle wie die alte. Ihr Server veröffentlicht sie selbst, sobald er wieder im Serverbrowser steht, und alte DNS-Einträge sowie Discord-Statusbots tun den Rest. Ein Adresswechsel verschafft Stunden, keine Lösung.

"Der Server stürzt reproduzierbar ab, ohne dass die Bandbreite auffällt": Meist kein DDoS-Angriff, sondern ein Plugin, das zur Engine-Version nicht passt, oder ein veraltetes Serverbinary. sm plugins list und ein Abgleich der Versionsstände sind hier schneller als jede Filterregel.

"Der Server reagiert nach dem Leerlauf verzögert": Das ist die Hibernation und kein Fehler. Sie senkt die CPU-Last auf nahezu null, solange niemand verbunden ist, und das ist genau der Zustand, in dem Sie Reserven haben wollen.

"Auf dem Server laufen fremde Administrationsbefehle": Kein DDoS-Angriff, sondern ein kompromittierter RCON-Zugang. Passwort sofort neu setzen, Port auf die eigene Adresse einschränken, und daran denken, dass das Passwort im Klartext über die Leitung geht.

"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.

Kurz zusammengefasst

• Ein TF2-Server braucht nach außen genau 27015/UDP. RCON auf 27015/TCP gehört auf die eigene Adresse beschränkt, SourceTV auf 27020/UDP wird mit -nohltv abgeschaltet, wenn Sie nicht übertragen.
• Spielverkehr und A2S-Abfrage teilen sich denselben Port. Wer 27015/UDP pauschal sperrt oder ratenbegrenzt, wirft die eigenen Spieler heraus. Die Grenze muss zwischen den Paketarten verlaufen, erkennbar an den ersten vier Byte hinter dem UDP-Kopf.
• Split-Paket-Fluten mit dem Kopf FE FF FF FF erzeugen CPU-Last statt Bandbreite und stehen im Protokoll als NET_GetLong. Eine enge Begrenzung dieser Paketart ist bei TF2 vertretbar.
• Seit "Meet Your Match" finden neue Spieler Community-Server nur noch über den Serverbrowser. Jede Maßnahme, die Sie aus der Liste drängt, wirkt wie der Angriff selbst.
• Ein voller 24-Plätze-Server verarbeitet rund 1.600 eingehende Pakete pro Sekunde. Angriffe gegen Community-Gameserver liegen üblicherweise bei 5 bis 50 Gbit/s und mehreren Millionen Paketen pro Sekunde.
• 1 Gbit/s trägt bei kleinsten Paketen rund 1,49 Millionen Pakete pro Sekunde. Oberhalb dieser Grenze entscheidet ausschließlich das Netz vor dem Server, keine Regel auf dem Server.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten und ab der Bereitstellung aktiv, ohne Nullrouting. Die Advanced DDoS Protection kommt ab 50,00 EUR im Monat dazu, wenn Sie die Regeln je Port selbst steuern wollen.

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. Nennen Sie dabei gleich vier Angaben: IP-Adresse, Port, Zeitraum in Ihrer Zeitzone und was Sie sehen. Das erspart eine Rückfragerunde, und die zählt, wenn ein Match läuft.