Sentinel: Anti-Cheat

Sentinel ist in jeder aktiven Lizenz enthalten und läuft auf jedem Server mit. Er entscheidet auf dem Server, nie im Client, und er hält eine Trennung durch, die alles andere erklärt: was der Server beweisen kann, wird sofort geahndet. Was er nur vermutet, sammelt Punkte und wird gemeldet.

#Die zwei Klassen

Klasse A ist Beweis. Der Server kennt die Wahrheit aus seinen eigenen Daten, und es gibt keine harmlose Erklärung. Läuft ein giveWeaponEvent ein, obwohl der Server niemandem eine Waffe gegeben hat, ist das kein Ping-Problem und keine Desynchronisation. Klasse A handelt sofort.

Klasse B ist Verdacht. Godmode, Noclip, Geschwindigkeit. Jede dieser Beobachtungen hat auch eine harmlose Ursache, und zwar oft: ein Skript-Teleport, ein Flugzeug, eine Wiederbelebung, ein Spieler mit 300 ms Leitung. Klasse B sammelt Punkte, verlangt zwei unabhängige Signale und sperrt nie von allein. Reicht der Punktestand, wird der Spieler geworfen, und die Sperre landet als Vorentscheidung in der Prüfstelle des Panels.

Ein Anti-Cheat, das beides gleich behandelt, sperrt entweder zu selten oder zu oft. Deshalb steht die Klasse im Regelkatalog neben jeder Regel und nicht in einer globalen Einstellung.

#Was erkannt wird

Klasse A: Spawnen von Fahrzeugen, Peds und Objekten über dem Takt, Waffen an fremde Spieler, überschriebener Waffenschaden, Treffer jenseits der Reichweite, gesperrte Explosionsarten, Explosionsserien, Massenschaden, Zugriff auf fremde Peds und Fahrzeuge, Lockvogel-Ereignisse, ausbleibender Handschlag, clientseitig gestoppte Module, Admin-Aufrufe ohne Recht, Geldsprünge ohne Buchung und Sperrumgehung über ein zweites Konto.

Klasse B: Geschwindigkeit, Teleport, Godmode, Selbstheilung, Noclip und Unsichtbarkeit.

#Was Sentinel nicht kann

Das steht hier, weil ein Anti-Cheat, das mehr verspricht als es kann, das Vertrauen beim ersten nicht erkannten Fall verbrennt.

• Menüs nur, wenn sie sich zeigen. Der Lua-Wächter von Sentinel erkennt ein Menü, das sich in seine Lua-Umgebung setzt, ein Köder-Ereignis wie esx:getSharedObject abfeuert oder einen Köder-Export aufruft. Ein Menü in einer ganz eigenen Umgebung, das nichts davon anfasst, bleibt unsichtbar. Das können die Anbieter, die mit Menü-Erkennung werben, auch nicht.
• Kein Aimbot, kein fehlender Rückstoß. Dafür bräuchte es die Zielbewegung Bild für Bild vom Client, und die zu übertragen kostet mehr, als die Erkennung wert ist.
• Kein ESP und kein Wallhack. Beide werten nur aus, was der Server ohnehin geschickt hat. Es gibt kein Signal. Die richtige Antwort ist, weniger zu schicken.
• Kein Speicherzugriff, keine Prozessliste, kein DMA. Diese Ebene deckt der Schutz von Cfx.re selbst ab. Seine Sperren sind global und ohne Widerspruchsrecht.

#Was Fehlalarme verhindert

Schonfristen. Sentinel kann nicht wissen, was das Framework selbst tut. Also sagt es ihm das Modul, das es tut: die Garage, wenn sie ein Fahrzeug hinstellt, das Wohnungsmodul beim Teleport, das Todesmodul bei der Wiederbelebung. Team-Handlungen aus dem Adminmenü nimmt Sentinel sich selbst aus der Audit-Spur.

