Unturned-Server vor DDoS-Angriffen schützen

Ein Unturned-Server, der abends für ein paar Minuten aus der Serverliste verschwindet und dabei alle Spieler mit einer Zeitüberschreitung hinauswirft, hat selten ein Hardwareproblem. Meistens läuft ein Angriff, und zwar genau dann, wenn am meisten los ist. Dieser Beitrag zeigt zuerst, was Sie ohne Zusatzkosten selbst absichern können, danach, wo diese Maßnahmen technisch aufhören, und zum Schluss, was dann im Netz vor dem Server passieren muss.

Alle Angaben beziehen sich auf den Unturned Dedicated Server (U3DS, SteamCMD-App-ID 1110390) 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 an der Konfiguration und starten Sie den Server nicht neu: Sichern Sie die Messwerte (Abschnitt 10), nach dem Angriff sind sie weg.

Warum ausgerechnet Unturned-Server angegriffen werden

Unturned-Server werden angegriffen, weil ihre Adresse öffentlich ist, der Spielverkehr über UDP läuft und ein Angriff den Auslöser weder Können noch nennenswertes Geld kostet. Alle drei Punkte gelten hier stärker als bei den meisten anderen Spielen.

Ein öffentlicher Unturned-Server veröffentlicht seine IP-Adresse von sich aus. Er muss es tun, sonst würde ihn niemand finden: Der Steam-Serverbrowser fragt ihn direkt an, und Drittlisten wie unturned-servers.net oder BattleMetrics tragen IP-Adresse und Port im Klartext. unturned-servers.net prüft dafür nach eigener Angabe alle fünf Minuten, ob der Server auf dem Serverport UDP-Verbindungen annimmt. Für einen Angreifer ist das kein Aufwand, sondern ein Formular.

Dazu kommt die Spielerschaft. Unturned ist kostenlos, die Einstiegshürde liegt bei null, und zwischen Roleplay- und Survival-Projekten gibt es echte Konkurrenz um dieselben Spieler. Ein gebannter Spieler, ein gekränkter Ex-Admin oder ein Nachbarprojekt braucht keinen Zugriff auf Ihren Server, um ihn für eine Stunde unbrauchbar zu machen. Was ein DDoS-Angriff technisch ist und warum gefälschte Absenderadressen ihn so schwer zurückverfolgbar machen, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es tatsächlich geht

Ein Unturned-Server belegt genau zwei aufeinanderfolgende UDP-Ports: den in der Commands.dat gesetzten Wert und diesen Wert plus eins. In der Voreinstellung sind das 27015 und 27016. Die offizielle Dokumentation von Smartly Dressed Games beschreibt die Aufteilung so: Der erste Port trägt die Abfragen der Serverliste, der zweite den Spielverkehr. Gesetzt wird nur der erste, der zweite ergibt sich automatisch.

Name Mein Unturned Server
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

Die Commands.dat liegt unter U3DS/Servers/<Instanz>/Server/Commands.dat. Ihr Format ist eigenwillig und eine häufige Fehlerquelle: ein Befehl je Zeile, kein Gleichheitszeichen, Wert durch ein Leerzeichen getrennt, und die Befehle sind groß- und kleinschreibungsempfindlich. Zeilen, die mit // beginnen, sind Kommentare.

Der wichtigste Punkt für die Firewall lautet: Port 27017 wird seit Version 3.21.30.0 vom 21. November 2021 nicht mehr gebraucht. Davor verlangte ein Unturned-Server drei Ports, weil die Steam-Abfrage auf Port plus zwei lag. Mit diesem Update teilt sich die Abfrage den Port mit dem Server selbst, und der dritte Port entfiel. Router-Anleitungen, Hoster-Wikis und Forenbeiträge nennen 27017 trotzdem bis heute. Ein offener 27017 bringt Ihnen keinen Vorteil mehr, er ist reine Angriffsfläche.

Ebenfalls wichtig: Unturned hat keinen eingebauten RCON-Port. Die offizielle Dokumentation kennt nur Konsoleneingabe und Konsolenausgabe, die sich über die Schnittstelle ICommandInputOutput ersetzen lassen. Jede Fernsteuerung, die Sie auf einem Unturned-Server sehen, stammt aus einem Plugin und bringt einen eigenen TCP-Port mit. Diesen Port müssen Sie selbst finden und selbst beschränken, denn niemand hat ihn für Sie abgesichert.

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

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

