Rust-Server vor DDoS-Angriffen schützen

Ein Rust-Server geht selten zufällig offline. Der Zeitpunkt verrät fast immer das Motiv: Der Angriff beginnt in der Minute des Wipes oder mitten in einem Raid. Wer 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 ausgerechnet Rust-Server so häufig angegriffen werden

Rust ist ein Spiel, in dem Fortschritt an Zeit gebunden ist. Ein Raid dauert Minuten, ein Wipe-Zyklus Wochen. Deshalb ist ein Ausfall hier wertvoller als in fast jedem anderen Spiel: Wer verteidigt, gewinnt Zeit, wenn der Server fällt. Wer angreift, verhindert, dass die Gegenseite online kommt. Und wer eine konkurrierende Community betreibt, weiß, dass der erste Wipe-Abend über die Spielerzahl des Monats entscheidet.

Dazu kommt ein Punkt, den man nicht wegkonfigurieren kann: Ein Rust-Server ist mit IP-Adresse und Port öffentlich auffindbar, sonst könnte niemand beitreten. Anders als eine Website hinter einem Proxy muss ein Gameserver seine echte Adresse veröffentlichen. Die Frage lautet also nie, ob der Angreifer Ihre IP findet, sondern nur, was passiert, wenn er darauf schießt.

Die Ports, um die es geht

Ein Rust-Server belegt in der üblichen Konfiguration vier Ports:

• 28015/UDP, der Spielport (server.port). Hier läuft der komplette Spielverkehr. UDP kennt keinen Verbindungsaufbau, jedes Paket steht für sich, und die Absenderadresse lässt sich fälschen. Für einen Angreifer heißt das: keine Rückverfolgbarkeit und trotzdem Arbeit für Ihren Server bei jedem Paket.
• Der Query-Port (server.queryport), ebenfalls UDP. Darüber beantwortet der Server die Steam-Abfragen A2S_INFO, A2S_PLAYERS und A2S_RULES, ohne ihn erscheint er in keiner Serverliste. Ohne ausdrücklichen Wert liegt er direkt neben dem Spielport, viele Startzeilen setzen ihn auf 28017/UDP. Sehen Sie in Ihrer eigenen Startzeile nach, statt sich auf einen Standardwert zu verlassen.
• 28016/TCP, RCON (rcon.port), bei rcon.web 1 als WebSocket-Variante.
• 28082/TCP, die Companion-App Rust+ (app.port).

Der Query-Port ist der unangenehmste der vier, denn eine A2S-Antwort ist deutlich größer als die Anfrage. Ein Angreifer kann fremde Gameserver mit gefälschter Absenderadresse abfragen und die Antworten auf sein eigentliches Ziel lenken. Ihr Server ist dann nicht nur Opfer, sondern Verstärker gegen Dritte. Valve hat A2S_INFO deshalb um eine Challenge-Abfrage ergänzt, was die Sache entschärft, aber nicht beendet hat. Woran Sie einen 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, sorgt aber dafür, dass kleine Angriffe wirkungslos bleiben und dass Sie im Ernstfall nicht raten müssen.

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 auf 0.0.0.0 oder [::] ist aus dem Internet erreichbar, auch der Datenbankdienst, den ein Plugin mitgebracht hat. Vergleichen Sie die Ausgabe mit Ihrer Startzeile:

./RustDedicated -batchmode -nographics \
  +server.port 28015 \
  +server.queryport 28017 \
  +server.identity "wipe" \
  +server.maxplayers 150 \
  +rcon.port 28016 \
  +rcon.web 1 \
  +rcon.password "IHR-LANGES-ZUFALLSPASSWORT"

Wenn Rust bei Ihnen über SteamCMD installiert ist, hilft für den Unterbau der Beitrag Gameserver mit SteamCMD installieren.

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

Vier Ports, mehr nicht. RCON gehört nicht ins offene Internet, sondern auf Ihre Adresse eingeschränkt, und Rust+ nur geöffnet, wenn Sie die Companion-App nutzen:

ufw allow 28015/udp comment "Rust Spielport"
ufw allow 28017/udp comment "Rust Query"
ufw allow from 203.0.113.10 to any port 28016 proto tcp comment "Rust RCON"
ufw allow 28082/tcp comment "Rust Companion"

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Bei einer wechselnden Adresse führt der Weg über einen SSH-Tunnel.

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: Bei KVM-Rootservern und Dedicated Servern von KernelHost erreichen Sie den Server über die VNC-Konsole im Kundenbereich. Sie hängt nicht am Netzwerkstack des Gastsystems und lässt sich von einer Firewall-Regel im Gast nicht blockieren.

