RAGE MP und alt:V Server vor DDoS-Angriffen schützen

Ein GTA-Multiplayer-Server ist für Angreifer ein dankbares Ziel: Er hängt an einer einzigen IP-Adresse, sein Port steht in einer öffentlichen Serverliste, und jeder Aussetzer ist für alle Spieler gleichzeitig sichtbar. Dieser Beitrag zeigt zuerst, was Sie auf dem eigenen Server wirklich erreichen können, und danach genauso deutlich, wo diese Möglichkeiten enden.

Falls Sie noch gar nicht sicher sind, ob überhaupt ein Angriff läuft, messen Sie das zuerst: DDoS-Angriff erkennen beschreibt die Diagnose Schritt für Schritt. Die technischen Grundlagen stehen in Was ist ein DDoS-Angriff.

Warum ausgerechnet RAGE MP und alt:V so oft getroffen werden

Die Rollenspiel-Szene rund um GTA V ist klein, öffentlich und stark umkämpft. Ein Server lebt von seiner Stammspielerschaft, und die ist bei längeren Aussetzern schnell in einem anderen Discord. Das macht Angriffe attraktiv: Es braucht keinen Erfolg über Stunden, ein paar Minuten zur besten Spielzeit genügen, am Eröffnungsabend oder während eines angekündigten Wipes.

Dazu kommt, dass niemand lange suchen muss. Beide Plattformen melden Ihren Server auf Wunsch an eine öffentliche Serverliste, RAGE MP über announce in der conf.json, alt:V über announce und token in der server.toml. Wer dort steht, veröffentlicht damit IP-Adresse und Port. Ein frisch eingetragener Server bekommt die ersten automatisierten Verbindungsversuche deshalb oft schon in der ersten Stunde, lange bevor der erste echte Spieler da ist.

Der dritte Grund ist technischer Natur: Der Spielverkehr läuft über UDP. UDP kennt keinen Verbindungsaufbau, den ein Absender abwarten müsste, also lässt sich die Absenderadresse fälschen. Wer Ihren Port kennt, kann ihn beschießen, ohne je eine Antwort zu bekommen und ohne die eigene Adresse zu zeigen.

Die Ports, um die es geht

Bevor Sie die erste Regel schreiben, sollten Sie wissen, welcher Port wofür da ist. Beide Plattformen brauchen mehr als einen.

Zwei Eigenheiten sind dabei wichtig. Bei RAGE MP ist der HTTP-Port fest an den Spielport gekoppelt, er ist immer der nächsthöhere: Verschieben Sie den Spielport auf 22015, wandert der Dateiport auf 22016 mit. Bei alt:V teilen sich Spielverkehr und Dateiauslieferung dieselbe Portnummer, einmal über UDP und einmal über TCP. Wer die Client-Dateien über ein Content-Delivery-Netz ausliefern lässt (Optionen useCdn und cdnUrl in der server.toml), nimmt den TCP-Teil aus der eigenen Leitung heraus. Der Spielverkehr über UDP bleibt davon unberührt.

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

Die folgenden Schritte halten keinen volumetrischen Angriff auf, das kann keine Software auf dem Server. Sie räumen aber alles ab, was darunter liegt: Portscans, Verbindungsfluten aus wenigen Quellen, Angriffe auf die Datenbank statt auf das Spiel und den Missbrauch Ihres eigenen Dateiports. Das ist der Großteil dessen, was einen kleinen Server im Alltag stört, und kostet nur eine halbe Stunde.

Schritt 1: Bestandsaufnahme, was nach außen lauscht

ss -tulnp

Interessant ist die Spalte mit der lokalen Adresse. Alles, was dort auf 0.0.0.0 oder [::] steht, ist aus dem Internet erreichbar, alles auf 127.0.0.1 nur lokal. Auf einem typischen Rollenspiel-Server finden sich neben dem Spiel schnell eine Datenbank, ein Zwischenspeicher, ein Webpanel und manchmal ein Voice-Server. Jeder dieser Dienste ist eine eigene Angriffsfläche, und keiner davon muss offen sein, nur weil er läuft.