1. Bestandsaufnahme: was lauscht wirklich

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

ss -lnup
ss -lntp

Der erste Befehl zeigt die lauschenden UDP-Sockets, der zweite die TCP-Sockets. Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:27015 und [::]:27015 bedeuten "aus dem ganzen Internet erreichbar", 127.0.0.1:3306 bedeutet "nur lokal" und braucht keine Firewall-Regel. Neben dem Spiel finden sich dort häufig ein RCON-Plugin, ein Webpanel, eine Datenbank und ein alter Testserver auf 27017, den niemand mehr benutzt. Die Sicht des Angreifers liefert ein Portscan von außen, für Unturned ausdrücklich mit UDP:

nmap -Pn -sU -p 27000-27050 IHRE.SERVER.IP.ADRESSE
nmap -Pn -p- --min-rate 1000 IHRE.SERVER.IP.ADRESSE

2. Nur 27015 und 27016 offen lassen

Für Unturned genügen zwei UDP-Freigaben nach außen. Für das Spiel selbst wird kein einziger TCP-Port gebraucht: Die offizielle Dokumentation verlangt für beide Ports ausdrücklich UDP, und die Netzwerkschicht des Spiels (Steam Networking Sockets, seit einem Update die Voreinstellung) arbeitet ausschließlich über UDP. Wer zusätzlich TCP freigibt, folgt einer veralteten Anleitung.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned Abfrage'
ufw allow 27016/udp comment 'Unturned Spiel'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Die Reihenfolge ist wichtig, sonst sperren Sie sich selbst aus. Die vollständige Anleitung samt Rettungsweg steht unter UFW-Firewall einrichten, ohne sich selbst auszusperren. Betreiben Sie mehrere Instanzen, halten Sie den empfohlenen Abstand von zwei ein (27015, 27017, 27019) und geben Sie je Instanz genau die zwei Ports frei, die sie wirklich belegt.

Ein Webpanel, eine Datenbank oder ein RCON-Plugin gehören nicht ins offene Netz. Beschränken Sie den jeweiligen Port mit ufw allow from 203.0.113.10 to any port 8080 proto tcp auf Ihre eigene Adresse, oder erreichen Sie die Oberfläche über eine lokale SSH-Weiterleitung mit ssh -N -L 8080:127.0.0.1:8080 root@IHRE.SERVER.IP.ADRESSE. Die Datenbank bindet man auf 127.0.0.1.

3. Den Abfrageport absichern, ohne aus der Serverliste zu fliegen

Der Abfrageport ist der empfindlichste Punkt eines Unturned-Servers. Über ihn beantwortet der Server die Steam-Abfragen A2S_INFO, A2S_PLAYERS und A2S_RULES. Sperren Sie ihn vollständig, verschwindet der Server aus jeder Serverliste, auch wenn er einwandfrei läuft.

Eine A2S-Antwort ist deutlich größer als die Anfrage. Das US-CERT führt das Steam-Protokoll in seiner Übersicht zu UDP-Verstärkungsangriffen (TA14-017A) mit einem Bandbreiten-Verstärkungsfaktor von 5,5. Konkret heißt das: Ein Angreifer schickt Abfragen mit gefälschter Absenderadresse an fremde Gameserver und lenkt die rund fünfeinhalbfach größeren Antworten auf sein eigentliches Ziel. Ihr Server ist dann nicht das Opfer, sondern der Verstärker gegen einen Dritten. In der Gegenrichtung reicht ein Abfrage-Flood aus, um den Server aus dem Serverbrowser verschwinden zu lassen, ohne dass ein einziger Spieler fliegt. Betreiber melden genau das: Der Server läuft, die Spieler darauf merken nichts, aber er ist nicht mehr auffindbar.

Gegen kleine Abfrage-Floods hilft eine Obergrenze je Quelladresse. Legitime Abfragen kommen selten: Der Steam-Browser fragt einmal pro Anzeige, Statusdienste alle paar Minuten.

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

Die zweite Zahl leitet sich direkt aus dem Spiel ab: Unturned begrenzt einen Spieler ab Werk auf 50 Pakete je Sekunde (Max_Packets_Per_Second). 300 Pakete je Sekunde und Quelladresse lassen also einem einzelnen Anschluss reichlich Luft, selbst wenn mehrere Spieler hinter derselben Adresse sitzen. Beide Werte sind Startwerte, keine Wahrheiten. Messen Sie erst eine Woche Normalbetrieb, sonst werfen Sie Ihre eigenen Spieler heraus.

