Left-4-Dead-2-Server vor DDoS-Angriffen schützen

Ein Left-4-Dead-2-Server fällt selten zum bequemen Zeitpunkt aus. Er fällt im letzten Abschnitt einer Kampagne aus, im zweiten Durchgang eines Versus-Matches oder genau dann, wenn ein gesperrter Spieler zum dritten Mal abgewiesen wurde. Wer gerade beschossen wird, braucht keine Grundsatzdiskussion über Netzwerktechnik, sondern eine Reihenfolge. Dieser Beitrag zeigt zuerst, wie Sie einen Left-4-Dead-2-Server vor DDoS-Angriffen schützen, solange das mit Bordmitteln noch geht, danach, wo diese Möglichkeiten physikalisch enden, und zum Schluss, was davor im Netz passieren muss.

Alle Angaben beziehen sich auf einen dedizierten Server (srcds), installiert über SteamCMD unter der App-ID 222860, 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. Ein Punkt vorweg, weil er die Reihenfolge bestimmt: Ändern Sie während eines laufenden Angriffs nichts blind und starten Sie den Server nicht neu, bevor Sie die Messwerte gesichert haben. Nach dem Angriff sind sie weg.

Warum Left-4-Dead-2-Server ein lohnendes DDoS-Ziel sind

Der Unterschied zu einem Shooter mit 64 Plätzen liegt in der Größe der Runde. Eine Koop-Kampagne hat vier Plätze für Überlebende, ein Versus-Match acht Plätze für beide Seiten zusammen. Ein Ausfall trifft deshalb nie einzelne Spieler, sondern immer die gesamte Partie: Wer eine Kampagne im dritten von fünf Abschnitten abbricht, hat den Abend für alle Beteiligten beendet. Genau das macht einen Angriff für den Auslöser attraktiv, denn er kostet ihn weder Können noch nennenswertes Geld, während er auf der Gegenseite eine Stunde Spielzeit vernichtet.

Dazu kommt die Bauweise. Left 4 Dead 2 läuft auf der Source-Engine, und ein Source-Server ist mit IP-Adresse und Port öffentlich auffindbar. Das ist Voraussetzung, kein Versehen: Ein Server, der keine Abfrage beantwortet, steht in keiner Liste und wird von keiner Lobby gefunden. Die Frage lautet also nie, ob ein Angreifer Ihre Adresse kennt, sondern nur, was passiert, wenn er darauf schießt. Der Spielverkehr läuft über UDP, und UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, dazu lassen sich Absenderadressen fälschen. Was dabei technisch abläuft, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Ein dritter Punkt ist Left 4 Dead 2 eigen und hat kein Gegenstück bei Counter-Strike, Garry's Mod oder Team Fortress 2: Die meisten Spieler kommen nicht über den Serverbrowser, sondern über das Lobby-System. Eine Lobby aus bis zu vier Spielern wird über das Steam-Matchmaking auf einen dedizierten Server vermittelt, der dafür eine Reservierung erhält. Dieses Verfahren ist gleichzeitig Ihr wirksamster Zugangsfilter und eine zusätzliche Angriffsfläche. Beides steht weiter unten im Detail.

Die Ports, um die es tatsächlich geht

Ein Left-4-Dead-2-Server belegt genau einen UDP-Port für alles, was das Spiel ausmacht. Standard ist 27015, festgelegt über -port beziehungsweise +hostport in der Startzeile:

./srcds_run -game left4dead2 -console -nohltv \
  -port 27015 \
  +ip 203.0.113.10 \
  +maxplayers 4 \
  +exec server.cfg \
  +map c1m1_hotel

Die erste Zeile dieser Tabelle ist der Kern des Problems. Spielverkehr und Serverabfrage teilen sich 27015/UDP, es gibt bei Left 4 Dead 2 keinen getrennten Query-Port. Wer diesen Port pauschal sperrt oder grob ratenbegrenzt, wirft im selben Zug seine eigenen Spieler heraus und beendet den Angriff im Sinne des Angreifers.

