CS2- und Source-Server vor DDoS-Angriffen schützen

Ein Counter-Strike-Server fällt selten zu einem beliebigen Zeitpunkt aus. Der Ausfall kommt in der entscheidenden Runde, kurz vor dem Turnierfinale oder genau dann, wenn ein gesperrter Spieler zum zweiten Mal abgewiesen wurde. Wer gerade beschossen wird, braucht keine Grundsatzdiskussion, sondern eine Reihenfolge. Dieser Beitrag zeigt zuerst, was Sie selbst am Server ändern können, danach, wo diese Möglichkeiten enden, und zum Schluss, was davor im Netz passieren muss.

Warum CS2- und Source-Server so häufig angegriffen werden

Counter-Strike ist ein Spiel auf Zeit. Eine Runde dauert weniger als zwei Minuten, ein Match knapp eine Stunde, und ein Ausfall in dieser Stunde entscheidet über das Ergebnis. Der Ausfall ist damit nicht nur ärgerlich, sondern ein Werkzeug: Wer zurückliegt, gewinnt durch einen Abbruch Zeit, und wer eine konkurrierende Community betreibt, weiß, dass ein Abend voller Timeouts die Stammspieler weiterziehen lässt.

Dazu kommt die Bauweise der Engine. Ein Source-Server ist mit IP-Adresse und Port öffentlich auffindbar, und das ist Voraussetzung, kein Versehen: Ohne beantwortete Serverabfrage steht er in keinem Browser. Die Frage lautet also nie, ob ein Angreifer Ihre Adresse findet, sondern nur, was passiert, wenn er darauf schießt.

Die Ports, um die es geht

Counter-Strike 2, CS:GO und Garry's Mod teilen sich dieselbe Portlogik, und darin steckt ein Punkt, der sie von Minecraft oder Rust unterscheidet:

• 27015/UDP, Spielport und Serverabfrage zugleich (-port). Über diesen einen Port läuft der Spielverkehr und zusätzlich die A2S-Abfrage, mit der Steam und jede Listenseite den Server auslesen. Einen getrennten Query-Port gibt es hier nicht.
• 27015/TCP, RCON. Gleiche Nummer, anderes Protokoll. Darüber laufen Administrationsbefehle, sofern rcon_password gesetzt ist.
• 27020/UDP, GOTV beziehungsweise SourceTV (tv_port). Nur nötig, wenn Sie tatsächlich übertragen.
• 27005/UDP, Client-Port. Der geht vom Spieler aus und braucht auf dem Server keine Freigabe.
• Bei mehreren Instanzen zählen die Nummern hoch (27016, 27017 sowie 27021, 27022 für GOTV). Liegt der schnelle Download für Karten (sv_downloadurl) auf demselben Host, kommt 80/TCP oder 443/TCP dazu.

Der geteilte Port ist der Kern des Problems. Eine A2S-Anfrage ist ein Paket von wenigen Dutzend Byte, die Antwort ein Vielfaches davon, und bei UDP lässt sich die Absenderadresse fälschen. Ein Angreifer kann fremde Server abfragen und die Antworten auf sein eigentliches Ziel lenken: Ihr Server ist dann nicht nur Opfer, sondern Verstärker. Valve hat A2S_INFO deshalb um eine vorgeschaltete Challenge ergänzt, was die Sache entschärft, aber nicht beendet hat. Woran Sie einen laufenden Angriff erkennen, beschreibt der Beitrag DDoS-Angriff am Server erkennen.

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

Der folgende Teil kostet nichts und lohnt sich unabhängig davon, wo Ihr Server steht. Er nimmt Ihnen keinen volumetrischen Angriff ab, lässt aber kleine und mittlere Angriffe verpuffen.

1. Bestandsaufnahme: was lauscht wirklich

Bevor Sie eine Regel schreiben, klären Sie, welche Dienste erreichbar sind. Auf einem gewachsenen Gameserver sind das fast immer mehr als erwartet:

ss -lntup

Alles, was an 127.0.0.1 oder ::1 gebunden ist, braucht keine Freigabe. Alles, was auf 0.0.0.0 oder [::] lauscht, ist aus dem Internet erreichbar, auch die Datenbank, die ein Statistik-Addon mitgebracht hat. Vergleichen Sie das mit Ihrer Startzeile:

./game/bin/linuxsteamrt64/cs2 -dedicated \
  -port 27015 \
  -maxplayers_override 12 \
  +game_alias competitive \
  +map de_dust2 \
  +sv_setsteamaccount IHR_GSLT_TOKEN

Bei CS:GO und Garry's Mod übernimmt srcds_run dieselbe Aufgabe. Ist der Unterbau über SteamCMD eingerichtet, hilft der Beitrag Gameserver mit SteamCMD installieren.

2. Nur die Ports offen lassen, die der Server wirklich braucht

Zwei UDP-Ports und ein eingeschränkter TCP-Port, mehr nicht. RCON gehört nicht ins offene Internet:

ufw allow 27015/udp comment "CS2 Spielport und A2S"
ufw allow 27020/udp comment "GOTV"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Wechselt diese regelmäßig, führt der Weg über einen SSH-Tunnel statt über eine dauerhafte Freigabe.

Ein Hinweis, der jedes Jahr Server kostet: Die Reihenfolge beim Scharfschalten einer Firewall entscheidet darüber, ob Sie sich selbst aussperren. Sie steht samt Rückweg im Beitrag UFW-Firewall einrichten. Falls es doch passiert: KVM-Rootserver und Dedicated Server von KernelHost haben kein IPMI und kein iDRAC, Sie erreichen den Server über die VNC-Konsole im Kundenbereich. Diese hängt nicht am Netzwerkstack des Gastsystems.

3. Den Abfrageverkehr begrenzen, ohne aus der Serverliste zu fliegen

Hier liegt der teuerste Fehler in diesem Themenfeld. Weil Spielverkehr und Serverabfrage denselben Port belegen, ist die naheliegende Reaktion falsch: Wer 27015/UDP sperrt oder pauschal ratenbegrenzt, wirft im selben Zug seine eigenen Spieler heraus und bringt den Angriff selbst zu Ende.

Der richtige Ansatzpunkt ist die Unterscheidung zwischen Abfrage- und Spielpaketen. Die Engine sieht den Inhalt und bringt dafür drei Konsolenvariablen mit:

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 deckelt die Summe über alle Adressen, die dritte legt das Mittelungsfenster in Sekunden fest; find sv_max_queries zeigt, ob Ihr Build sie kennt. Sie schützen die CPU davor, sinnlos Antworten zu erzeugen, verhindern aber nicht, dass die Pakete ankommen.

Eine Ebene tiefer lässt sich der Abfrageverkehr sauber abtrennen. Alle verbindungslosen Pakete der Source-Engine, also Serverabfragen und Verbindungsaufbau, beginnen mit vier gesetzten Byte (0xffffffff), der Verkehr bereits verbundener Spieler hat diesen Kopf nicht. Genau darauf lässt sich mit nftables eine Ratenbegrenzung legen:

table inet cs2 {
    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. Mit klassischem iptables erreicht dieselbe Trennung ein Abgleich auf die A2S_INFO-Kennung:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Beginnen Sie großzügig und ziehen Sie die Grenze erst an, wenn legitime Abfragen nachweislich durchkommen.

4. RCON absichern

Ein offener RCON-Port mit schwachem Passwort ist kein DDoS-Problem, sondern eine Übernahme: Wer RCON hat, kann die Karte wechseln, alle Spieler sperren und den Server stoppen. Setzen Sie rcon_password nie leer und nie geraten, ein Wert aus openssl rand -base64 32 genügt. Die Source-Titel bringen zusätzlich eine Bremse gegen Anmeldeversuche mit:

sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440
sv_rcon_whitelist_address "203.0.113.10"

Damit wird eine Adresse nach drei Fehlversuchen innerhalb von 30 Sekunden für einen Tag gesperrt, während Ihre eigene ausgenommen bleibt; find sv_rcon zeigt, welche Variablen Ihr Build kennt. Die Firewall-Einschränkung aus Schritt 2 bleibt trotzdem wirksamer, weil sie den Versuch nicht bis zur Anwendung durchlässt.

5. Die Verbindungsverfolgung entlasten

Dieser Punkt wird oft übersehen und erklärt Ausfälle, die wie ein Volumenangriff aussehen, aber keiner sind. Der Kernel legt für UDP-Verkehr Einträge in der Verbindungsverfolgung (conntrack) an, und bei gefälschten Absenderadressen bedeutet jede Adresse einen neuen Eintrag. Ist die Tabelle voll, verwirft der Kernel Pakete ohne Unterschied: Der Angriff und Ihre Spieler fliegen gemeinsam heraus. Der wirksamste Schritt ist, den Spielverkehr gar nicht erst verfolgen zu lassen, denn die Engine verwaltet ihre Sitzungen selbst:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 27015, 27020 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 27015, 27020 } notrack
    }
}