Reine iptables-Regeln sind nach einem Neustart weg. Unter Debian und Ubuntu sichert man sie mit apt-get install -y iptables-persistent und netfilter-persistent save. Unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden.

Dazu kommt eine Gewohnheit, die nichts kostet: Wenn Ihre Webseite oder Ihr Discord-Bot den Spielerstand anzeigt, fragen Sie den Server nicht vom Besucher aus ab, sondern speichern Sie das Ergebnis in festen Abständen zwischen. Eine viel besuchte Statusseite erzeugt sonst eine Abfrage pro Besucher statt einer pro Intervall.

4. Die eingebauten Grenzen in der Config.json setzen

Unturned bringt in der Config.json im selben Server-Ordner wie die Commands.dat einen Abschnitt mit, der für die Abwehr wichtiger ist, als sein Name vermuten lässt. Die Voreinstellungen lauten:

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

Max_Packets_Per_Second begrenzt einen verbundenen Spieler auf 50 Pakete je Sekunde. Join_Rate_Limit_Window_Seconds und Rate_Limit_Kick_Threshold werfen eine Verbindung hinaus, die innerhalb von 40 Sekunden mehr als zehn Mal über die Grenze geht. VAC_Secure und BattlEye_Secure verlangen beide Anti-Cheat-Systeme auf der Spielerseite und halten damit den Großteil der Wegwerf-Clients fern.

Eines muss dabei klar sein: Diese Grenzen wirken gegen Clients, die tatsächlich beitreten oder es versuchen. Gegen einen Flood mit gefälschten Absenderadressen wirken sie nicht, weil dort nie eine Sitzung entsteht. Sie sind trotzdem wichtig, weil sie den häufigsten Einzelfall abfangen: einen einzelnen manipulierten Client, der den Server allein überlastet. Max_Ping_Milliseconds auf 750 zu belassen ist sinnvoll; niedriger eingestellt wirft der Server bei jedem kurzen Netzruckler halbe Runden heraus.

5. Die Verbindungsverfolgung entlasten

Dieser Punkt wird fast immer übersehen und erklärt Ausfälle, die wie ein Volumenangriff aussehen, aber keiner sind. Der Kernel legt auch für UDP-Verkehr Einträge in der Verbindungsverfolgung (conntrack) an, und bei gefälschten Absenderadressen bedeutet jede neue Adresse einen neuen Eintrag. Ist die Tabelle voll, verwirft der Kernel Pakete ohne Unterschied: Der Angriff und Ihre Spieler fliegen gemeinsam heraus. Im Systemprotokoll steht dann nf_conntrack: table full, dropping packet.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack

Der wirksamste Schritt ist, den Unturned-Verkehr gar nicht erst verfolgen zu lassen. Das Spiel verwaltet seine Sitzungen selbst und braucht keine Zustandsverfolgung im Kernel:

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

Achten Sie darauf, dass Ihre Freigaben für diese beiden Ports dann nicht mehr über ESTABLISHED,RELATED laufen dürfen, sondern als eigene Annahmeregeln stehen müssen. Erst danach lohnt es sich, nf_conntrack_max zu erhöhen. Wer zuerst die Tabelle vergrößert, verschiebt das Problem nur um Minuten und verbraucht dafür Arbeitsspeicher.

Kommen Pakete schneller an, als der Serverprozess sie abholt, läuft zusätzlich der Empfangspuffer des Sockets über. Für die Spieler sieht das aus wie Paketverlust, obwohl die Leitung frei ist:

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

Legen Sie die Werte unter /etc/sysctl.d/ ab und aktivieren Sie sie mit sysctl --system. Ob sie nötig sind, verrät der Kernel: Steigt UdpRcvbufErrors in nstat -az an oder steht in ss -lunp dauerhaft etwas in der Empfangswarteschlange, dann greifen sie. Bleiben beide bei null, ändert die Anpassung nichts. Das ist Reserve, kein Schutz.

6. Beitritts-Flood, Warteschlange und Whitelist

