ARK-Server vor DDoS-Angriffen schützen

Ein ARK-Cluster fällt selten zu einem zufälligen Zeitpunkt aus. Wer PvP-Server betreibt, kennt das Muster: Kurz bevor eine fremde Basis fällt, wird der Server unerreichbar, alle Spieler fliegen heraus, und wenn er zurückkommt, ist der Raid gelaufen. Dieser Beitrag zeigt zuerst, was Sie auf dem Server selbst einstellen können, danach, wo diese Maßnahmen technisch enden, und zum Schluss, was KernelHost davor stellt.

Warum ausgerechnet ARK so gezielt angegriffen wird

Bei den meisten Spielen ist ein Serverausfall ärgerlich. Bei ARK: Survival Evolved und ARK: Survival Ascended ist er ein Spielzug. Verluste im Spiel sind dauerhaft, ein Raid-Fenster dauert wenige Minuten, und jeder Offline-Raid-Schutz wirkt nur so lange, wie der Server erreichbar ist. Wer die Verteidiger zehn Minuten aus dem Spiel nimmt, gewinnt Ressourcen und Kreaturen. Der Angriff hat damit einen konkreten Gewinn und einen geplanten Zeitpunkt, und er wiederholt sich, sobald er funktioniert hat.

Dazu kommt die Bauweise eines Clusters. Mehrere Karten laufen üblicherweise auf derselben Maschine hinter derselben IP-Adresse. Ein Angriff trifft deshalb nicht einen Server, sondern The Island, Ragnarok, Aberration und den Transfer dazwischen gleichzeitig. Spieler, die genau im Transfer hängen bleiben, verlieren im ungünstigsten Fall Charakter und Gegenstände. Was bei einem DDoS-Angriff technisch passiert, beschreibt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es geht

ARK überträgt den Spielverkehr vollständig über UDP. Das ist der Grund, warum viele Firewall-Anleitungen hier nicht helfen: Sie öffnen TCP.

Survival Evolved belegt zusätzlich den Port direkt über dem Spielport, weil die Engine dort einen zweiten UDP-Socket öffnet. Survival Ascended braucht diesen zweiten Port nicht mehr. Der Abfrageport beantwortet Statusanfragen im Steam-Format (Servername, Karte, Spielerzahl, Spielzeit) und ist der interessanteste Port für Angreifer.

In einem Cluster vergibt man die Ports in Zweierschritten, damit der zweite Socket nicht mit der nächsten Instanz kollidiert: 7777 und 7778 für die erste Karte, 7779 und 7780 für die zweite, dazu 27015 und 27016 als Abfrageports.

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

Die folgenden Schritte kosten nichts und wirken gegen die häufigsten Fälle: kleine gezielte Fluten aus wenigen Quellen, missbrauchte Abfrageports und Versuche, über RCON die Kontrolle zu übernehmen. Sie lohnen auch dann, wenn davor bereits ein Netzfilter arbeitet.

1. Nur öffnen, was der Cluster wirklich braucht

Ein ARK-Host hat schnell mehr offene Ports als gedacht: Panel, Datenbank, ein Webserver für die Karte, dazu die Spielinstanzen. Jeder davon ist ein Ziel für Pakete. Das folgende nftables-Regelwerk für /etc/nftables.conf lässt durch, was ein Cluster mit zwei Karten braucht, und verwirft den Rest.

#!/usr/sbin/nft -f

flush ruleset