3. Den Query-Port absichern, ohne aus der Serverliste zu fliegen

Der naheliegende Reflex, den Query-Port zu sperren, ist der teuerste Fehler in diesem Themenfeld. Ohne ihn verschwindet Ihr Server aus dem Serverbrowser, zeigt falsche Spielerzahlen und wird von Listenseiten als offline geführt. Sie hätten den Angriff selbst zu Ende gebracht.

Richtig ist eine Ratenbegrenzung je Absenderadresse. Ein echter Client fragt beim Durchblättern der Liste ein paar Mal pro Sekunde ab, ein Reflexionswerkzeug tausendfach. Mit nftables in einer eigenen Tabelle, die vor der Filterkette ausgewertet wird:

table inet rust {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 28017 meter rustquery { ip saddr limit rate over 15/second } drop
    }
}

Die Datei laden Sie mit nft -f. Die Priorität -10 sorgt dafür, dass die Regel vor der Filterkette greift, die UFW mit Priorität 0 anlegt. Mit klassischem iptables erreicht das Modul hashlimit dasselbe:

iptables -A INPUT -p udp --dport 28017 -m hashlimit \
  --hashlimit-name rustquery --hashlimit-mode srcip \
  --hashlimit-above 15/sec --hashlimit-burst 30 -j DROP

Beginnen Sie großzügig und ziehen Sie die Grenze erst an, wenn legitime Abfragen nachweislich durchkommen. Eine zu enge Grenze fällt sonst erst am Wipe-Tag auf.

4. 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 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. Prüfen lässt sich das so:

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

Der wirksamste Schritt ist, den Spielverkehr gar nicht erst verfolgen zu lassen. Rust braucht dafür keine Zustandsverfolgung im Kernel, es verwaltet seine Sitzungen selbst:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 28015 notrack
    }
}

Mit iptables lautet die Entsprechung:

iptables -t raw -A PREROUTING -p udp --dport 28015 -j NOTRACK

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.

5. Empfangspuffer und Kernel-Parameter

Kommen Pakete schneller an, als der Rust-Prozess sie abholt, läuft 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 -p. 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. RCON absichern

Ein offener RCON-Port mit schwachem Passwort ist kein DDoS-Problem, sondern eine Übernahme: Wer RCON hat, kann bannen, entbannen und das Spiel stoppen. Setzen Sie rcon.password nie leer und nie geraten, ein Wert aus openssl rand -base64 32 ist in fünf Sekunden erzeugt. Und geben Sie den Port nicht öffentlich frei, sondern schränken Sie ihn auf Ihre Adresse ein.

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

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

• Serverbinary aktuell halten. Das monatliche Update, das den Wipe erzwingt, ist gleichzeitig ein Sicherheitsupdate. Wer es hinauszögert, bleibt auf den bekannten Fehlern sitzen.
• Plugin-Framework aktuell halten. Oxide/uMod und Carbon ziehen nach jedem Rust-Update nach. Ein Framework, das zur Serverversion nicht passt, ist der häufigste Grund für Abstürze am Wipe-Abend.
• Weniger Plugins. Jedes Plugin ist zusätzlicher Code im selben Prozess. Plugins mit eigenen Webdiensten (Kartenansichten, Statistikseiten) öffnen weitere Ports und veröffentlichen dabei oft genau die Adresse, die Sie schützen wollen.
• Bannlisten pflegen. Wiederholte Verbindungsversuche desselben Kontos lassen sich mit Bordmitteln unterbinden. Rust legt Besitzer und Moderatoren in server/<identity>/cfg/users.cfg ab, Sperren in server/<identity>/cfg/bans.cfg. Eine Sperre über banid überlebt den Neustart.

Eine Whitelist bringt Rust im Kern nicht mit, sie kommt über das Plugin-Framework. Für einen privaten oder Community-Server ist sie wirksam. Für einen öffentlichen Wipe-Server ist sie keine Option: Ein Server, den niemand betreten kann, ist genauso leer wie einer, der offline ist.

8. Serverliste und die eigene Adresse