Ein Beitritts-Flood ist ein Angriff, bei dem der Angreifer den regulären Beitrittsweg nutzt, um Slots und Rechenzeit zu verbrauchen, statt die Leitung zu füllen. Unturned bringt dagegen vier Werkzeuge mit, die alle in der Commands.dat stehen:

• Queue_Size 32 setzt die Warteschlange. Voreinstellung sind 8 Plätze, das Maximum ist 64. Eine zu große Warteschlange hilft einem Angreifer, eine zu kleine wirft echte Spieler bei jedem Neustart ab.
• Whitelisted schaltet den Server auf Zugangsliste um. Eingetragen wird über die Konsole mit permit <SteamID64>, entfernt mit unpermit <SteamID64>.
• Password IhrPasswort schließt alles aus, was die Adresse nur aus einer Liste hat.
• Filter weist Spieler mit unzulässigen Zeichen im Namen ab, MaxPlayers 24 hält die Slotzahl bei dem, was die Hardware wirklich trägt.

Eine Whitelist 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. RocketMod, OpenMod und die Plugin-Seite

Unturned hat zwei verbreitete Plugin-Plattformen, und beide laufen im selben Prozess wie der Server. RocketMod ist die ältere: Die ursprünglichen Betreuer haben die Pflege am 20. Dezember 2019 eingestellt und den Quellcode unter die MIT-Lizenz gestellt. Smartly Dressed Games pflegt seitdem den Ableger Legally Distinct Missile (LDM), der beim Dedicated Server bereits mitgeliefert wird: Man kopiert Rocket.Unturned aus dem Ordner Extras in den Ordner Modules. Die Entwickler empfehlen den Ableger ausdrücklich, weil er alte Rocket-Probleme wie Threading-Fehler und Teleport-Exploits behebt.

OpenMod ist der neuere Nachfolger, entwickelt von einem der ursprünglichen Rocket-Betreuer. Er ersetzt RocketMod nicht, sondern läuft daneben und kann bestehende Rocket-Plugins über eine Integration mitverwenden. Für die Abwehr heißt das zweierlei.

Erstens: Jedes Plugin ist Angriffsfläche im Hauptprozess. Ein Plugin, das bei jeder Chatnachricht oder bei jedem Spielereignis eine Datenbankabfrage auslöst, ist ein selbstgebauter Denial of Service. Ein einzelner Spieler, der ein Ereignis in einer Schleife auslöst, legt den Server dann ohne jede Bandbreite lahm. Halten Sie die Plugin-Liste kurz, bevorzugen Sie quelloffene Plugins und messen Sie die Bildrate des Servers nach jeder Erweiterung.

Zweitens: Da Unturned keinen eigenen RCON-Port hat, stammt jede Fernsteuerung aus einem Plugin. Prüfen Sie nach der Installation mit ss -lntp, welchen TCP-Port es geöffnet hat, und beschränken Sie ihn auf Ihre eigene Adresse. Ein offener Fernsteuerungsport mit schwachem Passwort ist kein DDoS-Problem, sondern ein Übernahmeproblem.

8. Workshop-Inhalte und der Beitrittsvorgang

Workshop-Inhalte machen den Beitritt teuer, und das wirkt sich direkt auf die Angreifbarkeit aus. Gesteuert wird das über die WorkshopDownloadConfig.json im selben Server-Ordner:

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

In File_IDs stehen die Workshop-Kennungen der Karten und Mods. Beim Start lädt der Server sie samt Abhängigkeiten herunter, und jeder Spieler lädt sie beim Verbinden automatisch nach. Drei Folgen sollten Sie kennen. Erstens dauert der Beitritt bei großen Modlisten lange, und nach einem Angriff kommen alle Spieler gleichzeitig zurück, was den Server ein zweites Mal belastet. Zweitens hält Should_Monitor_Updates den Server an, sobald eine Workshop-Datei aktualisiert wird: Der voreingestellte Shutdown_Update_Detected_Timer von 600 Sekunden führt dann zu einem Neustart, den Betreiber im Angriffsfall regelmäßig für einen Angriffserfolg halten. Drittens ist jede Mod fremder Code auf Ihrem Server.

Praktisch heißt das: Halten Sie die Liste so kurz wie möglich, prüfen Sie nach jedem unerwarteten Neustart zuerst das Serverprotokoll auf die Meldung zur Workshop-Aktualisierung, und stellen Sie Should_Monitor_Updates nur dann ab, wenn Sie Aktualisierungen selbst einplanen.