Eine A2S-Anfrage ist ein Paket von wenigen Dutzend Byte, die Antwort ein Vielfaches davon. Bei UDP lässt sich die Absenderadresse fälschen, und damit wird Ihr Server nicht nur Opfer, sondern Verstärker: Ein Angreifer fragt fremde Spielserver mit der Adresse seines Ziels ab und lenkt deren Antworten dorthin. Valve hat A2S_INFO im Dezember 2020 um eine vorgeschaltete Aufforderung (S2C_CHALLENGE) ergänzt, die der Abfragende zurückschicken muss, bevor er die Antwort bekommt. Das entschärft die Reflexion, beendet sie aber nicht, weil ältere Abfrageprogramme weiterhin bedient werden.

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, und er beseitigt die Ausfälle, die fälschlich als DDoS-Angriff gemeldet werden.

1. Bestandsaufnahme: was lauscht wirklich

Bevor Sie eine Regel schreiben, klären Sie, welche Dienste erreichbar sind. Auf einem gewachsenen Left-4-Dead-2-Server sind das fast immer mehr als erwartet, weil neben srcds noch ein Webserver für die Kampagnen, eine Statistikdatenbank und manchmal ein zweiter Server für Versus laufen:

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. Die Sicht des Angreifers liefert ein Portscan von außen, und die weicht erfahrungsgemäß von der eigenen Erwartung ab:

nmap -Pn -sU -sT -p 27000-27050,80,443,3306 IHRE.SERVER.IP.ADRESSE

Ist der Unterbau frisch aufgesetzt oder wollen Sie ihn nachvollziehen, beschreibt der Beitrag Gameserver mit SteamCMD installieren den Weg von SteamCMD bis zum laufenden srcds.

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

Ein UDP-Port nach außen, ein TCP-Port für die eigene Adresse, mehr nicht. RCON gehört nicht ins offene Internet, denn wer RCON hat, wechselt die Karte, sperrt alle Spieler und stoppt den Server:

ufw allow 27015/udp comment "L4D2 Spielport und A2S"
ufw allow from 203.0.113.10 to any port 27015 proto tcp comment "RCON"
ufw allow from 203.0.113.10 to any port 22 proto tcp comment "SSH"
ufw default deny incoming
ufw default allow outgoing
ufw --force enable

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Wechselt diese regelmäßig, führt der Weg über eine SSH-Portweiterleitung statt über eine dauerhafte Freigabe. Die Reihenfolge beim Scharfschalten entscheidet darüber, ob Sie sich selbst aussperren; sie steht samt Rückweg im Beitrag UFW-Firewall einrichten, ohne sich selbst auszusperren. 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, und die hängt nicht am Netzwerkstack des Gastsystems.

3. Die A2S-Abfrage bremsen, ohne aus der Lobby-Suche zu fallen

Hier liegt der teuerste Fehler in diesem Themenfeld. Weil Spielverkehr und Serverabfrage denselben Port belegen, muss die Bremse zwischen beiden Paketklassen unterscheiden, nicht zwischen Ports.

Der Steam-Gameserver-Unterbau bringt dafür seit den Änderungen von Dezember 2020 eine eigene Begrenzung mit, die vor dem Start als Umgebungsvariable gesetzt wird. STEAM_GAMESERVER_RATE_LIMIT_200MS=N verwirft verbindungslose Pakete (A2S_INFO, A2S_RULES, A2S_PLAYERS) einer Absenderadresse, sobald in einem Fenster von 200 Millisekunden mehr als N davon eintreffen. Valve nennt 25 bis 75 als brauchbaren Bereich, standardmäßig ist die Begrenzung aus:

export STEAM_GAMESERVER_RATE_LIMIT_200MS=50
./srcds_run -game left4dead2 -console -port 27015 +exec server.cfg +map c1m1_hotel

In einer systemd-Unit gehört derselbe Wert als Environment=STEAM_GAMESERVER_RATE_LIMIT_200MS=50 in den Abschnitt [Service], sonst ist er nach dem nächsten Neustart weg. Diese Bremse greift nur, wenn Ihr Serverbuild den aktuellen Steamworks-Unterbau mitbringt, und sie schützt die Rechenzeit Ihres Servers, nicht Ihre Leitung: Die Pakete sind bereits angekommen.

Eine Ebene tiefer lässt sich derselbe Verkehr im Kernel 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. Darauf lässt sich mit nftables eine Ratenbegrenzung je Absenderadresse legen:

table inet l4d2 {
    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. Beginnen Sie großzügig und ziehen Sie die Grenze erst an, wenn legitime Abfragen nachweislich durchkommen: Ihr eigener Eintrag in der Serverliste hängt daran.

4. Das Lobby-System als Zugangsfilter nutzen

Das ist der Hebel, den nur Left 4 Dead 2 und der Vorgänger haben. Der Server entscheidet selbst, ob er Verbindungen außerhalb des Matchmakings überhaupt annimmt. Vier Direktiven in der server.cfg bestimmen das:

sv_allow_lobby_connect_only 1
sv_search_key "ihr-eigener-schluessel"
sv_steamgroup "103582791400000000"
sv_steamgroup_exclusive 2

• sv_allow_lobby_connect_only 1 lässt ausschließlich Beitritte aus einer Matchmaking-Lobby zu. Ein connect 203.0.113.10:27015 in der Entwicklerkonsole und eine Steam-Einladung werden abgewiesen. Der Wert 0 erlaubt beides.
• sv_search_key ist ein frei wählbarer Suchschlüssel. Nur eine Lobby, in der derselbe Schlüssel gesetzt ist, findet den Server über das Matchmaking. Ohne den Schlüssel taucht er in der öffentlichen Suche nicht auf.
• sv_steamgroup bindet den Server an eine Steam-Gruppe und lässt ihn unter deren Gruppenservern erscheinen.
• sv_steamgroup_exclusive kennt drei Stufen: 0 lässt jeden zu, 1 verhält sich wie 0, verlangt aber den Beitritt über eine Lobby, und 2 lässt nur noch Gruppenmitglieder und den direkten Zugriff über die IP-Adresse durch.

Für eine feste Community ist die Kombination aus Suchschlüssel und sv_steamgroup_exclusive 2 der wirksamste kostenlose Zugangsfilter, den das Spiel kennt. Ein öffentlicher Server kann sie nicht nutzen, denn ein Server, den niemand findet, ist genauso leer wie einer, der offline ist.

Und jetzt der Teil, den Werbetexte gern weglassen: Diese Direktiven schützen Ihre Spiellogik, nicht Ihre Leitung. Ein Angreifer, der 27015/UDP flutet, will gar nicht beitreten. Seine Pakete werden abgelehnt, sind aber trotzdem angekommen, haben Bandbreite verbraucht und einen Durchlauf durch den Netzwerkstack gekostet. Gegen einen Beitritts-Flood aus Wegwerf-Konten wirkt sv_allow_lobby_connect_only 1 hervorragend, gegen einen Booter wirkt es gar nicht.

5. Die Lobby-Reservierung und wann sv_force_unreserved die bessere Wahl ist

Eine Lobby-Reservierung ist eine zeitlich begrenzte Belegung Ihres Servers durch eine Matchmaking-Lobby. Solange sie besteht, gilt der Server für andere Lobbys als vergeben, und sie läuft erst nach einer Weile von selbst ab. Für einen Server mit vier Plätzen ist das eine knappe Ressource: Anders als bei einem Shooter mit 32 oder 64 Plätzen reicht sehr wenig, um eine Partie zu blockieren.

Wer seinen Server nicht über das Matchmaking betreibt, nimmt diese Fläche ganz heraus:

sv_force_unreserved 1
sv_allow_lobby_connect_only 0

sv_force_unreserved 1 bewirkt, dass der Server auf Reservierungsanfragen aus dem Lobby-System nicht mehr antwortet und Beitritte mit einem Reservierungsmerkmal ablehnt. Dieselbe Einstellung brauchen Sie ohnehin, wenn Sie mit L4DToolZ mehr als vier Koop-Plätze betreiben, denn sonst erhält die Lobby eine Reservierung, sobald die ersten vier Plätze belegt sind, und die übrigen Plätze bleiben unerreichbar. Die Kehrseite ist eindeutig: Ihre Spieler kommen dann nur noch über den Serverbrowser oder über connect herein.

Entscheiden Sie sich bewusst für eine der beiden Betriebsarten. Die Mischung aus halb offenem Matchmaking und halb offenem Direktbeitritt ist die Variante, die beide Nachteile vereint.

6. RCON absichern

Ein offener RCON-Port mit schwachem Passwort ist kein DDoS-Problem, sondern eine Übernahme. 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:

rcon_password "HIER_EIN_ZUFAELLIGER_WERT"
sv_rcon_minfailures 3
sv_rcon_maxfailures 5
sv_rcon_minfailuretime 30
sv_rcon_banpenalty 1440

Damit wird eine Adresse nach drei Fehlversuchen innerhalb von 30 Sekunden für einen Tag gesperrt; find sv_rcon in der Serverkonsole zeigt, welche dieser Variablen Ihr Build kennt. Die Firewall-Einschränkung aus Schritt 2 bleibt trotzdem wirksamer, weil sie den Versuch gar nicht erst bis zur Anwendung durchlässt. Wenn Sie RCON nicht brauchen, lassen Sie das Passwort leer: Dann lauscht der TCP-Anteil von 27015 nicht.

7. Custom-Kampagnen auslagern statt über den Spielport ausliefern

Custom-Kampagnen sind der Grund, warum Left 4 Dead 2 nach fünfzehn Jahren noch gespielt wird, und gleichzeitig eine Lastquelle, die es bei Counter-Strike in dieser Form nicht gibt. Eine Kampagne ist ein VPK-Paket mit Karten, Modellen, Texturen und Klängen, also ein Vielfaches dessen, was eine einzelne Wettkampfkarte wiegt.

Der bequeme Weg für die Spieler ist der Steam-Workshop: Das Paket kommt dann von Steam, nicht von Ihrem Server, und kostet Sie keine Bandbreite. Liefern Sie lose Dateien selbst aus, gehört die Auslieferung auf einen Webserver und nicht auf den Spielport:

sv_allowdownload 1
sv_allowupload 0
sv_downloadurl "https://cdn.example.org/l4d2/"
sv_consistency 1

Dateien für sv_downloadurl gehören als bzip2-Archiv auf den Webserver, aus meinekarte.bsp wird also meinekarte.bsp.bz2. Ohne sv_downloadurl schickt srcds die Dateien selbst über die Spielverbindung, und dann gilt: Jeder Verbindungsversuch eines neuen Spielers kostet Sie den vollen Download, jeder Abbruch mitten im Download ebenfalls. Das ist eine ausgesprochen billige Art, eine Leitung zu füllen, und sie sieht in keiner Statistik wie ein Angriff aus.

Drei Punkte dazu, die in der Praxis wehtun. sv_allowupload 0 gehört gesetzt, denn Uploads vom Client zum Server brauchen Sie nicht. Liegt der Webserver für sv_downloadurl auf demselben Host wie das Spiel, teilen sich Download und Spielverkehr dieselbe Leitung und dieselbe IP-Adresse, und ein Angriff auf 443/TCP trifft dann auch Ihre laufende Partie. Und sv_consistency 1 ist kein Schutz gegen Angriffe, sondern gegen abweichende Clientdateien; abschalten sollten Sie es nur, wenn eine Kampagne sonst nachweislich nicht startet.

8. SourceMod, Metamod und die Erweiterungen

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

• Metamod:Source und SourceMod zur Engine-Version passend halten. Left 4 Dead 2 bekommt weiterhin Aktualisierungen, und eine unpassende Erweiterung ist der häufigste Grund für Abstürze direkt nach einem Update.
• Left4DHooks statt eigener Eingriffe. Die L4D2-typischen Ereignisse liegen in dieser Erweiterung gebündelt vor. Eigene Eingriffe in dieselben Funktionen sind der schnellste Weg zu einem Serverbinary, das bei bestimmten Paketfolgen aussteigt.
• L4DToolZ nur bewusst einsetzen. Die Erweiterung hebt die fest eingebauten Platzgrenzen an. Jeder zusätzliche Platz ist ein zusätzlicher Spieler, der Rechenzeit erzeugt, und in Verbindung mit dem Lobby-System braucht sie sv_force_unreserved 1.
• Weniger Erweiterungen. Jedes Plugin ist Code im selben Prozess. Erweiterungen mit eigenen Webdiensten öffnen zusätzliche Ports und veröffentlichen oft genau die Adresse, die Sie schützen wollen.

Sperren gehören dauerhaft abgelegt, sonst sind sie nach dem Neustart weg. Die Source-Titel kennen dafür banid mit writeid sowie addip mit writeip, und die erzeugten Dateien werden über exec banned_user.cfg und exec banned_ip.cfg wieder eingelesen.

9. Verbindungsverfolgung und Empfangspuffer 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. Stand und Obergrenze zeigt ein Blick:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

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 notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport 27015 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. Kommen Pakete schneller an, als srcds sie abholt, läuft zusätzlich der Empfangspuffer über, und das sieht für die Spieler aus wie Paketverlust auf einer freien Leitung:

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

Die Datei legen Sie unter /etc/sysctl.d/ ab und aktivieren sie mit sysctl -p. Ob die Werte überhaupt 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.

10. Messen, damit Sie im Angriff nicht raten müssen

Im Angriff ist die wichtigste Frage: Wie viel kommt an, auf welchem Port, und ist es Abfrage- oder Spielverkehr. Vier Befehle genügen:

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

Den ersten Befehl führen Sie zweimal im Abstand von zehn Sekunden aus, dann haben Sie eine Rate statt eines Absolutwerts. Die letzte Zeile zeigt ausschließlich die verbindungslosen Pakete, also genau die Klasse, die eine Abfrageflut missbraucht; läuft der Zähler in Sekunden voll, während kaum jemand verbunden ist, haben Sie Ihre Antwort. Halten Sie die Mitschrift kurz, weil sie unter Last selbst Rechenzeit kostet. Wie Sie die Werte einordnen, steht im Beitrag DDoS-Angriff am Server erkennen.

Der wichtigste Schritt ist allerdings 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 vollem Versus-Server.

Wo diese Maßnahmen aufhören

Jetzt der ehrliche Teil. Alles bisher Beschriebene wirkt erst, wenn die Pakete auf Ihrer Netzwerkkarte angekommen sind. 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 typischer Gameserver hängt an 1 Gbit/s, das entspricht 125 Megabyte pro Sekunde. Bei kleinstmöglicher Paketgröße trägt diese 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. Ein normaler Serverkernel verarbeitet je nach Prozessor und Netzwerkkarte einige hunderttausend Pakete pro Sekunde, bevor er anfängt zu verwerfen. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Server also lahmlegen, weil die Rechenzeit für das Verwerfen draufgeht. Betreiber erleben das als "die Auslastung war doch gar nicht hoch, trotzdem war alles weg".

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.

Deshalb sind die zwei verbreiteten Notbremsen unbefriedigend. Nullrouting (Blackholing) nimmt die angegriffene IP-Adresse aus dem Netz und beendet zwar den Angriff, aber auch Ihren Server: Für Ihre Spieler ist das Ergebnis identisch mit einem erfolgreichen Angriff. Eine reaktive Umleitung kostet in der Umschaltzeit genau die Minuten, in denen die Kampagne 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 inklusive ist

Der DDoS-Schutz von KernelHost ist zweistufig aufgebaut und permanent 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, lange bevor sie das Rechenzentrum erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main. Direkt vor dem Server werden protokollspezifische Muster auf Layer 3 bis 7 erkannt und verworfen, Paket für Paket.

Zwei Eigenschaften 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-Adresse bleibt im Netz, verworfen werden nur die schädlichen Pakete. Der Schutz ist in jedem Serverpaket ohne Aufpreis enthalten, ohne separates Schutzpaket und ohne Einrichtung, und er ist ab der Bereitstellung aktiv. Die Server stehen im maincubes Premium Datacenter in Frankfurt am Main. 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 nicht gelegentlich, sondern gezielt und über Wochen angegriffen, mit wechselnden Mustern und immer genau zum verabredeten Kampagnenabend. Für diese Fälle 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:

• 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, also 27015/UDP anders als der Webserver, der Ihre Kampagnen ausliefert.
• Änderungen greifen in Echtzeit, ohne Ticket und ohne Wartezeit. Sie können also während eines laufenden Angriffs nachjustieren.
• Ein Schutzprofil passend zum jeweiligen Spiel. Für Left 4 Dead 2 und die übrigen 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

Für die meisten Left-4-Dead-2-Projekte 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 ist aus der Lobby-Suche 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. Ist der Port erreichbar und der Server trotzdem unsichtbar, prüfen Sie sv_search_key, sv_steamgroup_exclusive, sv_lan 0 und sv_region 255, und ob der Start versehentlich mit -nomaster erfolgt ist.

In der Serverkonsole steht laufend "Invalid split packet length": Das ist kein volumetrischer Angriff, sondern ein fehlerhaft zusammengesetztes Netzwerkpaket, das in schneller Folge geschickt wird. Der Verkehr bleibt dabei winzig, der Server lagt trotzdem. Prüfen Sie zuerst, ob die Bandbreite überhaupt auffällig ist, und bringen Sie Serverbinary und Erweiterungen auf Stand. Bandbreite hilft hier nichts.

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: Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht, weil sie hinter den UFW-Ketten steht oder nach dem letzten Neustart verloren ging. Steigen sie und es ändert sich nichts, ist die Leitung vor dem Server gesättigt, und ab da hilft nur Filterung im Netz.

Der Server nimmt keine Spieler mehr an, obwohl Plätze frei sind: Meist hängt eine Lobby-Reservierung. Entweder Sie betreiben den Server konsequent über das Matchmaking, oder Sie setzen sv_force_unreserved 1 und lassen Ihre Spieler über den Serverbrowser beitreten. Bei mehr als vier Koop-Plätzen mit L4DToolZ ist diese Einstellung ohnehin Pflicht.

Neue Spieler laden ewig und die Leitung ist dabei voll: Dann liefert srcds die Kampagnendateien selbst über den Spielport aus. Setzen Sie sv_downloadurl auf einen Webserver und legen Sie die Dateien dort als bzip2-Archiv ab, oder verweisen Sie Ihre Spieler auf den Steam-Workshop.

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, und ein vergessener DNS-Eintrag oder ein Discord-Bot mit Statusanzeige tut den Rest. Ein IP-Wechsel verschafft Stunden, keine Lösung.

Auf dem Server laufen fremde Administrationsbefehle: Kein DDoS-Angriff, sondern ein kompromittierter RCON-Zugang. Passwort sofort ändern und den TCP-Anteil von 27015 auf die eigene Adresse einschränken.

Kurz zusammengefasst

• Ein Left-4-Dead-2-Server braucht genau einen offenen Port nach außen: 27015/UDP. Spielverkehr und A2S-Abfrage teilen ihn sich, einen getrennten Query-Port gibt es nicht.
• 27015/TCP ist RCON und gehört ausschließlich auf die eigene Adresse. Wer RCON nicht braucht, lässt rcon_password leer.
• Das Lobby-System ist der wirksamste kostenlose Zugangsfilter, den das Spiel kennt: sv_allow_lobby_connect_only 1, ein eigener sv_search_key und sv_steamgroup_exclusive 2 sperren alles aus, was nicht über das Matchmaking kommt. Es filtert Beitritte, nicht Pakete.
• Custom-Kampagnen gehören in den Steam-Workshop oder hinter sv_downloadurl, nie über den Spielport. Sonst zahlt jeder abgebrochene Verbindungsversuch mit Ihrer Bandbreite.
• Ratenbegrenzung muss zwischen verbindungslosen Paketen (beginnend mit 0xffffffff) und Spielverkehr unterscheiden. Eine grobe Regel auf 27015/UDP wirft Ihre eigenen Spieler heraus.
• Bei 64 Byte großen Paketen trägt eine 1-Gbit/s-Leitung rund 1,49 Millionen Pakete pro Sekunde. Darüber entscheidet ausschließlich das Netz vor dem Server, keine Einstellung auf dem Server selbst.
• Bei KernelHost filtern 17 Tbps globales Scrubbing und eine Arbor-Echtzeitfilterung mit 3,2 Tbps in Frankfurt am Main dauerhaft und ohne Aufpreis, ohne Nullrouting und ohne Umschaltzeit.

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, damit unser Team die Filterregeln für Ihre IP-Adresse nachjustiert. 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 (Spieler fliegen heraus, Server nicht in der Lobby-Suche, hoher Ping). Das erspart eine Rückfragerunde, und die zählt, wenn gerade eine Kampagne läuft.

Hosten Sie woanders und werden regelmäßig beschossen, ist der Umzug zu KernelHost der kürzere Weg als jede weitere Regel auf einem Server, dessen Leitung vorher endet. Der Dauerschutz ist Teil jedes Serverpakets, nicht ein Zusatz, den Sie erst im Ernstfall buchen.