Schritt 2: Die Firewall auf die tatsächlich benötigten Ports einschränken

Für einen RAGE-MP-Server sind das drei Freigaben: SSH, Spielport und Dateiport. Erlauben Sie in jedem Fall zuerst Ihren SSH-Port, sonst sperren Sie sich mit der letzten Zeile selbst aus:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 22005/udp
ufw allow 22006/tcp
ufw enable

Für alt:V lauten die beiden Spielregeln stattdessen:

ufw allow 7788/udp
ufw allow 7788/tcp

Prüfen Sie danach mit ufw status verbose, ob wirklich nur diese Ports offen sind, und wiederholen Sie ss -tulnp. Die ausführliche Einrichtung samt IPv6 und den typischen Aussperr-Fallen steht in UFW-Firewall einrichten.

Schritt 3: Datenbank und Zwischenspeicher vom Netz nehmen

MariaDB und Redis laufen bei den meisten Gamemodes auf derselben Maschine wie der Spielserver und brauchen dann keine Adresse im Internet. In die MariaDB-Konfiguration (unter Debian und Ubuntu /etc/mysql/mariadb.conf.d/50-server.cnf) gehört dazu die Zeile:

bind-address = 127.0.0.1

Und in die /etc/redis/redis.conf:

bind 127.0.0.1 ::1
protected-mode yes

Danach beide Dienste neu starten und mit ss -tulnp gegenprüfen. Ein offener Zwischenspeicher ohne Passwort ist kein DDoS-Problem, sondern ein Einbruchsweg, und er wird rund um die Uhr gescannt.

Schritt 4: Verbindungsraten auf dem Dateiport begrenzen

Der TCP-Port für die Client-Dateien ist die Stelle, an der eine Ratenbegrenzung auf dem Server sinnvoll greift, denn hier gibt es einen echten Verbindungsaufbau und damit eine Absenderadresse, der man halbwegs trauen kann. Zwei Regeln genügen, hier für RAGE MP auf Port 22006:

iptables -A INPUT -p tcp --dport 22006 --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p tcp --dport 22006 --syn -m hashlimit --hashlimit-name gtahttp --hashlimit-mode srcip --hashlimit-above 30/sec --hashlimit-burst 60 -j DROP

Die erste Regel begrenzt die gleichzeitig offenen Verbindungen je Quelladresse, die zweite die Verbindungsversuche pro Sekunde. Für alt:V setzen Sie an beiden Stellen 7788 ein. Drei Hinweise dazu: ufw limit ist hier zu grob und kennt nur TCP, die Zahlenwerte passen Sie an die Größe Ihrer Client-Dateien an, und die Regeln überleben einen Neustart nur mit iptables-persistent oder als Eintrag in /etc/ufw/before.rules.

Auf dem UDP-Spielport bringt dieselbe Technik dagegen wenig, weil die Absender dort gefälscht sind: Eine Sperre nach Quelladresse trifft dann niemanden außer zufällig einen echten Spieler. Was Sie stattdessen im Blick behalten sollten, ist die Verbindungsverfolgung des Kernels:

cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Nähert sich der erste Wert dem zweiten, verwirft der Kernel Pakete unabhängig davon, ob sie zu einem Angriff oder zu einem Spieler gehören. Im Systemprotokoll steht dann nf_conntrack: table full, dropping packet.

Schritt 5: Die Bordmittel der beiden Plattformen nutzen

Beide Serverkerne bringen Einstellungen mit, die genau gegen Verbindungsmissbrauch gedacht sind und ab Werk auf dem lockersten Wert stehen. Bei RAGE MP betrifft das drei Schlüssel in der conf.json:

{
    "bind": "0.0.0.0",
    "port": 22005,
    "announce": true,
    "maxplayers": 200,
    "disallow-multiple-connections-per-ip": true,
    "limit-time-of-connections-per-ip": 1000,
    "enable-http-security": true
}