Mit iptables lautet die Entsprechung iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK und dieselbe Zeile für OUTPUT mit --sport. Der Port braucht danach eine ausdrückliche Freigabe, denn ohne Verfolgung greift keine Regel mehr, die auf einen bestehenden Zustand prüft.

6. Empfangspuffer und Kernel-Parameter

Kommen Pakete schneller an, als der Serverprozess sie abholt, läuft der Empfangspuffer über. Für die Spieler sieht das aus wie Paketverlust, obwohl die Leitung frei ist. Ein Aufschlag unter /etc/sysctl.d/, aktiviert mit sysctl -p, verschafft Luft:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Ob die Werte nötig sind, verrät der Kernel selbst: Steigt UdpRcvbufErrors in nstat -az an, dann greifen sie. Bleibt der Zähler bei null, ändert die Anpassung nichts. Das ist Reserve, kein Schutz.

7. Anti-Cheat- und Plugin-seitige Maßnahmen

Ein erheblicher Teil der als DDoS gemeldeten Ausfälle sind keine. Es sind Abstürze, die ein einzelner Client mit wenigen hundert Paketen auslöst, weil im Serverbinary oder in einer Erweiterung eine Lücke offensteht. Dagegen hilft keine Bandbreite, sondern Pflege:

• Serverbinary aktuell halten. Aktualisierungen schließen neben Spielinhalten auch Netzwerkfehler. Ein Server, der zwei Versionen hinterherhinkt, steht bekannten Absturzmustern offen.
• Erweiterungen zur Engine-Version passend halten. Für CS:GO und Garry's Mod sind Metamod:Source und SourceMod der übliche Unterbau; für Counter-Strike 2 gibt es SourceMod bislang nicht in gleicher Reife, verbreitet sind dort Metamod:Source in den Entwicklungsständen sowie CounterStrikeSharp. Eine unpassende Erweiterung ist der häufigste Grund für Abstürze nach einem Update.
• Weniger Erweiterungen. Jedes Plugin ist Code im selben Prozess, und Erweiterungen mit eigenen Webdiensten öffnen weitere Ports und veröffentlichen oft die Adresse, die Sie schützen wollen.
• Bei Garry's Mod die Netznachrichten begrenzen. Der bekannteste Selbstschuss ist ein Menü, das ohne Begrenzung auf net.Receive hört: Ein Client sendet die Nachricht in einer Schleife und bremst den Server allein aus.

local last = {}

net.Receive("mein_menue", function(len, ply)
    if last[ply] and CurTime() - last[ply] < 0.5 then return end
    last[ply] = CurTime()
end)

hook.Add("PlayerDisconnected", "mein_menue_cleanup", function(ply)
    last[ply] = nil
end)

Ebenfalls bei Garry's Mod: sv_allowcslua 0 verhindert, dass Clients eigenen Lua-Code ausführen. Sperren gehören dauerhaft abgelegt, sonst sind sie nach dem Neustart weg: Die Source-Titel kennen dafür banid und writeid sowie addip und writeip; was Ihr Build mitbringt, zeigt find ban.

8. Serverliste, Whitelist und die eigene Adresse

Ein öffentlicher Counter-Strike-Server braucht ein Game Server Login Token, gesetzt über sv_setsteamaccount. Ohne dieses Token bleibt er unregistriert und taucht in keiner öffentlichen Liste auf. Für eine feste Gruppe ist genau das wirksam: sv_password setzen, auf die Registrierung verzichten und die Adresse nur an die eigenen Spieler geben. Für einen öffentlichen Server ist das keine Option: Ein Server, den niemand findet, ist genauso leer wie einer, der offline ist. Eine echte Whitelist bringt die Engine nicht mit, sie kommt über Erweiterungen.