An der öffentlichen Spielserver-IP lässt sich nichts ändern, sehr wohl aber an allem daneben. Oft findet ein Angreifer gleich die ganze Umgebung: den Webserver mit dem Shop, den Host des Discord-Bots, den Backup-Server, den Panel-Zugang. Diese Adressen gehören weder in dieselbe Ankündigung noch in alte DNS-Einträge. Prüfen Sie einmal im Quartal, welche Subdomain wohin zeigt.

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

Im Angriff zählt eine Frage: Wie viel kommt an und auf welchem Port. Drei Kommandos genügen:

ip -s link show eth0
nstat -az | grep -i udp
journalctl -u rust-server -f

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. Schnittstelle und Dienst-Unit heißen bei Ihnen möglicherweise anders, prüfen Sie beides mit ip -br link und systemctl list-units --type=service. Wie die Pakete aussehen, zeigt eine Stichprobe, die kurz bleiben sollte, weil eine Mitschrift unter Last Rechenzeit kostet:

tcpdump -ni eth0 -c 200 "udp port 28015"

Wo der Eigenschutz aufhört

Jetzt der ehrliche Teil. Alles bisher Beschriebene wirkt erst, wenn die Pakete auf Ihrer Netzwerkkarte angekommen sind. Ein Server hängt typischerweise an 1 Gbit/s oder 10 Gbit/s. 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 ARK-Gameserver auf Port 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 Port 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 am Router davor entsteht. Und lange bevor die Leitung voll ist, ist die CPU am Ende: Jedes Paket kostet einen Interrupt und einen Durchlauf durch den Netzwerkstack, auch wenn es danach verworfen wird.

Deshalb sind die zwei verbreiteten Notbremsen beide unbefriedigend. Nullrouting (Blackholing) nimmt die angegriffene IP aus dem Netz und beendet zwar den Angriff, aber auch Ihren Server. Und eine reaktive Umleitung in ein Filtersystem kostet in der Umschaltzeit genau die Minuten, in denen der Raid 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, 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 protokollnahe 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 Erkennungs- und 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), TÜV TIER3+ zertifiziert und direkt am DE-CIX. 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 Rust-Projekte werden nicht gelegentlich, sondern über Wochen gezielt angegriffen, mit wechselnden Mustern und immer genau zum Wipe. 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 so nicht bietet:

• Eine dedizierte Schutz-IP. Ihr Server wird in unserem eigenen Netz darauf 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 28015/UDP anders als der Query-Port. Änderungen greifen in Echtzeit, ohne Ticket und ohne Wartezeit.
• Ein Schutzprofil passend zum jeweiligen Spiel. Für Rust ebenso wie für über 40 weitere Spiele, Dienste und Protokolle, dazu frei belegbare 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 nicht.

Die beiden Stufen im Vergleich

Häufige Fehler und Lösungen

Der Server ist aus dem Serverbrowser verschwunden, läuft aber weiter: Fast immer ist der Query-Port gesperrt oder zu eng ratenbegrenzt. Prüfen Sie mit ss -lunp, ob er lauscht, und lockern Sie die Ratengrenze schrittweise. Bleibt Rust+ stumm, ist meist app.port zu.

Alle Spieler haben hohen Ping und Rubberbanding, 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. Ein voller Empfangspuffer oder eine erschöpfte Verbindungsverfolgung erzeugt dieses Bild.

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 fiel, kann nichts bewirken. Ab diesem Punkt hilft nur Filterung im Netz.

Nach dem Scharfschalten der Firewall kein SSH-Zugang mehr: Melden Sie sich über die VNC-Konsole im Kundenbereich an. Darüber lässt sich die Firewall abschalten und die fehlende Regel nachtragen, auch wenn über das Netz nichts mehr geht.

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

Auf dem Server laufen fremde Admin-Befehle: Kein DDoS, sondern ein kompromittierter RCON-Zugang. Passwort sofort ändern, den Port auf Ihre Adresse einschränken, die Bannliste prüfen.

Wenn Sie gerade angegriffen werden

Läuft Ihr Server bereits bei KernelHost, ist die Filterung permanent aktiv und Sie müssen nichts einschalten. 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 kurz, was Sie sehen (Spieler fliegen heraus, Server nicht erreichbar, hoher Ping). Das erspart eine Rückfragerunde, und die zählt, wenn der Wipe läuft.