FiveM Server schützen 2026 — Operator-Hardening-Guide mit offiziellen Quellen

Ein FiveM-Server ist ein laufender Gameserver, plus ein Haufen Lua-Code, plus eine MySQL-Datenbank, plus ein Discord im Backend, plus ein Admin-Panel. Jede dieser Schichten hat 2026 eine eigene Angriffsoberfläche — und jede ist schon öffentlich kompromittiert worden. Dieser Post ist kein Marketing-Copypaste aus einem Hosting-Blog. Jeder Punkt steht mit Quelle.

Zielgruppe: Operator, die selbst administrieren — von 32-Slot bis 300-Slot — und die wissen wollen, was vor dem Anti-Cheat passieren muss, damit ein Anti-Cheat überhaupt greift.

Die Angriffsoberfläche

Vier Schichten, auf denen ein FiveM-Server wirklich lebt: Cfx.re-Plattform, Server-Host, Resource-Code und Admin-Zugänge. Historisch ist jede davon öffentlich gebrochen worden. Der Cfx.re-Forum-Breach vom November 2022 zeigt die Plattform-Ebene. Das Asset-Security-Update vom August 2025 zeigt die Resource-Ebene. CVE-2024-46310 in FXServer ≤ v9601 zeigt die Host-Ebene. Discord-Token-Stealer wie RedLine und Stealc zeigen die Admin-Ebene.

Wer nur eine Schicht absichert, verliert an der nächsten. Kein Cheat muss eine Backdoor öffnen, wenn der Owner-Discord bereits durch einen Token-Stealer kompromittiert wurde — die Backdoor ist dann schon da.

Was Operator wirklich trifft

Fünf Angriffsvektoren, die zwischen 2022 und 2026 dokumentiert in die Community eingeschlagen sind. Jede Karte mit Primärquelle.

Event-Sicherheit: die Cfx.re-Basis

Bevor irgendein Anti-Cheat greift, muss Server-Code „safe by default" sein. Die offizielle Server-Security-Dokumentation definiert drei harte Regeln:

1. AddEventHandler für Same-Context, RegisterNetEvent für Cross-Context. Nur Events mit RegisterNetEvent sind vom Client aus triggerbar — alles andere muss AddEventHandler bleiben. Das schließt eine ganze Klasse von Exploits von vornherein aus.

2. Source-Validierung bei Same-Context-Events. Konkrete Code-Empfehlung der Docs: if source ~= 65535 then return end in Events, die ausschließlich server-intern laufen sollen. Wer diesen Guard weglässt, hat einen Event, den ein Cheat triggern kann, obwohl der Name nach „interner Event" aussieht.

3. Input-Validation server-seitig. Offizielles Zitat: „make sure to retrieve all values using server-side methods, not allowing players to change the values." Alles was Geld, Items, Permissions, State, Position oder Inventar betrifft, muss server-seitig gezogen und geprüft werden — nicht aus dem Event-Payload gelesen.

Dazu die beiden kanonischen Community-Guides im Cfx.re-Forum: „How hackers can exploit your servers and what to do about it" und die Liste „Vulnerable and Abused Events".

Für Datenbank-Zugriff: oxmysql mit parametrisierten Statements — nicht String-Concat. Jede SQL-Injection-Schwachstelle in FiveM-Resources der letzten Jahre war letztlich Developer-Fehler, nicht Library-Fehler.

OneSync, State Bags und Routing Buckets

OneSync ist nicht nur Performance-Feature — es ist Security-Feature. Mit aktiviertem OneSync kann der Server Entity-Ownership kontrollieren, statt sie jedem Client zu erlauben. Relevante Hooks:

• playerEnteredScope / playerLeftScope — server-seitige Events beim Betreten/Verlassen des ~424-Unit-Radius eines anderen Spielers. Basis für Distance-Checks, die der Client nicht fälschen kann.
• Routing Buckets mit strict-Lockdown — verhindert, dass Clients Entities außerhalb ihres eigenen Buckets spawnen oder sehen.
• State Bags mit Ownership-Validierung — Entity-State darf nur vom owning Player oder Server geschrieben werden; globaler State nur vom Server.

Kritische Server-Events, die server-seitig plausibilisiert werden müssen (aus der offiziellen Event-Liste):

• weaponDamageEvent — cancelbar, Damage gegen Distance und Weapon-Capabilities prüfen
• explosionEvent — Explosion-Exploits abfangen
• entityCreating — Vehicle-/Ped-Spawning vor Commit prüfen
• playerConnecting mit Deferrals — asynchrone Ban-/VPN-/Identity-Checks VOR Connect

Zusätzlich existieren zwei Convars, die direkt Angriffsoberfläche reduzieren (Server-Commands-Docs): sv_endpointPrivacy versteckt Spieler-IPs aus öffentlichen Server-Reports, sv_filterRequestControl blockiert REQUEST_CONTROL_EVENT nach konfigurierbarer Policy.

