RedM-Server vor DDoS-Angriffen schützen

Ein RedM-Server, der abends mitten in der Session verschwindet und zehn Minuten später wieder auftaucht, hat selten ein Hardwareproblem. Meistens läuft ein Angriff auf Port 30120, und er läuft genau dann, wenn die meisten Spieler online sind. Dieser Beitrag zeigt, wie Sie einen RedM-Server vor DDoS-Angriffen schützen: zuerst das, was Sie ohne Zusatzkosten selbst absichern können, danach die physikalische Grenze dieser Maßnahmen, und zum Schluss, was im Netz vor dem Server passieren muss, wenn der Angriff größer ist als Ihre Leitung.

Alle Angaben beziehen sich auf einen FXServer mit gamename rdr3 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. RedM ist die Red-Dead-Redemption-2-Modifikation von Cfx.re und das Schwesterprojekt von FiveM. Beide laufen auf demselben Serverprogramm, weshalb ein Teil der Netzwerktechnik wirklich identisch ist. Wo das zutrifft, steht es hier in einem Satz und der ausführliche Teil im Beitrag FiveM-Server vor DDoS-Angriffen schützen. Alles Übrige in diesem Text ist RedM-spezifisch.

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

Warum RedM-Server so oft Ziel von DDoS-Angriffen werden

Ein RedM-Server ist ein lohnenderes Ziel, als seine Spielerzahl vermuten lässt. Der Grund ist die Größe der Szene, nicht ihre Kleinheit. Im September 2026 zählten öffentliche Serverlisten-Tracker rund 2.000 aktive RedM-Server mit etwa 12.400 gleichzeitigen Spielern, gegenüber rund 39.000 FiveM-Servern mit etwa 325.000 Spielern. Wer einen von 2.000 RedM-Servern lahmlegt, nimmt damit einen deutlich größeren Anteil der gesamten Szene vom Netz als jemand, der einen von 39.000 FiveM-Servern trifft. Für einen Angreifer, der einem Konkurrenzprojekt schaden will, ist der Hebel also ungleich größer.

Dazu kommt die Struktur der Communities. RedM-Roleplay lebt von festen Sessions zu festen Uhrzeiten, oft mit Anmeldung und Charakterfreigabe. Ein Ausfall um 20 Uhr trifft nicht irgendwelche Spieler, sondern genau die, die sich für diesen Abend angemeldet haben. Viele Projekte laufen zudem als Hobby mit kleinem Budget, hängen an einem einzelnen günstigen Server und haben keine zweite Instanz, auf die man umschalten könnte. Öffentlich dokumentierte Fälle aus der RedM-Szene beschreiben Angriffsserien über Monate im nahezu täglichen Takt, die den Spielserver und den separaten Voice-Server gleichzeitig getroffen haben.

Technisch kommt hinzu, dass der Spielverkehr über UDP läuft. UDP ist ein verbindungsloses Transportprotokoll: Es gibt keinen Verbindungsaufbau, den der Server verlangen könnte, und Absenderadressen lassen sich fälschen. Ein Angreifer muss Ihren RedM-Server also weder betreten noch korrekt ansprechen, um Last zu erzeugen. Was ein DDoS-Angriff genau ist und wie er aufgebaut wird, erklärt der Beitrag Was ist ein DDoS-Angriff?.

Die Ports, um die es tatsächlich geht

Ein RedM-Server bindet sich standardmäßig auf einen einzigen Port, und zwar auf beiden Protokollen. In der server.cfg steht dafür:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
set gamename rdr3
sv_enforceGameBuild 1491
sv_licenseKey "cfxk_..."

Die Zeile set gamename rdr3 ist die einzige, die einen RedM-Server von einem FiveM-Server unterscheidet. Fehlt sie, meldet sich derselbe FXServer als GTA-V-Server an, und ein RedM-Client verbindet sich nicht. RedM hat keinen eigenen Query-Port und keinen eigenen RCON-Port: Serverabfrage, Verbindungsaufbau, Spielverkehr und RCON laufen alle über dieselben beiden Einträge auf 30120. Das ist die harte Zahlenlage:

Von den vier genannten Ports gehören genau zwei ins offene Netz: 30120 TCP und 30120 UDP. Port 40120 und Port 3306 gehören dort nicht hin, und SSH auf Port 22 sollte auf die eigenen Adressen beschränkt sein. Das ist der häufigste vermeidbare Fehler auf RedM-Servern, weil viele Projekte mit einem fertigen txAdmin-Rezept starten und danach nie prüfen, was der Server nach außen anbietet.

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