table inet ark {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set queryflood {
        type ipv4_addr
        size 65535
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip saddr @adminips tcp dport { 22, 27020 } accept

        udp dport { 7777-7780 } accept

        udp dport { 27015-27016 } add @queryflood { ip saddr limit rate over 10/second burst 20 packets } drop
        udp dport { 27015-27016 } accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Tragen Sie unter adminips Ihre feste IP-Adresse ein, bevor Sie laden, sonst sperren Sie sich aus SSH aus.

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset

nft -c prüft nur die Syntax und ändert nichts. Erst der zweite Befehl lädt das Regelwerk und macht es neustartfest. Wer lieber mit UFW arbeitet, findet den Weg unter UFW-Firewall einrichten. Beachten Sie: flush ruleset löscht auch die Regeln von UFW und Docker. Läuft eines von beiden, lassen Sie diese Zeile weg.

2. Den Abfrageport begrenzen, statt ihn zu schließen

Der Abfrageport ist der einzige Port, an dem Ihr Server jedem Fremden auf eine winzige Anfrage eine deutlich größere Antwort schickt. Daraus folgen zwei Probleme. Erstens lässt sich Ihr Server als Verstärker missbrauchen: Der Angreifer fälscht die Absenderadresse, Ihr Server antwortet einem fremden Opfer, und Ihre Leitung trägt den ausgehenden Verkehr. Zweitens kostet jede Antwort Rechenzeit in genau dem Prozess, der auch das Spiel berechnet. Eine Flut auf 27015 zeigt sich deshalb oft als Ruckeln und nicht als Verbindungsabbruch.

Den Port zu schließen ist keine Lösung, denn dann verschwindet der Server aus der Serverliste. Die Regel oben begrenzt stattdessen pro Quelladresse: Zehn Abfragen pro Sekunde mit einem Puffer von zwanzig Paketen reichen für Spieler und Monitoring, eine Quelle mit tausenden Anfragen pro Sekunde wird verworfen. Welche Adressen gerade begrenzt werden, zeigt:

nft list set inet ark queryflood

3. RCON aus dem Internet nehmen

RCON gibt volle Kontrolle: Wer das Passwort hat, entfernt Spieler, beendet den Server und greift in die Welt ein. Der Port ist TCP, das Passwort steht im Klartext in der Konfiguration, und die Anmeldung lässt sich beliebig oft versuchen. Deshalb steht er im Regelwerk oben nur für die Admin-Adresse offen.

[ServerSettings]
RCONEnabled=True
RCONPort=27020
ServerAdminPassword=<langes Zufallspasswort>

Die Datei GameUserSettings.ini liegt unter ShooterGame/Saved/Config/ im Serververzeichnis. Ein brauchbares Passwort erzeugt:

openssl rand -base64 24

Nutzt ein Webpanel auf derselben Maschine RCON, genügt der Zugriff über 127.0.0.1, der Port bleibt von außen zu. Läuft das Panel woanders, gehört dessen Adresse in adminips und sonst nirgendwohin.

4. Die Verbindungsverfolgung entlasten

Ein UDP-Flood bringt einen Linux-Server oft nicht über die Bandbreite um, sondern über die Verbindungsverfolgung. Der Kernel legt für jedes eingehende UDP-Paket einen Eintrag an, die Tabelle läuft voll, und danach verwirft er auch Pakete echter Spieler, erkennbar an nf_conntrack: table full, dropping packet im Systemprotokoll. Für Spielverkehr nützt diese Verfolgung nichts, also nehmen Sie die Spielports heraus:

table inet arkraw {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        udp dport { 7777-7780, 27015-27016 } notrack
    }

    chain output {
        type filter hook output priority -300; policy accept;
        udp sport { 7777-7780, 27015-27016 } notrack
    }
}

Beide Richtungen sind nötig, sonst entstehen halbe Einträge für ausgehenden Verkehr. Dazu ein paar Kernelparameter in /etc/sysctl.d/90-ark.conf:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_udp_timeout = 15
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.ipv4.tcp_syncookies = 1

sysctl --system
cat /proc/sys/net/netfilter/nf_conntrack_count

Steigt der zweite Wert unter Angriff gegen das Maximum, war die Verbindungsverfolgung der Engpass und nicht die Leitung.

5. Whitelist und Serverpasswort

Bedient Ihr Cluster ohnehin eine geschlossene Gruppe, ist eine Zugangsliste die wirksamste Maßnahme gegen Störer. ARK bringt sie mit, der Server startet dafür mit -exclusivejoin:

./ShooterGameServer "TheIsland?listen?SessionName=MeinCluster?Port=7777?QueryPort=27015?RCONEnabled=True?RCONPort=27020" -server -log -exclusivejoin

Die erlaubten Spieler stehen dann, eine Kennung pro Zeile, in PlayersExclusiveJoinList.txt im Verzeichnis der Serverbinärdatei. Im Betrieb pflegen Sie die Liste über die Serverkonsole oder RCON:

AllowPlayerToJoinNoCheck <Spielerkennung>
DisallowPlayerToJoinNoCheck <Spielerkennung>

Ein Serverpasswort über ServerPassword wirkt ähnlich, wandert erfahrungsgemäß aber schnell weiter. Beides hat dieselbe harte Grenze: Die Prüfung findet im Spielprozess statt, also erst nachdem das Paket angekommen ist. Gegen eine Paketflut hilft eine Whitelist nicht, gegen den Spieler, der Ihren Cluster erst ausspäht, sehr wohl.

6. Was Anti-Cheat und Plugins leisten, und was nicht

Auf beiden Titeln läuft ab Werk ein Anti-Cheat-System, dazu gibt es Server-Plugins über die jeweilige Server-API. Beides ist sinnvoll, löst aber ein anderes Problem. Anti-Cheat prüft, ob ein verbundener Client manipuliert ist, ein Plugin kann Verbindungsversuche zählen oder Spieler bei auffälligem Verhalten trennen. Alle diese Prüfungen laufen im selben Prozess wie das Spiel und greifen erst, wenn das Paket verarbeitet wird. Ist der Prozess ausgelastet, fällt die Schutzlogik mit ihm aus. Ein Plugin, das DDoS-Angriffe abwehrt, kann es aus diesem Grund nicht geben. Was trotzdem hilft: Serverdateien und Mods aktuell halten und ihre Zahl klein halten, denn ein guter Teil der Abstürze in ARK-Clustern sind fehlerhafte Mods und keine Angriffe.

7. Ihre Adresse steht in der Serverliste

Ein öffentlich gelisteter ARK-Server veröffentlicht IP-Adresse und Abfrageport, sonst könnte ihn niemand finden, und diese Listen werden laufend automatisiert abgefragt und archiviert. Ihre Adresse ist also bekannt, sobald der Server einmal gelistet war. Verstecken ist keine Option, denn wer nicht listet, wächst nicht. Es bleiben die Nebenwege, über die eine Adresse zusätzlich abfließt:

• Alte DNS-Einträge. Ein A-Eintrag, der noch auf den vorigen Server zeigt, verrät die alte Adresse. Solche Einträge gehören gelöscht.
• Weitere Dienste auf derselben Adresse. Webseite, Kartenansicht, Panel, Voice-Server und Datenbank sind jeweils ein zweiter Weg, den Cluster zu treffen.
• Der eigene Discord. Statusbots, Screenshots aus der Konsole und Verbindungsanleitungen enthalten die Adresse oft im Klartext.

8. Messen statt raten

Der häufigste Fehler mitten in einer Störung ist die falsche Diagnose. Ein abgestürzter Mod, ein volles Dateisystem und ein echter Angriff fühlen sich für die Spieler gleich an. Auseinanderhalten lassen sie sich in einer Minute. Zuerst die Paketrate an der Netzwerkkarte:

r1=$(cat /sys/class/net/eth0/statistics/rx_packets)
sleep 1
r2=$(cat /sys/class/net/eth0/statistics/rx_packets)
echo "$((r2-r1)) Pakete pro Sekunde"

Ein Cluster mit fünfzig Spielern liegt normal im niedrigen fünfstelligen Bereich, sechs- oder siebenstellige Werte sind ein Angriff. Danach die Zähler des Netzwerkstapels:

nstat -az UdpInDatagrams UdpNoPorts UdpRcvbufErrors
ss -ulnp | grep -E '7777|27015'

UdpNoPorts steigt, wenn Pakete an Ports ankommen, auf denen nichts lauscht, ein typisches Zeichen für einen blind gestreuten Flood. UdpRcvbufErrors steigt, wenn der Serverprozess die Pakete nicht mehr schnell genug abholt. Zum Schluss das Protokoll des Spiels:

tail -n 200 ShooterGame/Saved/Logs/ShooterGame.log

Steht dort ein Absturzbericht, während die Paketzähler unauffällig sind, war es kein Angriff. Verzichten Sie während einer Störung auf tcpdump, der Mitschnitt kostet Rechenzeit auf einem System, das gerade keine hat. Weitere Merkmale nennt der Beitrag DDoS-Angriff am Server erkennen.

Wo diese Maßnahmen aufhören

Alles bisher Beschriebene wirkt auf dem Server, und genau dort liegt die Grenze. Eine Firewallregel kann nur verwerfen, was bereits angekommen ist. Der Engpass liegt aber davor, auf der Leitung.

Die Zahlen sind eindeutig. Eine Anbindung mit 1 Gbit/s ist bei kleinstmöglichen Paketen nach rund 1,49 Millionen Paketen pro Sekunde ausgelastet, unabhängig davon, was der Server damit vorhat. Ein realer UDP-Flood auf einem ARK-Gameserver bei KernelHost, Port 7777, lag bei über 112,2 Gbit/s und über 8,7 Millionen Paketen pro Sekunde, im Schnitt also rund 1,6 Kilobyte je Paket. Das ist das 112-fache einer 1-Gbit/s-Leitung und immer noch mehr als das Elffache einer 10-Gbit/s-Leitung.

Auch der zweite Engpass ist schnell erreicht: Ein CPU-Kern verwirft mit einem gewöhnlichen Regelwerk je nach Hardware einige hunderttausend Pakete pro Sekunde. Bei 8,7 Millionen geht diese Rechnung auch mit vielen Kernen nicht auf. Die Regel greift korrekt, der Server ist trotzdem offline.

Volumetrische Angriffe müssen deshalb im Netz vor dem Server gefiltert werden. Auf dem Server selbst ist das nicht lösbar, weder mit mehr Hardware noch mit einem besseren Regelwerk.

Was KernelHost davor stellt

Der inkludierte Dauerschutz auf jedem Server

Auf jedem Server von KernelHost läuft ein zweistufiger DDoS-Dauerschutz, ohne Bestellung und ohne Konfiguration. Die erste Stufe ist ein globales Scrubbing-Netzwerk mit 17 Tbps Mitigationskapazität: Volumetrische Angriffe werden nah an ihrer Quelle abgefangen, weit bevor sie das Rechenzentrum erreichen. Die zweite Stufe ist eine Arbor-Echtzeitfilterung mit 3,2 Tbps direkt vor Ort im Rechenzentrum maincubes in Frankfurt am Main, Deutschland. Sie übernimmt die Feinarbeit auf den Schichten 3, 4 und 7 und kennt die Protokollmuster gängiger Gameserver.

Drei Eigenschaften sind entscheidend. Der Schutz ist permanent aktiv, es gibt also keine Reaktionszeit, in der ein Angriff erst erkannt werden müsste. Es wird kein Nullrouting eingesetzt, die angegriffene IP-Adresse bleibt im Netz und nur die schädlichen Pakete fallen weg. Und er kostet nichts extra. Wie das für Gameserver aussieht, beschreibt der Beitrag Gameserver-DDoS-Schutz in Echtzeit.

Advanced DDoS Protection für dauerhaft angegriffene Projekte

Manche Cluster werden nicht einmal getroffen, sondern über Wochen, jeden Abend zur selben Zeit und mit wechselnden Mustern. Dafür gibt es die Advanced DDoS Protection ab 50,00 Euro im Monat, PrePaid und damit ohne Mindestlaufzeit, ohne Kündigungsfrist, ohne Vertrag und ohne Einrichtungsgebühr.

Sie erhalten eine dedizierte Schutz-IP-Adresse aus dem Frankfurter Kern. Ihr Server wird im Netz von KernelHost darauf umgestellt, ein Umbau auf Ihrer Seite entfällt. Der Unterschied liegt danach: Die Schutzregeln verwalten Sie selbst im Kundenbereich, getrennt nach Port und Protokoll, und Änderungen greifen in Echtzeit, ohne Ticket. Als Schutzprofil wählen Sie den Titel, den der jeweilige Port bedient, verfügbar für über 40 Spiele, Dienste und Protokolle, darunter ARK: Survival Evolved. Für einen Cluster heißt das: Spielprofil auf die Spielports, ein engeres Limit auf den Abfrageport, eine eigene Regel für ein Webpanel, statt überall denselben Kompromiss.

Die beiden Stufen im Vergleich

Häufige Fehler und Lösungen

Nur TCP freigegeben, der Server läuft, aber niemand kommt hinein: Der Spielverkehr von ARK ist UDP, eine Regel für tcp dport 7777 ändert daran nichts. Prüfen Sie mit ss -ulnp und geben Sie die Ports als udp dport frei.

Der Server ist erreichbar, taucht aber nicht in der Serverliste auf: Meist ist der Abfrageport zu oder das Rate-Limit zu eng. Öffnen Sie 27015 UDP und heben Sie das Limit an. Zur Kontrolle zeigt nft list set inet ark queryflood, welche Adressen begrenzt werden.

Der eigene Statusbot meldet den Server als offline, obwohl Spieler darauf sind: Ein Discord-Bot fragt aus einer einzigen Quelladresse ab, oft mehrfach pro Sekunde und für jede Karte einzeln, und läuft damit in dasselbe Limit wie ein Angreifer. Legen Sie eine Ausnahme für diese Adresse vor die Limit-Regel.

Nach dem Laden des Regelwerks ist kein SSH mehr möglich: In adminips stand die falsche Adresse, oder SSH läuft auf einem anderen Port. Sie kommen über die VNC-Konsole im Kundenbereich zurück auf den Server, ein IPMI oder iDRAC gibt es bei den Dedicated Servern und KVM-Rootservern nicht. Dort nft flush ruleset als Notbremse ausführen, danach die Datei korrigieren.

sysctl kann die conntrack-Werte nicht setzen: Die Parameter unter net.netfilter existieren erst, wenn das Modul geladen ist. Laden Sie es mit modprobe nf_conntrack und rufen Sie sysctl --system erneut auf.

Ein vermeintlicher Angriff ist in Wirklichkeit ein Mod: Sind die Paketzähler normal und steht in ShooterGame.log ein Absturzbericht, war die Ursache nicht das Netz. Nach einer Aktualisierung im Workshop ist das die wahrscheinlichste Erklärung, besonders wenn immer dieselbe Karte betroffen ist.

Der ganze Cluster geht gleichzeitig offline: Alle Instanzen hängen an derselben IP-Adresse, ein Angriff trifft damit alles auf einmal, inklusive Transfer. Eine dedizierte Schutz-IP löst genau dieses Muster, weil die Filterung dann vor der Adresse steht statt auf dem Server dahinter.

Kurz zusammengefasst

Öffnen Sie nur die Spielports, den Abfrageport und den Zugang für Ihre eigene Adresse, begrenzen Sie den Abfrageport pro Quelle, halten Sie RCON aus dem Internet heraus und messen Sie Paketraten, bevor Sie eine Ursache annehmen. Das kostet nichts und deckt den Alltag ab. Alles darüber hinaus entscheidet sich nicht mehr auf dem Server: Der inkludierte Dauerschutz mit 17 Tbps Mitigationskapazität im globalen Scrubbing-Netzwerk und 3,2 Tbps Arbor-Echtzeitfilterung in Frankfurt am Main fängt es ohne Aufpreis und ohne Nullrouting ab. Bei dauerhaftem Beschuss ergänzt die Advanced DDoS Protection eine dedizierte Schutz-IP mit selbst gesetzten Regeln. Betreiber ist die KernelHost GmbH mit Sitz in Wien in Österreich.