9. Serverliste, Server-Code und die Fake-IP-Funktion

Ihre IP-Adresse lässt sich nicht geheim halten, solange der Server öffentlich gelistet ist. Jeder Spieler, der einmal verbunden war, kennt sie, und die Drittlisten veröffentlichen sie ohnehin. Zwei Gewohnheiten helfen trotzdem: Veröffentlichen Sie die rohe Adresse nirgends selbst, und verbinden Sie Ihre Spieler über einen Hostnamen, damit ein Adresswechsel nicht jeden Verweis bricht. Der Klassiker ist der vergessene A-Eintrag auf die alte Adresse, der jeden Wechsel wirkungslos macht.

Für den Betrieb im Internet brauchen Sie ohnehin ein Game Server Login Token (GSLT) aus der Steam-Serververwaltung zur App-Kennung 304930. Es sorgt zusätzlich dafür, dass der Server-Code Ihres Servers über Neustarts hinweg gleich bleibt, statt bei jedem Start neu erzeugt zu werden.

Unturned bietet außerdem eine Fake-IP-Funktion an. Sie wird mit "Use_FakeIP": true in der Config.json eingeschaltet, und der Konsolenbefehl CopyFakeIP liefert die Adresse, die Sie dann veröffentlichen. Der Verkehr läuft danach über das Relaisnetz Steam Datagram Relay, die vergebenen Adressen liegen im Bereich 169.254.0.0 bis 169.254.255.255, und die echte Adresse des Servers wird den Spielern nicht mehr gezeigt. Valve beschreibt den Verkehr als authentifiziert, verschlüsselt und ratenbegrenzt.

Der Preis dafür ist hoch und wird selten dazugesagt: Adresse und Port wechseln bei jedem Neustart, ein Domainname lässt sich ohne eigene Skripte nicht darauf richten, und die Steam-Listen "Favoriten" und "Verlauf" funktionieren damit nicht, sondern nur die Lesezeichenfunktion. Vor allem aber schützt die Funktion nur den Spielweg. Ihr Server behält seine echte Adresse, und SSH, Webpanel, Datenbank und Webseite bleiben darüber erreichbar. Wer die Adresse aus einem alten DNS-Eintrag, einer Statusseite oder von einer früheren Verbindung kennt, greift sie weiterhin direkt an. Die Fake-IP-Funktion ersetzt also keine Filterung im Netz vor dem Server, sie verkleinert nur die Zahl der Leute, die Ihre Adresse überhaupt kennen.

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

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 je 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 portrange 27015-27016 -c 200 -q

Bei tcpdump gilt: immer mit -c begrenzen, ein Mitschnitt unter Volllast belastet einen ohnehin überlasteten Server zusätzlich. Wie Sie die Werte auswerten und einen Angriff von einem Softwarefehler unterscheiden, steht in DDoS-Angriff am Server erkennen.

Wo diese Maßnahmen aufhören

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 typischer Gameserver hängt an 1 Gbit/s, das sind 125 Megabyte je Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Der normale Betrieb bleibt weit darunter: Bei 24 Spielern und den ab Werk erlaubten 50 Paketen je Spieler und Sekunde kommen rund 1.200 Pakete je Sekunde an. Ein Booter-Dienst erzeugt ohne jede Vorbereitung ein Vielfaches davon.

Die zweite Größe ist die Paketrate, und sie schlägt fast immer 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 je Sekunde. Ein normaler Serverkernel verarbeitet je nach CPU und Netzwerkkarte einige hunderttausend davon, bevor er anfängt zu verwerfen. Ein Angriff, der Ihre Leitung nicht einmal zu einem Drittel füllt, kann Ihren Server also trotzdem lahmlegen, weil die Rechenzeit für das Verwerfen draufgeht. 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 Angriff mit über 473,4 Gbit/s bei über 41,5 Millionen Paketen je 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. Der Standort ist Frankfurt am Main. Welche Spiele und Protokolle abgedeckt sind, listet Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft beschossene Projekte

Manche Projekte werden nicht gelegentlich, sondern gezielt und über Wochen angegriffen. Dafür gibt es die Advanced DDoS Protection ab 50,00 EUR im Monat, PrePaid, ohne Mindestlaufzeit und ohne Einrichtungsgebühr. 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 getrennt ein, was auf 27015 UDP erlaubt ist (die Abfragen) und was auf 27016 UDP (der Spielverkehr), ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren, etwa die Abfragen enger fassen und den Spielverkehr unangetastet lassen.
• Schutzprofil passend zum Spiel, ebenso für modifizierte und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports, also auch für ein Plugin mit eigenem Port.