An der Spielserver-Adresse lässt sich nichts ändern, sehr wohl aber an allem daneben: Oft findet ein Angreifer gleich die ganze Umgebung, vom Webserver über den Host des Discord-Bots bis zum Panel-Zugang. Diese Adressen gehören nicht in dieselbe Ankündigung wie die Serveradresse und nicht in alte DNS-Einträge.

9. Protokollieren, damit Sie im Angriff nicht raten müssen

Im Angriff ist die wichtigste Frage: Wie viel kommt an und auf welchem Port. Drei Kommandos genügen:

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

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 dritte Zeile zeigt ausschließlich die verbindungslosen Pakete, also die Klasse, die eine Abfrageflut missbraucht. Halten Sie diese Mitschrift kurz, weil sie unter Last selbst Rechenzeit kostet. Läuft der Zähler in Sekunden voll, während kaum jemand verbunden ist, haben Sie Ihre Antwort.

Wo der Eigenschutz aufhört

Jetzt der ehrliche Teil. Alles bisher Beschriebene wirkt erst, wenn die Pakete auf Ihrer Netzwerkkarte angekommen sind. Bei kleinstmöglicher Paketgröße trägt eine 1-Gbit/s-Leitung rund 1,49 Millionen Pakete pro Sekunde, eine 10-Gbit/s-Leitung rund 14,88 Millionen. Das ist die physikalische Obergrenze, unabhängig von CPU, Kernel und Firewall.

Dem gegenüber stehen reale Angriffe. Zwei Beispiele aus dem Betrieb bei KernelHost, beide in Echtzeit gefiltert: ein UDP-Flood gegen einen Gameserver auf 7777/UDP mit über 112,2 Gbit/s und über 8,7 Millionen Paketen pro Sekunde, sowie ein Multi-Vektor-Angriff gegen einen Voice-Server auf 9987/UDP mit über 473,4 Gbit/s und über 41,5 Millionen Paketen pro Sekunde.

Rechnen Sie das gegen Ihre Leitung: 473,4 Gbit/s sind rund das 470-Fache einer 1-Gbit/s-Anbindung und immer noch rund das 47-Fache einer 10-Gbit/s-Anbindung. Ihre Regel kann noch so korrekt sein, sie wird nie ausgeführt, weil der Verlust vorher entsteht, am Router davor. Und lange bevor die Leitung voll ist, ist die CPU am Ende, denn jedes Paket kostet einen Durchlauf durch den Netzwerkstack, auch wenn es danach verworfen wird.

Deshalb sind die zwei verbreiteten Notbremsen unbefriedigend. Nullrouting (Blackholing) nimmt die angegriffene IP aus dem Netz und beendet zwar 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 dagegen stellt

Der Dauerschutz, der auf jedem Server läuft

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und permanent aktiv, ohne dass Sie etwas einschalten müssen. Die erste Stufe ist ein globales Scrubbing-Netzwerk mit 17 Tbps Mitigationskapazität, das volumetrische Angriffe nah an ihrer Quelle abfängt, lange bevor sie das Rechenzentrum erreichen. Die zweite Stufe ist eine Arbor-Echtzeitfilterung mit 3,2 Tbps direkt vor Ort in Frankfurt am Main, die die Feinarbeit übernimmt und komplexe Muster auf Layer 3 bis 7 verwirft.

Zwei Punkte sind entscheidend. Erstens läuft die Filterung dauerhaft, es gibt also keine Umschaltzeit, in der Ihre Spieler herausfliegen. Zweitens wird kein Nullrouting eingesetzt: Die angegriffene IP bleibt im Netz, nur die schädlichen Pakete fallen weg. Der Schutz ist in jedem Serverpaket ohne Aufpreis enthalten, ohne separates Schutzpaket und ohne Einrichtung. Die Server stehen im maincubes Premium Datacenter in Frankfurt am Main (Deutschland), Anbieter ist die KernelHost GmbH mit Sitz in Wien (Österreich). Welche Spiele und Protokolle abgedeckt sind, listet der Beitrag Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden über Wochen gezielt angegriffen, mit wechselnden Mustern und immer genau zum Matchtermin. Für diese Fälle gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid und ohne Mindestlaufzeit. Sie bringt drei Dinge mit, die der inkludierte Dauerschutz nicht bietet:

• Eine dedizierte Schutz-IP. Ihr Server wird in unserem Netz auf diese Adresse umgestellt, ein Umbau auf Ihrer Seite ist nicht nötig.
• Selbst verwaltbare Schutzregeln je Port und Protokoll. Sie legen im Kundenbereich fest, welcher Port mit welchem Profil gefiltert wird, etwa 27015/UDP anders als 27020/UDP. Änderungen greifen in Echtzeit, ohne Ticket und ohne Wartezeit.
• Ein Schutzprofil passend zum jeweiligen Spiel. Für Counter-Strike 2 und die Source-Titel ebenso wie für über 40 weitere Spiele und Protokolle, dazu freie TCP- und UDP-Profile für modifizierte Server.

Auch hier gilt das PrePaid-Modell: keine Mindestlaufzeit, keine Kündigungsfrist, kein Vertrag und keine Einrichtungsgebühr. Ist die Angriffswelle vorbei, verlängern Sie einfach nicht.

Die beiden Stufen im Vergleich

Häufige Fehler und Lösungen

Der Server ist aus dem Browser verschwunden, läuft aber weiter: Meist wurde 27015/UDP pauschal gesperrt oder zu eng ratenbegrenzt, und weil Spielverkehr und Abfrage denselben Port teilen, trifft eine grobe Regel beides. Arbeiten Sie stattdessen mit einem Abgleich auf die verbindungslosen Pakete. Fehlt der Server trotz erreichbarem Port, prüfen Sie sv_setsteamaccount.

Alle Spieler haben hohen Ping, die Leitung ist aber nicht voll: Das deutet auf Paketrate statt Volumen hin. Sehen Sie sich die verworfenen Pakete in ip -s link show und die UDP-Zähler in nstat -az an. Steht im Systemprotokoll nf_conntrack: table full, nehmen Sie den Spielport mit notrack heraus.

Die Firewall-Regel ist korrekt und wirkt trotzdem nicht: Dann ist die Leitung vor dem Server gesättigt. Eine Regel, die nie ausgeführt wird, weil das Paket schon am Router davor verworfen wurde, kann nichts bewirken. Ab hier hilft nur Filterung im Netz.

Nach dem Scharfschalten der Firewall kein SSH-Zugang mehr: Über die VNC-Konsole im Kundenbereich anmelden (ein IPMI oder iDRAC gibt es nicht) und die Firewall dort abschalten.

Der Angriff pausiert nach einem IP-Wechsel und kommt nach ein bis zwei Tagen zurück: Das ist der Normalfall, denn Ihr Server veröffentlicht die neue Adresse selbst, sobald er wieder registriert ist. Ein IP-Wechsel verschafft Stunden, keine Lösung.

Der Server stürzt reproduzierbar ab, ohne dass die Bandbreite auffällt: Meist kein DDoS, sondern ein Absturzmuster in einer Erweiterung oder eine veraltete Serverversion.

Auf dem Server laufen fremde Administrationsbefehle: Kein DDoS, sondern ein kompromittierter RCON-Zugang. Passwort sofort ändern und den Port einschränken.

Wenn Sie gerade angegriffen werden

Läuft Ihr Server bereits bei KernelHost, ist die Filterung permanent aktiv. Bemerken Sie trotzdem Auffälligkeiten, eröffnen Sie ein Support-Ticket, damit unser Team die Filterregeln für Ihre IP nachjustiert. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfall-Chat unter +43 650 8209883.

Nennen Sie dabei gleich vier Angaben: IP-Adresse, Port, Zeitraum in Ihrer Zeitzone und was Sie sehen (Spieler fliegen heraus, Server nicht im Browser, hoher Ping). Das erspart eine Rückfragerunde, und die zählt, wenn ein Match läuft.