FiveM-Server vor DDoS-Angriffen schützen

Ein FiveM-Roleplay-Server, der abends immer wieder für ein paar Minuten verschwindet, hat selten ein Hardwareproblem. Meistens läuft ein Angriff, und zwar genau dann, wenn die meisten Spieler online sind. 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 einen FXServer 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.

Wenn der Angriff gerade läuft: Ändern Sie jetzt nichts an der Konfiguration und starten Sie den Server nicht neu. Sichern Sie zuerst die Messwerte (siehe Abschnitt "Protokollieren"), nach dem Angriff sind sie weg.

Warum ausgerechnet FiveM-Server so oft angegriffen werden

FiveM-Projekte vereinen mehrere Eigenschaften, die sie zu einem bequemen Ziel machen. Erstens veröffentlicht ein RP-Server seine Adresse von sich aus: Der Eintrag in der Cfx.re-Serverliste enthält IP-Adresse und Port im Klartext, weil Spieler den Server sonst nicht finden würden. Zweitens ist die Spielerschaft an feste Zeiten gebunden, ein Ausfall um 20 Uhr ist also maximal sichtbar. Drittens gibt es Konkurrenz zwischen Projekten, gebannte Spieler und interne Konflikte, und ein Angriff kostet den Auslöser weder Können noch nennenswertes Geld.

Technisch kommt hinzu, dass der Spielverkehr über UDP läuft. UDP kennt keinen Verbindungsaufbau, den man verlangen könnte, und Absenderadressen lassen sich fälschen. Ein Angreifer muss Ihren Server also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Was ein DDoS-Angriff im Detail ist, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es tatsächlich geht

Ein FXServer bindet sich standardmäßig auf einen einzigen Port, und zwar auf beiden Protokollen. In der server.cfg:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

Diese beiden Zeilen sind die gesamte Angriffsfläche des Spiels selbst:

• 30120 UDP trägt den laufenden Spielverkehr: Positionsdaten, Synchronisation, Sprachübertragung.
• 30120 TCP trägt den Verbindungsaufbau und die eingebauten HTTP-Endpunkte des FXServer: /info.json, /players.json und /dynamic.json.
• 40120 TCP ist die Voreinstellung für die Weboberfläche von txAdmin.
• 3306 TCP gehört zur Datenbank, die jedes ESX- oder QBCore-Framework braucht.
• 22 TCP ist Ihr SSH-Zugang.

Von diesen fünf Ports gehören genau zwei ins offene Netz. Die anderen drei sind der häufigste vermeidbare Fehler auf FiveM-Servern.

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

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

1. Bestandsaufnahme: was lauscht überhaupt?

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

ss -lntup

Interessant ist die Spalte mit der lokalen Adresse. 0.0.0.0:30120 und [::]:30120 bedeuten "aus dem ganzen Internet erreichbar", 127.0.0.1:3306 bedeutet "nur lokal" und braucht keine Firewall-Regel. Neben dem Spiel tauchen dort oft noch txAdmin, MariaDB, ein Webserver und ein längst vergessener Voice-Dienst auf. Die Sicht des Angreifers liefert ein Portscan von außen:

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

2. Nur offen lassen, was das Spiel wirklich braucht

Für FiveM reichen zwei Freigaben nach außen, alles andere wird eingeschränkt oder gar nicht erst veröffentlicht. Mit UFW sieht das so aus, und zwar genau in dieser Reihenfolge, damit Sie sich nicht selbst aussperren:

ufw allow 22/tcp comment 'SSH'
ufw allow 30120/tcp comment 'FiveM'
ufw allow 30120/udp comment 'FiveM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Ersetzen Sie 203.0.113.10 durch Ihre eigene Adresse. Bei einem Anschluss mit wechselnder Adresse ist das unpraktisch, der bessere Weg steht weiter unten. Die vollständige Anleitung samt Rettungsweg finden Sie unter UFW-Firewall einrichten, ohne sich selbst auszusperren.

Die Datenbank gehört in keinem Fall ins offene Netz. Prüfen Sie in /etc/mysql/mariadb.conf.d/50-server.cnf, dass dort steht:

bind-address = 127.0.0.1

3. Den Query-Port und die HTTP-Endpunkte absichern

Der FXServer beantwortet auf dem TCP-Anteil von 30120 HTTP-Anfragen, ohne dass jemand das Spiel starten muss. Sehen Sie sich an, was er dort ausliefert:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600