Ping-Toleranz. Die erlaubte Sprungweite wächst mit der gemessenen Leitung des Spielers. Ohne das wäre eine Teleport-Regel eine Regel gegen Spieler mit schlechter Verbindung.

Strikes und Mehrsignal. Eine Klasse-B-Regel gibt erst nach mehreren Treffern in Folge Punkte, und eskaliert nur, wenn zwei verschiedene Regelfamilien denselben Spieler in fünf Minuten treffen. Die beiden Signale müssen dabei mindestens fünf Sekunden auseinander liegen: eine Momentaufnahme, die gleichzeitig zwei Dinge sieht, ist ein Signal und nicht zwei.

Der Ladebildschirm zählt nicht. Zwischen Verbinden und geladenem Charakter liegen Ladebildschirm, Intro und Charakterwahl. In dieser Zeit gibt es keinen Charakter, über den sich etwas behaupten ließe: der Spielfigur ist unverwundbar und unsichtbar, die Kamera hängt in der Luft, und Netz-Ereignisse erreichen den Client gar nicht. Sentinel bewertet Beobachtungen erst, wenn der Charakter da ist. Clientseitig erzeugte Fahrzeuge und Objekte bleiben in dieser Zeit scharf.

Punkte mit Halbwertszeit. Nach 24 Stunden ist die Hälfte weg. Wer einmal auffiel und danach normal spielt, läuft nicht mit dem alten Stand herum.

Die Notbremse. Sperrt Sentinel innerhalb von zehn Minuten fünf verschiedene Spieler, stellt er sich selbst auf Melden und schreibt, warum. Eine falsch eingestellte Regel kostet dich dann fünf Sperren und nicht deinen Server.

Bei Störung wird nicht gesperrt. Antwortet die Datenbank nicht, wird nichts vollstreckt. Eine Störung darf keinen Serverausfall auslösen.

#Das Panel im Portal

Unter Schutz siehst du zuerst, ob dein Server sich meldet, dann den Verlauf, die Prüfstelle und die Regeln. Jeder Vorfall klappt auf und zeigt den Beweis: Koordinaten, Ping, Rohdaten und die Schonfristen, die zu dem Zeitpunkt liefen. Letztere beantworten die Frage, warum eine Regel trotzdem ausgelöst hat.

Neben jedem Regelschalter steht, wie oft die Regel in sieben Tagen getroffen hat und bei wie vielen verschiedenen Spielern. Diese zweite Zahl ist die wichtigere: zwanzig Treffer bei einem Spieler sind ein Cheater, zwanzig Treffer bei zwanzig Spielern sind ein Fehlalarm. Schalte eine Regel erst scharf, wenn du diese Zahl gesehen hast.

Unter Sperren und Ausnahmen steuerst du beides aus dem Browser. Die Sperrliste ist dieselbe, die im Adminmenü deines Servers steht, und eine Aufhebung geht durch dieselbe Funktion wie /unban. Es soll genau eine Sperrliste geben: zwei widersprechen sich, und dann weiß niemand, welche gilt.

Beides braucht bis zu dreißig Sekunden. Der Grund ist derselbe, aus dem das Panel überhaupt ohne offenen Port an deinem Spielserver funktioniert: das Portal legt die Änderung bereit, dein Server holt sie sich beim nächsten Lebenszeichen. Ist er gerade aus, wartet sie, bis er wieder da ist.

#Die Resource-Prüfung

Sentinel prüft jedes Netz-Ereignis der 5mc-Module gegen ein Schema und ein Aufruflimit. Bei fremden Resources geht das nicht: ihre Ereignisse laufen nicht durch unseren Code. Wer etwas anderes verspricht, verkauft eine Liste von Menünamen.

Was geht, ist nachsehen. Zwanzig Sekunden nach dem Start liest Sentinel die serverseitigen Dateien der fremden Resources und sucht Netz-Ereignisse, deren Code den Aufrufer nicht ansieht. So ein Ereignis kann jeder Spieler mit beliebigen Werten auslösen, und das ist die häufigste Lücke in FiveM überhaupt.