ACE-Permissions und txAdmin-Hardening

ACE-Permissions nach dem Principle of Least Privilege. Standard-Syntax aus den offiziellen Server-Commands-Docs:

add_ace group.admin command.ban allow
add_principal identifier.fivem:12345 group.admin

Nie pauschale command- oder .all-Rechte. Gruppen statt Einzel-Identifier. Ex-Admins explizit remove_principal beim Ausscheiden — sonst bleibt der Zugriff auch nach Discord-Role-Entzug bestehen.

txAdmin ist seit FXServer-Build ≥ 2524 Teil der offiziellen Distribution (Docs), Default-Port TCP 40120. Security-relevante Konfiguration (txAdmin env-config, Security-Overview):

• 2FA auf dem Cfx.re-Account aktivieren. Der txAdmin-Login über Cfx.re ist nur so sicher wie der darunter liegende Account — siehe 2022-Forum-Breach.
• Bcrypt-Master-Backup-Passwort aktiv lassen. Recovery-Weg, wenn Cfx.re-Login ausfällt.
• 40120 NICHT öffentlich exponieren. Reverse-Proxy mit TLS + IP-Allowlist oder WireGuard-Tunnel. Ein txAdmin-Panel, das als http://<server-ip>:40120 im offenen Netz steht, ist ein Fund für jede automatisierte Scan-Engine.

Cfx.re-Security-Advisory-Historie zur Einschätzung des Prozesses: Security Advisory 2019-01-02 (RCon-DoS) inklusive historischer iptables-Workaround-Regel. Meldewege über die offizielle SECURITY.md: [email protected] oder CFX-Support-Formular, SLA „review and respond within 24 hours."

Artifact-Update-Workflow

Cfx.re liefert FXServer-Artifacts mit den Labels „recommended" und „optional" — die offizielle Forum-Empfehlung sagt aber klar, dass diese Labels aktuell nicht zuverlässig gepflegt werden. Zitat: „Marking an older version as 'optional' has no benefit at this point and the label is just a leftover."

Praktische Konsequenz für Operator:

1. Eigenes Staging betreiben. Neue Artifacts zuerst auf einem Test-Server hochziehen, dort 24 h gegen den Resource-Stack laufen lassen.
2. Auto-Deploy-Script für Linux kennen — für geplante Updates, aber mit Staging davor.
3. Cfx.re-Announcements per RSS abonnieren, nicht nur „wenn Probleme auftauchen".
4. Alte Builds nicht aus Bequemlichkeit halten — der RCon-DoS von 2019 wurde in Build 960 gefixt. Wer auf älteren Builds sitzt, hat bekannte Exploits live.

DDoS-Realismus

Drei harte Wahrheiten, jeweils mit Anbieter-Primärquelle:

1. Hetzner-Standard-Protection ist unzureichend gegen ernsthafte Angriffe. Aussage direkt aus dem offiziellen Hetzner-Game-Server-Tutorial. Wer bei Hetzner hostet und mit >10 Gbps-Angriffen rechnet, braucht zusätzlich Game-DDoS-Protection.
2. OVHcloud Game DDoS Protection ist laut Produktseite Bestandteil der 3rd-Gen-Bare-Metal-Game-Server seit 2024. GRE-Tunnel-Setups erfordern Whitelisting via Flexrules, siehe Support-Artikel.
3. Cloudflare Spectrum ist Enterprise-Feature und nutzt ein eigenes Simple-Proxy-Protokoll für Client-IP-Übertragung — dein FiveM-Server muss diesen Header lesen können, sonst siehst du die Cloudflare-Edge-IP statt des Spielers.

Discord-Security

Die überwiegende Mehrheit aller FiveM-Operator fährt Discord als Admin-Backbone. Damit wird der Discord-Account zum kritischsten Single-Point-of-Failure — noch vor dem txAdmin-Panel.

Minimum-Setup für Admin-Accounts:

• 2FA mit Authenticator-App — nicht SMS — auf Discord, Cfx.re und Hosting-Panel.
• Admin-Rechner getrennt vom Gaming-/Download-Rechner. Ja, wirklich. Die überwiegende Mehrheit der dokumentierten Stealc-Kampagnen laufen über gecrackte Software, Discord-Invites mit Malware-Archiven und malicious npm-Packages.
• Discord-Bots nur mit minimalen OAuth2-Scopes. Ein Bot mit „Administrator"-Permission ist effektiv Owner-Zugriff — inklusive bei Bot-Kompromittierung.
• MessageContent-Intent nur aktivieren, wenn der Bot wirklich Message-Parsing braucht. Jeder Bot, der ohne MessageContent auskommt, sollte ohne laufen.

Invite-Link-Hijacking ist laut Kaspersky ein aktiver Vektor — abgelaufene Invites werden neu registriert und Malware-Archive darüber verlinkt. Wer alte Discord-Invite-Links in Tutorials oder Pins stehen hat, sollte sie rotieren.