Das ist ein Ausschnitt, die übrigen Schlüssel bleiben unverändert. disallow-multiple-connections-per-ip unterbindet mehrere gleichzeitige Verbindungen derselben Adresse, limit-time-of-connections-per-ip erzwingt einen Mindestabstand zwischen zwei Verbindungsversuchen (0 schaltet die Begrenzung ab), und enable-http-security aktiviert die zusätzlichen Prüfungen des eingebauten HTTP-Servers. Gleichen Sie die Zeiteinheit des mittleren Wertes mit der Dokumentation Ihrer Serverversion ab, bevor Sie ihn erhöhen. Und rechnen Sie damit, dass die erste Option Mitspieler hinter demselben Anschluss aussperrt, also Wohngemeinschaften, Familien und Firmennetze.

Bei alt:V stehen die entsprechenden Optionen in der server.toml:

host = '0.0.0.0'
port = 7788
players = 200
announce = true
duplicatePlayers = 4
connectionQueue = true
useEarlyAuth = true

duplicatePlayers begrenzt, wie viele Spieler mit derselben IP-Adresse gleichzeitig verbunden sein dürfen. Der Standardwert liegt bei 4096 und ist damit praktisch keine Grenze. connectionQueue stellt Verbindungsversuche in eine Warteschlange, statt sie alle auf einmal abzuarbeiten. useEarlyAuth schaltet eine Anmeldung vor den Spielserver: Der Client muss sich anmelden, bevor er in Ihre Spielwelt kommt, was einfache Verbindungsfluten von vornherein aussortiert. Die Adresse der Anmeldeseite steht in earlyAuthUrl.

Schritt 6: Whitelist, solange es brennt

Wenn ein Angriff über die Spielmechanik läuft, also über massenhafte Verbindungsversuche statt über reine Bandbreite, ist eine Whitelist das wirksamste kurzfristige Mittel. Bei alt:V genügt für den geschlossenen Betrieb schon ein password in der server.toml. Programmatisch sieht die einfachste Form so aus, hier für RAGE MP:

const whitelist = new Set(['SpielerEins', 'SpielerZwei']);

mp.events.add('playerJoin', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Der Server ist derzeit geschlossen.');
    }
});

Und dieselbe Logik für alt:V:

import * as alt from 'alt-server';

const whitelist = new Set(['SpielerEins', 'SpielerZwei']);

alt.on('playerConnect', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Der Server ist derzeit geschlossen.');
    }
});

Beides ist bewusst einfach gehalten und hat eine klare Grenze: Der Anzeigename ist kein starkes Merkmal. Wer eine Whitelist dauerhaft betreibt, prüft besser gegen die Kennung aus der vorgelagerten Anmeldung oder gegen eine eigene Kontenverwaltung. Vor allem aber gilt: Ein Kick passiert erst, nachdem die Verbindung den Server erreicht hat. Gegen Pakete, die schon die Leitung füllen, hilft er nicht.

Schritt 7: Serverlisten-Eintrag und IP-Hygiene

Den Eintrag in der Serverliste abzuschalten (announce auf false) klingt nach einer schnellen Lösung und ist meistens keine. Wer Ihre IP-Adresse bereits hat, erreicht Sie weiterhin, und Ihre Spieler finden Sie nicht mehr. Sinnvoll ist der Schritt nur zusammen mit einem Wechsel der IP-Adresse, denn erst dann verliert der Angreifer sein Ziel.

Dauerhaft mehr bringt Sauberkeit an den Stellen, an denen die Adresse nebenbei bekannt wird: Webseite und Forum auf einer anderen Maschine betreiben, alte DNS-Einträge löschen (auch mail, ftp und Testnamen aus der Anfangszeit), Discord-Bots und Statusanzeigen nicht vom Spielserver aus laufen lassen, Voice-Server trennen. Vollständig verstecken lässt sich die Adresse eines Spielservers allerdings nicht: Der Spielverkehr über UDP muss direkt bei Ihnen ankommen, ein vorgeschaltetes Content-Delivery-Netz für Webseiten ändert daran nichts. Was hier hilft, ist keine Verschleierung, sondern eine Adresse, hinter der eine Filterung steht.

Schritt 8: Messwerte sammeln, bevor es ernst wird