Dieser Abschnitt ist der längste, und das mit Absicht. Ein sauber konfigurierter RedM-Server hält kleine und mittlere Angriffe aus eigener Kraft aus, unabhängig davon, bei wem er steht. Die Reihenfolge ist bewusst gewählt: Sie messen zuerst, schließen dann und begrenzen erst danach.

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 FXServer tauchen auf einem RedM-Server regelmäßig txAdmin auf 40120, MariaDB auf 3306, ein Webserver für die Projektseite und gelegentlich ein 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 30120 TCP und UDP offen lassen

Für RedM 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 'RedM'
ufw allow 30120/udp comment 'RedM'
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 im nächsten Abschnitt zu txAdmin. 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. VORP, RSGCore und RedEM:RP brauchen alle eine MariaDB oder MySQL, meist über oxmysql mit einer Verbindungszeichenfolge in der server.cfg. Diese Verbindung läuft lokal, der Port muss also nicht von außen erreichbar sein. Prüfen Sie in /etc/mysql/mariadb.conf.d/50-server.cnf, dass dort steht:

bind-address = 127.0.0.1

3. Die HTTP-Endpunkte des FXServer absichern

Der FXServer beantwortet auf dem TCP-Anteil von 30120 HTTP-Anfragen, ohne dass jemand Red Dead Redemption 2 starten muss. Sehen Sie sich an, was Ihr RedM-Server 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
curl -s http://127.0.0.1:30120/dynamic.json

/players.json listet die verbundenen Spieler samt ihrer Kennungen, /info.json die Serverkonfiguration und die geladenen Ressourcen, /dynamic.json die aktuelle Belegung. Genau diese drei Endpunkte sind der dokumentierte Layer-7-Angriffsweg gegen FiveM- und RedM-Server: Sie sind ohne Anmeldung erreichbar, lassen 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

Diese Einstellung verbirgt die IP-Adressen Ihrer Spieler in den öffentlichen Ausgaben des Servers. Zweitens: Wenn Ihr Discord-Bot oder Ihre Projektseite 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. Bei einer kleinen Szene wie RedM fällt das doppelt ins Gewicht, weil ein einzelner Serverstatus-Bot in mehreren Discord-Servern gleichzeitig eingebunden sein kann.

4. txAdmin auf Port 40120 aus dem offenen Netz nehmen

txAdmin ist die Verwaltungsoberfläche, die im FXServer-Build für FiveM und RedM enthalten ist, und sie lauscht standardmäßig auf 40120 TCP. Dahinter liegt der volle Zugriff auf Ihren Server: Neustarts, Bannliste, Spielerdatenbank, Ressourcenverwaltung. Ohne feste IP-Adresse für die Freigabe lassen Sie den Port von außen zu und erreichen ihn über eine lokale Portweiterleitung mit SSH, danach öffnen Sie im Browser http://127.0.0.1:40120:

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

Wer txAdmin öffentlich stehen lässt, bekommt zwei Probleme auf einmal: eine Anmeldemaske, gegen die sich Anmeldefluten fahren lassen, und einen Dienst, der bei jeder Anfrage Arbeit leistet, obwohl er mit dem Spiel nichts zu tun hat. Im Zweifel binden Sie txAdmin gleich lokal, indem Sie den Dienst nur auf 127.0.0.1 lauschen lassen.

5. Verbindungs- und Paketraten je Quelladresse begrenzen

Gegen kleine Angriffe und unsaubere Bots hilft eine Obergrenze je Quelladresse. Die beiden Regeln gelten für 30120, also für beide Protokolle des Spiels:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 8 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name redm_udp --hashlimit-mode srcip --hashlimit-above 500/sec --hashlimit-burst 750 -j DROP

Die erste Regel verwirft neue TCP-Verbindungen, sobald eine Adresse mehr als acht davon gleichzeitig offen hat, die zweite UDP-Pakete ab dauerhaft mehr als 500 Paketen pro Sekunde aus derselben Quelle. Die Startwerte liegen hier etwas niedriger als bei einem FiveM-Server, weil ein RedM-Server mit 32 Slots schlicht weniger legitime Verbindungen je Adresse erzeugt. Startwerte sind aber keine Wahrheiten: Ein voller RP-Abend erzeugt deutlich mehr Pakete als ein leerer Server, 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. Die 32 Slots gegen Beitritts-Fluten absichern

Ein RedM-Server hat ohne OneSync genau 32 Slots. Mit OneSync sind es 48, darüber hinaus braucht es ein Element-Club-Abonnement für bis zu 1.024 Plätze. Diese Zahl ist sicherheitsrelevant, denn sie ist die Obergrenze, die ein Angreifer füllen muss: Wer 32 Beitrittsversuche gleichzeitig offen hält, belegt einen Standardserver vollständig, ohne dass ein einziger Spieler tatsächlich im Spiel ankommt. Bei einem FiveM-Projekt mit 128 Plätzen ist dieselbe Schwelle viermal so hoch.