DSGVO für Operator

Kurze, konkrete Rechtsbasis für Server-Logging, IP-Speicherung und Ban-Listen:

• IP-Logging als Sicherheitsmaßnahme — Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse). Praxisleitfaden: Thomas Helbing — Berechtigtes Interesse. Interessenabwägung im Einzelfall, Retention begrenzen, Datenminimierung.
• § 25 TDDDG regelt Zugriff auf Endgeräte (Cookies, ähnliche Technologien). IPs, die im Verbindungsaufbau implizit anfallen, fallen nicht unter § 25 TDDDG — nur unter DSGVO. Gesetzestext.
• AVV mit jedem Anti-Cheat-Anbieter. Art. 28 DSGVO. Ohne gültigen AVV ist die Weitergabe von IP + HWID + Verhaltensdaten an einen Anti-Cheat-Cloud-Dienst datenschutzrechtlich nicht sauber.
• Privacy Policy muss Ban-Listen und VPN-Erkennung explizit nennen, inklusive Retention-Fristen pro Datenkategorie.

Operator-Checkliste

1. Alle RegisterNetEvent-Handler auditieren. Jeder ohne server-seitige Input-Validation ist ein offener Exploit-Vektor.
2. oxmysql mit Prepared Statements, kein String-Concat. Resources, die noch concatenieren, sind SQL-Injection-verdächtig.
3. txAdmin 40120 hinter Reverse-Proxy + IP-Allowlist. Nicht öffentlich exponieren.
4. 2FA auf Cfx.re, Discord, Hosting-Panel. Authenticator-App, nicht SMS.
5. Admin-Rechner sauber halten. Keine gecrackte Software, keine unvalidierten npm-Packages auf Dev-Maschinen, Discord-Desktop getrennt von Test-/Cheat-Umgebungen.
6. Layer-3/4-DDoS-Protection einplanen, sobald der Server öffentlich sichtbar ist. Hetzner-Standard reicht nicht — Aussage des Anbieters selbst.
7. MySQL-Backups automatisieren. QBCore-Backup-Guide als Referenz, aber Prinzip gilt für jedes Framework: geplanter Dump, off-site Kopie, regelmäßiger Restore-Test.
8. ACE-Permissions regelmäßig auditieren. Ex-Admins remove_principal. Keine Wildcard-Permissions.
9. Artifact-Updates staged deployen. Das Recommended-Label ist laut Cfx.re selbst nicht verlässlich — eigenes Staging ist nicht optional.
10. AVV mit Anti-Cheat-Anbieter. Ohne Art. 28 DSGVO kein Anti-Cheat-Cloud-Dienst für EU-Operator.

Fazit

Einen FiveM-Server 2026 zu schützen heißt nicht, den teuersten Anti-Cheat zu kaufen. Es heißt, vier Schichten nicht zu ignorieren: Plattform-Hygiene (2FA, saubere Admin-Rechner), Code-Hygiene (Event-Validation, ACE-Permissions), Host-Hygiene (Artifact-Updates, DDoS-Kapazität) und Datenschutz-Hygiene (AVV, Retention). Jeder dieser Punkte ist öffentlich dokumentiert — von Cfx.re selbst, von GitHub-PRs, von Threat-Intel-Anbietern. Die meisten dokumentierten Incidents sind nicht an neuen Exploits gescheitert, sondern an einer dieser vier Basishygienen.

Erst wenn die Basis sitzt, macht ein Anti-Cheat-Layer oben drauf Sinn — nicht umgekehrt. hoaxeye ist genau dafür gebaut: Cloud-Detection, DSGVO-konforme AVV, vier unabhängige Signal-Ebenen, Update-Kadenz am Cheat, nicht am Quartal. Aber ohne die hier beschriebene Grundhygiene ist jeder Anti-Cheat — egal welcher — nur eine teure Kontrollschicht auf einem offenen Fundament.

Quellen im Überblick

Cfx.re offiziell

• Server Security · OneSync · State Bags · Server Events · Server Commands · Asset Escrow · txAdmin · SECURITY.md

Dokumentierte Incidents

• Cfx.re-Forum-Breach 2022 · Asset Security Update 2025 · CVE-2024-46310 · Security Advisory 2019-01-02

Resource-Bugs (Live-Beispiele)

• qb-inventory PR #249 · PR #397 · qb-management Issue #94 · qb-storerobbery PR #34

DDoS-Protection

• Hetzner Game-Server-Tutorial · OVHcloud Game DDoS · Cloudflare Spectrum · Cloudflare UDP-Flood-DDoS

Token-Stealer-Analysen

• Splunk — RedLine · Netskope — RedLine via Discord · Elastic Security Labs · Sekoia — Stealc Part 1 · Malwarebytes — DiscordStealer · Kaspersky — Hijacked Discord Invites · JFrog — malicious npm

Rechtlich (DE)

• Art. 6 DSGVO · § 25 TDDDG