/players.json listet die verbundenen Spieler samt ihrer Kennungen. Das ist praktisch für Statusseiten und Discord-Bots, aber auch eine Einladung: Der Endpunkt lässt sich beliebig oft abfragen, jede Abfrage kostet Ihren Server Arbeit, und der Inhalt verrät einem Angreifer, wann sich ein Angriff lohnt. Zwei Gegenmaßnahmen kosten nichts. Erstens gehören die Endpunkte der Spieler nicht in die Antwort, dafür genügt eine Zeile in der server.cfg:

sv_endpointPrivacy true

Zweitens: Wenn Ihr Discord-Bot oder Ihre Webseite den Spielerstand anzeigt, fragen Sie den Endpunkt nicht vom Besucher aus ab, sondern speichern Sie das Ergebnis in festen Abständen zwischen. Damit erzeugt eine viel besuchte Statusseite eine Abfrage pro Intervall statt einer pro Besucher.

4. txAdmin nicht ins offene Netz stellen

Port 40120 ist eine Weboberfläche mit vollem Zugriff auf Ihren Server. Ohne feste IP-Adresse für die Freigabe lassen Sie den Port von außen zu und erreichen ihn über einen SSH-Tunnel, danach öffnen Sie lokal http://127.0.0.1:40120:

ssh -N -L 40120:127.0.0.1:40120 root@IHRE.SERVER.IP.ADRESSE

5. Verbindungs- und Paketraten begrenzen

Gegen kleine Angriffe und unsaubere Bots hilft eine Obergrenze je Quelladresse:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name fivem_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

Die erste Regel verwirft neue TCP-Verbindungen, sobald eine Adresse mehr als zwölf davon gleichzeitig offen hat, die zweite UDP-Pakete ab dauerhaft mehr als 600 Paketen pro Sekunde aus derselben Quelle. Beide Zahlen sind Startwerte, keine Wahrheiten: Ein voller RP-Server erzeugt deutlich mehr Pakete als ein leerer, und wer zu eng einstellt, wirft eigene Spieler heraus. Messen Sie erst eine Woche im Normalbetrieb.

Zwei Hinweise dazu. Reine iptables-Regeln sind nach einem Neustart weg, unter Debian und Ubuntu sichert man sie so:

apt-get install -y iptables-persistent
netfilter-persistent save

Und unter UFW gehören solche Regeln in /etc/ufw/before.rules, weil sie sonst beim nächsten ufw reload verschwinden. Ein oft übersehener Engpass ist außerdem die Verbindungsverfolgung des Kernels: Läuft sie voll, verwirft der Server auch legitime Pakete, und im Protokoll steht "nf_conntrack: table full". Stand und Obergrenze zeigt:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

6. Der Eintrag in der Serverliste

Hier lohnt sich Ehrlichkeit statt Wunschdenken: Ihre IP-Adresse lässt sich nicht geheim halten. Jeder Spieler, der einmal verbunden war, kennt sie, und der Listeneintrag veröffentlicht sie ohnehin. Wer den öffentlichen Eintrag nicht braucht, weil das Projekt rein über Discord und Direktverbindung läuft, kann ihn mit sv_master1 "" abschalten. Das kostet allerdings sämtliche Sichtbarkeit für neue Spieler und hilft nur gegen den bequemsten aller Angreifer.

Wirksamer sind zwei Gewohnheiten. Veröffentlichen Sie die rohe IP-Adresse nirgends selbst, also nicht im Discord-Kanal und nicht auf der Projektseite. Und verbinden Sie Ihre Spieler über einen Hostnamen, damit Sie im Ernstfall die Adresse wechseln können, ohne dass alle Verweise brechen. Der Klassiker sind dabei alte DNS-Einträge: Ein vergessener A-Eintrag auf die vorherige Adresse macht jeden Wechsel wirkungslos.

7. Whitelist und Beitrittsprüfung

Eine Whitelist wirkt gegen alles, was den regulären Beitrittsweg nutzt: Trolle, Cheat-Clients, Botnetze aus Wegwerf-Konten. Umgesetzt wird sie serverseitig im Ereignis playerConnecting, wo Sie die Verbindung mit den Deferrals-Funktionen anhalten, die Kennung prüfen und erst danach freigeben. Dazu kommen eine strenge Kontoprüfung, eine realistische Spielerobergrenze und ein deaktiviertes ScriptHook:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 48
sv_scriptHookAllowed 0

Ein RCON-Passwort setzen Sie nur, wenn Sie RCON brauchen, denn der Zugang liegt auf demselben offenen Port. Und eines muss klar sein: 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.