Im Ernstfall zählt, was Sie belegen können. Legen Sie sich vorher die Befehle zurecht, mit denen Sie eingehende Paketrate und Verbindungslage in Sekunden erfassen:

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) Pakete/s eingehend auf $IF"
ss -s

Notieren Sie diese Werte einmal im Normalbetrieb zur Hauptspielzeit, denn ohne Vergleichswert ist jede Zahl im Angriffsfall wertlos. Läuft Ihr Spielserver als systemd-Dienst, gehört journalctl -u <dienstname> -n 200 dazu: Verbindungsfluten hinterlassen dort meist eine deutliche Spur. Eine Einschränkung muss man dabei kennen: Im Server messen Sie nur, was durchgekommen ist. Liegt eine Filterung davor, steht die belastbare Zahl im Traffic-Graphen im Kundenbereich und nicht in /proc.

Wo diese Maßnahmen aufhören

Jede Regel auf dem Server greift erst, nachdem das Paket angekommen ist. Das ist der entscheidende Satz. Eine Firewall entscheidet über Pakete, die bereits durch Ihre Leitung gelaufen sind, und genau diese Leitung ist das Ziel eines volumetrischen Angriffs.

Die Größenordnungen dazu: Ein einzelner Server hängt typischerweise an 1 Gbit/s. Bei kleinsten Paketen entspricht das rund 1,5 Millionen Paketen pro Sekunde, mehr passt physikalisch nicht durch. Um diese Leitung dichtzumachen, braucht niemand einen Rekordangriff, 2 bis 5 Gbit/s genügen dafür. Zum Vergleich ein real gemessener Angriff aus dem Frankfurter Netz von KernelHost: über 473,4 Gbit/s und über 41,5 Millionen Pakete pro Sekunde auf einen einzelnen Dienst. Das ist rund das 470-Fache einer Gigabit-Leitung, und auch ein 10-Gbit/s-Anschluss ist davon um den Faktor 47 entfernt.

Ist die Leitung voll, verwirft bereits der Router davor, und zwar ohne Ansehen des einzelnen Pakets. Ihre Spieler stehen dann in derselben Warteschlange wie der Angriff. Kein iptables, kein Plugin und keine stärkere CPU ändert daran etwas, weil der Engpass vor dem Server liegt. Hinzu kommt, dass die Absenderadressen bei UDP-Fluten gefälscht sind: Es gibt schlicht niemanden, den Sie sinnvoll sperren könnten.

Wirksam ist deshalb nur eine Filterung, die im Netz vor Ihrer Leitung sitzt und dort so viel Kapazität hat, dass der Angriff sie nicht sättigt.

Was KernelHost dagegen stellt

Der Dauerschutz, der auf jedem Server bereits läuft

Bei KernelHost (KernelHost GmbH, Sitz Wien, Österreich) ist auf jedem Server ein zweistufiger DDoS-Schutz permanent aktiv, ohne Bestellung, ohne Konfiguration und ohne Aufpreis:

• Stufe 1: globales Scrubbing-Netzwerk mit 17 Tbps Mitigationskapazität. Volumetrische Angriffe werden nah an ihrer Quelle abgefangen, bevor sie das Rechenzentrum überhaupt erreichen.
• Stufe 2: Arbor-Echtzeitfilterung mit 3,2 Tbps. Sie steht vor Ort im maincubes-Rechenzentrum in Frankfurt am Main (Deutschland) und übernimmt direkt vor Ihrem Server die Feinarbeit, Paket für Paket.

Genauso wichtig ist, was nicht passiert: Es gibt kein Nullrouting. Ihre IP-Adresse bleibt während eines Angriffs im Netz, es fallen nur die schädlichen Pakete weg. Für einen Rollenspiel-Server ist dieser Unterschied erheblich, denn eine nullgeroutete Adresse ist für Ihre Spieler von einem erfolgreichen Angriff nicht zu unterscheiden. Sollten Sie während eines Vorfalls per SSH nicht mehr durchkommen, erreichen Sie das System weiterhin über die VNC-Konsole im Kundenbereich, die unabhängig von der Netzwerkanbindung des Servers arbeitet.