Ein RedM-spezifischer Vorteil gleicht das teilweise aus: RedM setzt eine echte Kopie von Red Dead Redemption 2 voraus, egal ob über Steam, Epic Games oder Rockstar gekauft, dazu den Rockstar-Launcher. Ein Beitritts-Flood mit tausenden Wegwerf-Konten, wie er bei kostenlosen Spielen üblich ist, kostet hier also echtes Geld. Angriffe verschieben sich dadurch auf die Netzwerkebene und auf die HTTP-Endpunkte, wo keine Spielkopie nötig ist.

Gegen alles, was den regulären Beitrittsweg nutzt, wirkt trotzdem eine Whitelist. 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 und eine realistische Spielerobergrenze:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 32

sv_authMaxVariance ist ein Wert von 1 bis 5 und gibt an, wie stark sich die Kennung eines Spielers bei einem Anbieter ändern darf; 1 ist die strengste Einstellung. sv_authMinTrust läuft ebenfalls von 1 bis 5 und beschreibt, wie unwahrscheinlich eine gefälschte Identität sein muss; 5 ist hier der strengste Wert. Ein RCON-Passwort setzen Sie nur, wenn Sie RCON wirklich brauchen, denn der Zugang liegt auf demselben offenen Port 30120. 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.

7. Den Eintrag in der RedM-Serverliste richtig einschätzen

Hier lohnt sich Ehrlichkeit statt Wunschdenken: Ihre IP-Adresse lässt sich nicht geheim halten. RedM nutzt dieselbe Cfx.re-Masterserver-Infrastruktur wie FiveM, und der Listeneintrag enthält im Feld connectEndPoints den Verbindungsendpunkt im Klartext. Über die öffentliche Schnittstelle unter servers-frontend.fivem.net lässt sich zu jedem cfx.re-Code die zugehörige Adresse abfragen, für RedM genauso wie für FiveM. Wer den öffentlichen Eintrag gar nicht braucht, weil das Projekt rein über Discord und Direktverbindung läuft, kann den Server mit sv_master1 "" als privat führen: Er ist dann über die Serverliste nicht mehr beitretbar. Das kostet allerdings sämtliche Sichtbarkeit für neue Spieler, und in einer Szene mit 2.000 Servern ist Sichtbarkeit der eigentliche Wachstumsmotor.

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.

8. VORP-, RSGCore- und RedEM-Ereignisse serverseitig prüfen

Viele Ausfälle, die als DDoS-Angriff gemeldet werden, gehen auf ein einzelnes Skript zurück. RedM-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 Dollar erzeugen, Pferde spawnen oder in einer Schleife Datenbankabfragen auslösen, bis der Server steht. Das trifft alle drei verbreiteten Frameworks gleichermaßen: VORP Core, das seit 2020 die größte Skriptbasis hat, RSGCore und das ältere RedEM:RP.

Besonders anfällig sind die Inventar- und Charakterressourcen, weil sie bei jedem Aufruf in die Datenbank schreiben. Eine Ereignisschleife, die zehn Mal pro Sekunde einen Inventarstand speichert, belastet einen RedM-Server stärker als mancher Paketflut, und sie kommt von innen, wo keine Firewall greift.

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. Messwerte sammeln, bevor Sie sie brauchen

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 ein gut besuchter 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. Achten Sie außerdem darauf, ob die Last auf dem UDP- oder auf dem TCP-Anteil von 30120 liegt. UDP-Last deutet auf eine Paketflut gegen den Spielverkehr hin, TCP-Last auf eine Flut gegen die HTTP-Endpunkte, und beide brauchen unterschiedliche Gegenmaßnahmen. Wie Sie die Werte auswerten, steht in DDoS-Angriff erkennen.

Wo diese Maßnahmen aufhören

Jetzt der Teil, den keine server.cfg 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 Roleplay-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 RedM-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". Genau diese Lag-Spikes ohne sichtbare Serverlast sind das typische Erscheinungsbild eines Paketraten-Angriffs.

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 bei RedM anders ist als bei FiveM

Die kurze Antwort: die Netzwerktechnik ist identisch, das Umfeld nicht. Beide laufen auf demselben FXServer, beide nutzen 30120 TCP und UDP, beide werden über txAdmin auf 40120 verwaltet. Alles, was Sie oben über Ports, Raten und Endpunkte lesen, gilt für beide. Unterschiedlich sind die Rahmenbedingungen, und genau die entscheiden, wie schnell ein Angriff wirkt:

Drei Punkte aus dieser Tabelle sind für die Abwehr entscheidend. Erstens macht die kleinere Szene jeden einzelnen RedM-Server wertvoller als Ziel, weil ein Ausfall einen größeren Anteil der Spieler betrifft. Zweitens senkt die Standardgrenze von 32 Slots die Schwelle, ab der eine Beitritts-Flut den Server dichtmacht. Und drittens finden sich für RedM weniger fertige Schutzrezepte im Netz als für FiveM, weshalb viele Projekte mit einer unveränderten Standardkonfiguration laufen. Die Abwehr ist dieselbe, der Ausgangszustand ist schlechter.

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 RedM-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. Standort der Filterung 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 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 getrennt ein, was auf 30120 UDP erlaubt ist und was auf 30120 TCP, ohne dafür ein Ticket zu schreiben. Gerade bei RedM ist diese Trennung nützlich, weil Spielverkehr und HTTP-Endpunkte auf derselben Portnummer liegen und völlig unterschiedliche Muster haben.
• Änderungen greifen in Echtzeit, Sie können also während eines laufenden Angriffs nachjustieren.
• Schutzprofil passend zur Anwendung. Für Cfx.re-Server auf 30120 gibt es ein passendes Profil, ebenso für modifizierte und eigene Anwendungen auf beliebigen TCP- oder UDP-Ports.

Beides gilt für Server, die bei KernelHost stehen. Wenn Ihr RedM-Projekt derzeit woanders läuft und regelmäßig aus dem Netz geschossen wird, ist der Umzug die Empfehlung, nicht ein zusätzliches Produkt.

Die beiden Stufen im Vergleich

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

"Mein Server taucht in der RedM-Serverliste nicht auf, ich vermute einen Angriff": Prüfen Sie zuerst die Konfiguration. Fehlt set gamename rdr3, meldet sich der FXServer als GTA-V-Server an und erscheint nicht in der RedM-Liste. Fehlt oder stimmt der Lizenzschlüssel aus portal.cfx.re nicht, kommt der Eintrag ebenfalls nicht zustande. Ein Angriff sieht anders aus: Der Eintrag bleibt bestehen, die Verbindung scheitert.

"Hunderte Spieler bekommen einen Fehler beim Beitritt, das sieht aus wie eine Flut": Meist ist es ein Spielstand-Problem. Passt sv_enforceGameBuild nicht zu dem, was Ihre Ressourcen erwarten, meldet der Client "server specified an invalid game enforcement". Setzen Sie den Wert, den Ihr Framework verlangt, üblicherweise 1436 oder 1491, und starten Sie den Server vollständig neu.

"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, und prüfen Sie die Inventar- und Charakterressourcen Ihres Frameworks. Bleibt sar -n DEV 1 10 unauffällig, war es kein DDoS-Angriff.

"txAdmin zeigt hunderte fehlgeschlagene Verbindungsversuche": Das ist eine Beitritts-Flut und trifft die Spiellogik, nicht die Leitung. Dagegen wirken Whitelist, Kontoprüfung über sv_authMinTrust 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

• Ein RedM-Server braucht genau zwei offene Ports: 30120 TCP und 30120 UDP, gesetzt über endpoint_add_tcp und endpoint_add_udp. Einen eigenen Query-Port oder RCON-Port gibt es nicht.
• txAdmin auf 40120 TCP und die Datenbank auf 3306 TCP gehören nicht ins offene Netz, sondern auf die eigene Adresse beziehungsweise auf 127.0.0.1.
• sv_endpointPrivacy true nimmt die Spieler-IP-Adressen aus den öffentlichen Ausgaben, und ein zwischengespeicherter Serverstatus nimmt Last von /players.json, dem dokumentierten Layer-7-Angriffsweg gegen Cfx.re-Server.
• Ein RedM-Server hat ohne OneSync 32 Slots, mit OneSync 48 und mit Element Club bis 1.024. Je kleiner die Slotzahl, desto billiger ist eine Beitritts-Flut, und desto wichtiger sind Whitelist und Kontoprüfung.
• RedM und FiveM laufen auf demselben FXServer, unterschieden allein durch set gamename rdr3. Die Netzwerkabwehr ist deshalb identisch, das Umfeld nicht: rund 2.000 RedM-Server gegenüber rund 39.000 FiveM-Servern machen jedes einzelne RedM-Projekt zum wertvolleren Ziel.
• Lokale Firewall-Regeln enden dort, wo die Leitung voll ist: 1 Gbit/s sind 125 Megabyte pro Sekunde, und bei 64 Byte großen Paketen passen rund 1,49 Millionen Pakete pro Sekunde hinein. Alles darüber muss im Netz vor dem Server enden.
• Bei KernelHost ist der zweistufige Dauerschutz in jedem Serverpaket enthalten, ab Bereitstellung aktiv und ohne Nullrouting. Wer die Filterung selbst steuern will, bekommt mit der Advanced DDoS Protection ab 50,00 EUR im Monat eine dedizierte Schutz-IP und eigene Regeln je Port und Protokoll.

Läuft Ihr RedM-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.