8. Netzwerkereignisse serverseitig prüfen

Viele Ausfälle, die als DDoS-Angriff gemeldet werden, gehen auf ein einzelnes Skript zurück. FiveM-Ressourcen kommunizieren über Netzwerkereignisse, und ein Ereignis, das der Server ungeprüft ausführt, ist eine offene Tür: Wer im Client ein TriggerServerEvent mit beliebigen Werten absetzt, kann Geld erzeugen, Fahrzeuge spawnen oder in einer Schleife Datenbankabfragen auslösen, bis der Server steht.

Drei Regeln fangen den Großteil davon ab. Registrieren Sie mit RegisterNetEvent ausschließlich Ereignisse, die wirklich vom Client kommen sollen. Verlassen Sie sich nie auf Werte, die der Client mitschickt, sondern ermitteln Sie den Spieler serverseitig aus source. Und begrenzen Sie, wie oft ein Spieler dasselbe Ereignis auslösen darf, gerade bei allem mit Datenbankabfrage. Ruckelt der Server, während die Leitung ruhig ist, zeigt resmon 1 in der Clientkonsole die Rechenzeit je Ressource, und meist steht der Schuldige ganz oben.

9. Protokollieren, damit Sie im Ernstfall Daten haben

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 pro Sekunde viel waren oder einfach Dienstagabend. Mit apt-get install -y vnstat sysstat läuft die Messung dauerhaft mit. Während eines Vorfalls genügen vier Befehle: Paketraten je Sekunde, Verwurfsrate der Schnittstelle, Kernelmeldungen und eine kurze Stichprobe des Verkehrs.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -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, steht in DDoS-Angriff erkennen.

Wo diese Maßnahmen aufhören

Jetzt der Teil, den keine Konfigurationsdatei lösen kann. 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 pro Sekunde, und die Leitung ist voll, sobald jemand mehr schickt. Angriffe gegen FiveM-Projekte liegen üblicherweise zwischen 5 und 50 Gbit/s, also beim Fünf- bis Fünfzigfachen Ihrer Leitung. Ob Ihre iptables-Regel dahinter gut ist, spielt dann keine Rolle mehr, denn die Pakete Ihrer Spieler kommen schon vorher nicht durch.

Die zweite Größe ist die Paketrate, und sie schlägt oft 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 pro 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 pro 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. Das Rechenzentrum ist maincubes in Frankfurt am Main, Deutschland. 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 und ohne Mindestlaufzeit. 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 ein, was auf 30120 UDP erlaubt ist und was auf 30120 TCP, ohne dafür ein Ticket zu schreiben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren.
• Schutzprofil passend zum jeweiligen Spiel. Für FiveM gibt es ein fertiges Profil, ebenso für modifizierte und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Die beiden Stufen im Vergleich

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

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

"Meine iptables-Regeln greifen nicht": Drei Ursachen sind häufig. Die Regeln stehen hinter den UFW-Ketten und werden nie erreicht, sie waren nach dem letzten Neustart weg (dann helfen netfilter-persistent save oder ein Eintrag in /etc/ufw/before.rules), oder der Angriff ist volumetrisch und die Regel arbeitet korrekt an einer Leitung, die schon voll ist. Prüfen Sie mit iptables -L INPUT -n -v, ob die Trefferzähler steigen. Bleiben sie bei null, wird die Regel nicht erreicht.

"Der Server läuft, aber alle Spieler haben Gummiband-Effekte": Das ist häufiger ein Skript als ein Angriff. Sehen Sie zuerst mit resmon 1 nach, ob eine Ressource die Rechenzeit auffrisst. Bleibt sar -n DEV 1 10 unauffällig, war es kein DDoS-Angriff.

"txAdmin zeigt hunderte fehlgeschlagene Verbindungsversuche": Das ist ein Beitritts-Flood und trifft die Spiellogik, nicht die Leitung. Dagegen wirken Whitelist, Kontoprüfung und die Verbindungsobergrenze je Quelladresse.

"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

Schließen Sie alles außer 30120 TCP und UDP, halten Sie txAdmin und die Datenbank aus dem offenen Netz heraus, begrenzen Sie Verbindungen und Paketraten je Quelladresse, führen Sie eine Whitelist und prüfen Sie Netzwerkereignisse serverseitig. Damit sind Sie gegen alles gewappnet, was ohne nennenswerte Bandbreite auskommt. Darüber hinaus entscheidet ausschließlich das Netz vor dem Server.

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.