Advanced DDoS Protection für dauerhaft angegriffene Projekte

Manche Projekte werden nicht nur einmal getroffen, sondern über Wochen hinweg. Für diesen Fall gibt es die Advanced DDoS Protection ab 50,00 € im Monat, PrePaid und ohne Mindestlaufzeit, ohne Kündigungsfrist, ohne Vertrag und ohne Einrichtungsgebühr. Enthalten sind:

• eine dedizierte Schutz-IP aus dem Frankfurter Kern, auf die Ihr Server umgestellt wird, ohne Umbau auf Ihrer Seite,
• Schutzregeln, die Sie selbst verwalten, je Port und Protokoll, direkt im Kundenbereich,
• Änderungen, die in Echtzeit greifen, ohne Ticket und ohne Wartezeit,
• ein Schutzprofil passend zum jeweiligen Spiel, aus über 40 Profilen für Spiele, Dienste und Protokolle, darunter RageMP und alt:V, dazu allgemeine Profile für eigene TCP- und UDP-Anwendungen.

Der praktische Unterschied liegt in der Kontrolle: Sie entscheiden selbst, welches Profil auf 22005 UDP läuft und welche Regel für 22006 TCP gilt, auch mitten in einem Angriff.

Die beiden Stufen im Vergleich

Häufige Fehler und Lösungen

Alle Ports offen, weil sonst irgendetwas nicht funktioniert: Das ist fast immer eine Fehldiagnose. Notieren Sie sich mit ss -tulnp, welcher Dienst welchen Port braucht, und öffnen Sie genau diese. Fehlt danach etwas, liegt es meist an einem Dienst, der ohnehin nur lokal gebunden ist.

Die Angreifer-IPs werden gesperrt: Bei einer UDP-Flut sind die Absender gefälscht. Sie sperren damit unbeteiligte Adressen und im schlimmsten Fall Ihre eigenen Spieler. Sinnvoll ist das nur bei TCP-Verbindungen mit vollständigem Verbindungsaufbau, also auf dem Dateiport.

Nur announce auf false gesetzt: Der Server verschwindet aus der Liste, die IP-Adresse bleibt aber dieselbe. Ein laufender Angriff läuft unverändert weiter, nur finden Ihre Spieler den Server nicht mehr. Ohne Wechsel der Adresse bringt der Schritt nichts.

Ratenbegrenzung auf dem UDP-Spielport: Mobilfunknetze und Firmenanschlüsse bündeln viele Spieler hinter einer Adresse. Eine Begrenzung pro Quelladresse wirft dort echte Spieler heraus, während die gefälschten Absender der Flut unbehelligt bleiben.

Mehr CPU und mehr RAM als Antwort auf DDoS: Beides hilft gegen einen überlasteten Gamemode, nicht gegen eine volle Leitung. Der Engpass liegt vor dem Server, und dort ändert stärkere Hardware nichts.

Neustart mitten im Angriff: Er löscht alle Zähler, die Sie für eine belastbare Meldung gebraucht hätten, und der Angriff läuft danach unverändert weiter. Sammeln Sie erst die Messwerte, dann handeln Sie.

Datenbank offen im Internet, weil das Webpanel auf einer anderen Maschine läuft: Führen Sie die Verbindung über einen SSH-Tunnel oder ein privates Netz. Geht das nicht, beschränken Sie den Zugang zumindest auf die eine Quelladresse, die ihn wirklich braucht.

Wenn es gerade passiert

Sammeln Sie zuerst die Messwerte aus Schritt 8, damit Ihre Meldung belastbar ist: Zeitpunkt mit Zeitzone, betroffene IP-Adresse und betroffener Port, gemessene Paketrate mit Richtungsangabe. Danach eröffnen Sie ein Support-Ticket. Bei einem laufenden Angriff erreichen Sie uns zusätzlich über den WhatsApp-Notfall-Chat unter +43 650 8209883. Den anbieterunabhängigen Überblick über die weiteren Schritte gibt Server vor DDoS-Angriffen schützen.