Das Ergebnis steht im Panel unter Prüfung. Es ist eine Aufgabenliste und keine Erkennung: es wird nie etwas vollstreckt, und niemand bekommt Punkte.

#Die freiwillige Netzwerkliste

Teilnehmende Server teilen ihre bestätigten Sperren. Wer auf drei Servern wegen gespawnter Objekte gesperrt ist, ist beim vierten kein Zufall. Der Schaden ist genauso offensichtlich, deshalb ist dieser Teil absichtlich unbequem:

• Mitmachen ist eine Handlung im Panel und ein gemeinsames Geheimnis in deiner secrets.cfg. Ohne das Geheimnis macht dein Server nicht mit.
• Geteilt werden nur Prüfsummen, nie Identifier, und IP-Adressen gar nicht.
• Geteilt wird nur Klasse A oder was in der Prüfstelle bestätigt wurde. Eine Meldung wird nie geteilt.
• Ab Werk weist ein Treffer niemanden ab. Er erscheint als Vorfall und im Panel. Automatisch abweisen ist ein eigener Schalter mit eigener Schwelle.
• Jede Meldung hat einen Weg heraus. Du siehst, was dein Server gemeldet hat, und kannst jede Zeile zurückziehen.

Der Grund für diese Vorsicht steht in jeder Recherche zu diesem Markt: geteilte Sperrlisten sind der größte Verstärker von Fehlsperren. Dieselbe Kennung kann zu einem anderen Menschen gehören, etwa nach einem verkauften Konto oder an einem geteilten Rechner.

#Einrichtung

Es gibt keine. Der Lizenzschlüssel steht als 5mc_license in deiner secrets.cfg, und die Zeile schreibt die Einrichtung selbst. Ohne Schlüssel erkennt Sentinel nichts und sagt einmal im Log, was fehlt.

Antwortet unser Portal einmal nicht, läuft Sentinel bis zu sieben Tage mit dem letzten bestätigten Stand weiter. Ein Wartungsfenster bei uns schaltet deinen Schutz nicht ab.

#Härtung der server.cfg

Cfx.re bringt Schalter mit, die Angriffe verhindern, bevor eine Regel sie erkennen müsste. Das Panel zeigt sie unter Schutz und Härtung als Checkliste mit Zeilen zum Kopieren. Sentinel prüft sie nur und ändert nichts an deiner Datei.

Ein Punkt davon steht gegen den ersten Reflex: sv_entityLockdown gehört auf inactive. Auf relaxed oder strict erreichen clientseitig erzeugte Entities den Server nicht mehr, und dann kann Sentinel sie auch nicht prüfen. Du tauschst eine genaue Prüfung gegen eine grobe Sperre.

#Befehle

Rechte: 5mc.schutz für alles davon, 5mc.acbypass um sich selbst für Tests auszunehmen. Die Ausnahme wird protokolliert, damit sie kein Versteck ist.

#Eigene Module

Tut dein Modul etwas, das nach Cheat aussieht, sag es Sentinel:

import { guardGrant, guardExpect } from '@5mc/sdk';

guardGrant(source, 'teleport');
guardGrant(source, 'fahrzeug', 12000);
guardExpect(source, GetHashKey('prop_barrier_wat_03a'));

Läuft kein Schutz, ist der Aufruf ein Leeraufruf. Du darfst ihn also immer machen. Die Arten sind spawn, teleport, fahrzeug, entity, unverwundbar, kamera, geschwindigkeit, animation, waffe, leben und wirtschaft.

guardExpect ist für Entities, die der Client erzeugt. Was der Server selbst erzeugt, läuft gar nicht durch die Prüfung.

#Niemals mit einem echten Cheat testen

Cfx.re erkennt Injektoren selbst, sperrt global, unabhängig von deinem Server und ohne Widerspruchsrecht. Wer etwas nachstellen will, packt den Testcode als client_script in eine Wegwerf-Resource. Der Server sieht dann dasselbe Ereignis, und dein Konto bleibt heil.