Die beiden Stufen im Vergleich

Für die meisten Unturned-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

"Meine Anleitung sagt, ich muss 27015 bis 27017 freigeben": Die Anleitung ist älter als November 2021. Seit Version 3.21.30.0 braucht ein Unturned-Server nur noch zwei Ports, weil die Steam-Abfrage nicht mehr auf Port plus zwei liegt. Schließen Sie 27017, es sei denn, dort läuft eine zweite Instanz.

"Der Server läuft, aber er steht in keiner Serverliste mehr": Das ist das typische Bild eines Abfrage-Floods oder einer zu scharfen eigenen Regel auf 27015 UDP. Prüfen Sie mit iptables -L INPUT -n -v, ob Ihre eigene Regel Treffer zählt. Steigen die Zähler stark, filtern Sie gerade Ihre eigenen Listeneinträge weg. Sperren Sie 27015 nie vollständig.

"Alle Spieler fliegen gleichzeitig mit Zeitüberschreitung": Sehen Sie zuerst nach, ob die Verbindungsverfolgung übergelaufen ist (dmesg -T | grep -i conntrack). Ist die Tabelle voll, verwirft der Kernel unterschiedslos. Timeout_Game_Seconds steht ab Werk auf 30 Sekunden: Wer innerhalb dieser Zeit zurückkommt, behält seinen Platz.

"Der Server startet mitten im Betrieb neu": Das ist selten ein Angriff. Prüfen Sie das Protokoll auf die Meldung zur erkannten Workshop-Aktualisierung. Should_Monitor_Updates fährt den Server nach dem voreingestellten Zeitraum von 600 Sekunden herunter.

"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 einer Serverliste, einem Discord-Bot oder einem alten DNS-Eintrag. Ein Adresswechsel ist Zeitgewinn, keine Lösung.

"Ich habe die Fake-IP-Funktion eingeschaltet und werde trotzdem angegriffen": Sie verbirgt die Adresse vor neuen Spielern, nimmt sie dem Server aber nicht weg. Wer sie aus einem alten Listeneintrag, einer Statusseite oder einer früheren Verbindung kennt, erreicht Ihren Server weiterhin direkt, ebenso SSH und jedes Webpanel darauf.

"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 Unturned-Server braucht genau zwei offene UDP-Ports: den in der Commands.dat gesetzten Port (Voreinstellung 27015) und diesen Wert plus eins (27016). TCP braucht das Spiel selbst nicht.
• Port 27017 ist seit Version 3.21.30.0 vom 21. November 2021 überflüssig, weil die Steam-Abfrage nicht mehr auf Port plus zwei liegt. Wer ihn noch offen hat, folgt einer veralteten Anleitung.
• Unturned hat keinen eingebauten RCON-Port. Jede Fernsteuerung kommt aus einem Plugin, bringt einen eigenen TCP-Port mit und muss von Ihnen selbst beschränkt werden.
• Der Abfrageport 27015 ist der empfindlichste Punkt: Ein Abfrage-Flood macht den Server in der Serverliste unsichtbar, ohne einen Spieler zu treffen, und das Steam-Protokoll hat laut US-CERT TA14-017A einen Verstärkungsfaktor von 5,5.
• Die Grenzen in der Config.json (Max_Packets_Per_Second 50,0, Rate_Limit_Kick_Threshold 10 je 40 Sekunden) wirken nur gegen Clients, die wirklich beitreten, nicht gegen gefälschte Absenderadressen.
• Eine 1-Gbit/s-Leitung ist bei 125 Megabyte je Sekunde voll, bei 64 Byte großen Paketen bereits bei rund 1,49 Millionen Paketen je Sekunde. Normalbetrieb mit 24 Spielern liegt bei rund 1.200 Paketen je Sekunde. Alles darüber entscheidet das Netz vor dem Server, nicht Ihre Firewall.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket ohne Aufpreis enthalten und ab der Bereitstellung aktiv, ohne Nullrouting. Wer die Filterregeln selbst steuern will, nimmt die Advanced DDoS Protection ab 50,00 EUR im Monat dazu.

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