Whitelist vs Online Mode in Minecraft - Was ist sicherer?

Zwei Einstellungen in server.properties, die selbst erfahrene Admins verwirren: white-list und online-mode. Beide betreffen den Spielerzugang, aber sie funktionieren voellig unterschiedlich. Die eine prueft die Identitaet des Spielers, die andere ob er auf einer Liste steht. Wenn du auch nur eine davon falsch konfigurierst, reichen die Konsequenzen von "jemand hat sich als ich eingeloggt" bis "unsere gesamte Welt wurde ueber Nacht zerstoert."

Schauen wir uns an, was jede Einstellung macht, welche Risiken die verschiedenen Konfigurationen bergen und wie du deinen Server wirklich absicherst.

Was online-mode macht

online-mode=true sagt deinem Server: "Pruefe jeden Spieler, der sich verbindet, ueber die Mojang-Server." Wenn ein Spieler beitritt, sendet der Client eine Anfrage an sessionserver.mojang.com, und Mojang bestaetigt, dass dieser Account tatsaechlich der Person gehoert, die sich verbinden will.

Was das in der Praxis bedeutet:

• Jeder Spieler bekommt eine einzigartige UUID, die an seinen gekauften Account gebunden ist
• Niemand kann unter dem Benutzernamen eines anderen beitreten - der Server laesst es nicht zu
• Alle Daten (Inventar, Berechtigungen, Bankkonten) sind an die UUID gebunden, nicht an den Nutzernamen
• Skins werden korrekt ueber Mojangs Server geladen

UUID ist die Grundlage der Identitaet. Mit online-mode=true sieht eine UUID so aus: 069a79f4-44e9-4726-a5be-fca90e38aaf5 und wird von Mojang fuer jeden gekauften Account generiert. Sie aendert sich nicht, selbst wenn der Spieler seinen Namen aendert. Alle Plugins, Datenbanken und Weltdaten werden an diesen Identifier gebunden.

Was bei online-mode=false passiert

Wenn du online-mode=false setzt, hoert der Server auf, Accounts ueber Mojang zu verifizieren. Jeder Client kann sich mit jedem Benutzernamen verbinden. Die UUID wird offline basierend auf dem Nutzernamen generiert: UUID.nameUUIDFromBytes("OfflinePlayer:SpielerName") - das nennt man Offline-UUID.

Warum das gefaehrlich ist:

• Jeder kann als Admin beitreten und alle Berechtigungen bekommen
• UUID ist an den Nutzernamen gebunden, nicht an den Account - Name aendern = alle Daten verloren
• Echte Spieler und Betrueger sind nicht zu unterscheiden
• Bot-Angriffe werden trivial - keine Accounts noetig, einfach zufaellige Namen generieren

Ja, der Offline-Modus ermoeglicht Spielern ohne gekauften Account zu spielen. Aber der Preis dafuer ist das voellige Fehlen einer eingebauten Identitaetspruefung.

Was die Whitelist macht

white-list=true aktiviert die Whitelist - eine Datei namens whitelist.json mit einer Liste der Spieler, die sich verbinden duerfen. Alle anderen bekommen "You are not white-listed on this server!" und koennen nicht beitreten.

Die Verwaltung ist einfach:

/whitelist add SpielerName
/whitelist remove SpielerName
/whitelist list
/whitelist reload

Die Whitelist funktioniert auf Verbindungsebene - der Server prueft den Nutzernamen (und die UUID wenn online-mode aktiv ist), bevor der Spieler vollstaendig beitritt. Das bedeutet, unbekannte Personen koennen nicht nur nicht spielen - sie sehen nicht einmal die Welt.

Wie Whitelist und Online-Mode zusammenwirken

Hier kommt der entscheidende Punkt. Bei online-mode=true prueft die Whitelist die UUID des Spielers. Bei online-mode=false nur den Nutzernamen. Der Unterschied ist gewaltig.

Mit online-mode=true + Whitelist: Der Server verifiziert, dass der Spieler tatsaechlich ist, wer er vorgibt zu sein (ueber Mojang), UND dass er auf der erlaubten Liste steht. Doppelte Verifizierung. Maximale Sicherheit.

Mit online-mode=false + Whitelist: Der Server prueft nur den Nutzernamen. Und jeden Nutzernamen kann jeder eingeben. Die Whitelist wird zum Schloss, dessen Schluessel einfach die Kenntnis eines Namens ist.

Cracked Server: reale Risiken

Cracked Server (mit online-mode=false) sind nicht einfach "Server fuer Piraten." Es sind Server mit einem grundlegend anderen Sicherheitsmodell, bei dem Minecrafts Standard-Schutzmechanismen nicht funktionieren.

Was schiefgehen kann:

Account-Diebstahl. Ohne Mojang-Authentifizierung kann jeder mit jedem Nutzernamen beitreten. Wenn der Admin-Name bekannt ist - und das ist er normalerweise - tippt ein Angreifer ihn einfach ein und bekommt alle Berechtigungen, das Inventar und den Zugang. Keine Whitelist hilft, weil der Angreifer einfach den Admin-Namen verwendet.

Bot-Fluten. Einen Online-Mode-Server anzugreifen erfordert Hunderte oder Tausende gekaufte Accounts (oder gestohlene Session-Tokens). Auf einem Cracked-Server generiert der Bot einfach zufaellige Nutzernamen. Angriffskosten sinken auf null. Ein Bot kann 1000 Verbindungen pro Minute mit verschiedenen Namen erstellen, und der Server muss jede verarbeiten.

UUID-Spoofing. Im Offline-Modus ist die UUID vorhersagbar - sie wird aus dem Nutzernamen berechnet. Das bedeutet, ein Angreifer kann die UUID jedes Spielers im Voraus berechnen und potenziell deren Daten manipulieren.

Exploits durch gefaelschte Nutzernamen. Manche Plugins vertrauen dem Nutzernamen oder der UUID ohne zusaetzliche Pruefung. Auf einem Cracked-Server oeffnet das Luecken - von Rechteausweitung bis SQL-Injection, wenn ein Plugin den Nutzernamen bei Datenbankabfragen nicht bereinigt.

AuthMe: der Workaround, der zum Standard wurde

Wenn dein Server im Offline-Modus laeuft, ist AuthMe das Erste, was du installieren musst. Es fuegt ein Registrierungs- und Login-System ueber die Standard-Verbindung hinzu.

Wie es funktioniert: Beim ersten Beitritt muss der Spieler /register passwort passwort ausfuehren. Bei weiteren Besuchen - /login passwort. Bis zur Authentifizierung kann der Spieler sich nicht bewegen, keine Bloecke abbauen, nicht chatten oder mit der Welt interagieren.

AuthMe speichert Passwoerter gehasht (bcrypt standardmaessig), unterstuetzt MySQL/MariaDB, hat Brute-Force-Schutz und viele Einstellungen. Fuer Offline-Server ist es das absolute Minimum.

Aber AuthMe ist kein Ersatz fuer online-mode. Es ist ein Pflaster. Deshalb:

• Spieler muessen sich noch ein Passwort merken (und viele setzen "123456")
• Wenn die AuthMe-Datenbank geleakt wird, sind alle Accounts kompromittiert
• Timing-Angriffe und andere Umgehungsmethoden existieren
• Neue Spieler sind verwirrt vom Registrierungsprozess und gehen

Fuer Server mit grossem Cracked-Publikum ist AuthMe zusammen mit FastLogin (Auto-Login fuer lizenzierte Accounts) eine funktionierende Konfiguration. Aber wenn du online-mode nutzen kannst - nutze online-mode.

Einen tieferen Einblick in Sicherheits-Plugins und ihre Einrichtung findest du in unserem Plugin-Ueberblick.

BungeeCord und Velocity: Forwarding-Modi und Sicherheit

Wenn du ein Servernetzwerk hinter einem Proxy (BungeeCord oder Velocity) betreibst, wird es komplizierter. Der Proxy uebernimmt die Authentifizierung, und Backend-Server laufen mit online-mode=false, weil der Proxy die Verifizierung bereits durchgefuehrt hat. Aber das oeffnet einen neuen Angriffsvektor - wenn sich jemand direkt mit einem Backend-Server verbindet und den Proxy umgeht, ueberspringt er die gesamte Authentifizierung.

Legacy Forwarding (BungeeCord)

Der alte Mechanismus. BungeeCord uebertraegt UUID und IP des Spielers ueber spezielle Felder im Handshake-Paket. Der Backend-Server vertraut diesen Daten blind, wenn bungeecord: true in spigot.yml gesetzt ist.

Das Problem: Jeder kann diese Felder faelschen. Wenn der Backend-Server ueber seine direkte IP erreichbar ist, kann ein Angreifer sich verbinden und vorgeben, jeder zu sein - einschliesslich eines Administrators. Deshalb ist eine Firewall, die externen Zugang zu Backend-Ports blockiert, keine Option - es ist eine Notwendigkeit.

BungeeGuard

BungeeGuard loest das Vertrauensproblem des Legacy-Forwarding mit einem gemeinsamen geheimen Token. Der Proxy fuegt den Token zum Handshake hinzu, und der Backend-Server ueberprueft ihn. Fehlt der Token oder ist er falsch - Verbindung abgelehnt. Eine einfache und effektive Loesung, wenn du aus irgendeinem Grund nicht auf Velocity wechseln kannst.

Modern Forwarding (Velocity)

Velocity verwendet seinen eigenen Forwarding-Mechanismus, der Spielerdaten kryptographisch signiert. Der Backend-Server verifiziert die Signatur mit einem gemeinsamen Geheimnis. Diese Daten ohne Kenntnis des Geheimnisses zu faelschen ist unmoeglich.

In der Velocity-Konfiguration ist es player-info-forwarding-mode = "modern", und auf dem Backend in paper-global.yml gibst du dasselbe Geheimnis an. Das ist der sicherste Weg, Spielerdaten in 2026 weiterzuleiten.

Empfehlung: Wenn du ein Netzwerk von Grund auf aufbaust - nutze Velocity mit Modern Forwarding. Wenn du bereits auf BungeeCord bist und nicht migrieren kannst - installiere BungeeGuard und sperre deine Ports.

Reale Angriffsszenarien

Schauen wir uns an, wie das in der Praxis aussieht. Das sind Situationen, die ich nicht nur einmal gesehen habe.

Szenario 1: Admin-Account-Uebernahme auf einem Cracked-Server

Server mit online-mode=false, kein AuthMe. Ein Admin mit dem Nutzernamen "ServerAdmin" hat OP. Angreifer tritt als "ServerAdmin" bei, bekommt alle Berechtigungen, fuehrt /op fuer seinen Hauptaccount aus, zerstoert den Spawn und bannt alle. Der ganze Vorgang dauert 30 Sekunden.

Verteidigung: AuthMe + starke Passwoerter, OP nur ueber die Konsole (nie ueber /op im Spiel), Berechtigungs-Plugins statt OP verwenden.

Szenario 2: Bot-Flut auf einem Cracked-Server

Angreifer startet ein Botnet, das Hunderte Verbindungen pro Sekunde mit zufaelligen Nutzernamen generiert. Der Server verbraucht Ressourcen fuer die Verarbeitung jeder Verbindung, TPS sinken, echte Spieler koennen nicht beitreten. Wenn AuthMe installiert ist, bleiben Bots am Login-Screen haengen, verbrauchen aber trotzdem Ressourcen.

Verteidigung: LimboFilter auf dem Proxy (filtert Bots bevor sie den Hauptserver erreichen), Rate-Limiting nach IP, externe Traffic-Filterung.

Szenario 3: Direkte Backend-Verbindung

Servernetzwerk: BungeeCord + mehrere Spigot-Instanzen. Der Admin hat vergessen, Port 25566 zu schliessen (einer der Backends). Backend hat bungeecord: true und online-mode=false. Angreifer verbindet sich direkt, faelscht den Handshake mit der UUID eines Admins, bekommt vollen Zugang.

Verteidigung: Firewall (nur der Proxy darf sich mit Backends verbinden), BungeeGuard oder Wechsel zu Velocity Modern Forwarding, regelmaessige Port-Audits.

Szenario 4: UUID-Kollision auf einem Offline-Server

Auf einem Offline-Server wird die UUID aus dem Nutzernamen berechnet. Ein Angreifer erstellt einen Account mit einem Nutzernamen, der dieselbe UUID wie der Zielspieler erzeugt (durch Brute Force oder spezialisierte Tools). Ergebnis: Zugang zum Inventar, zur Endertruhe und den Plugin-Daten des Zielspielers.

Verteidigung: online-mode=true loest das Problem vollstaendig, da die UUID von Mojang vergeben wird und nicht vom Nutzernamen abhaengt.

Welche Konfiguration waehlen

Hier sind meine Empfehlungen je nach Server-Typ:

Privater Server fuer Freunde: online-mode=true + white-list=true. Maximaler Schutz mit minimalem Aufwand. Kein Fremder kommt rein.

Oeffentlicher lizenzierter Server: online-mode=true + Whitelist aus. Mojang-Authentifizierung bietet grundlegende Sicherheit. Fuege Sicherheits-Plugins nach Bedarf hinzu.

Oeffentlicher Cracked-Server: online-mode=false + AuthMe + FastLogin + LimboFilter. Das ist das Minimum. Ohne das bist du unter staendigen Angriffen. Selbst damit - die Risiken sind hoeher als bei einem lizenzierten Server.

Servernetzwerk (BungeeCord/Velocity): Proxy mit online-mode=true, Backends mit online-mode=false + Velocity Modern Forwarding (oder BungeeGuard). Firewall auf Backend-Servern ist Pflicht.

Whitelist + Online-Mode kombinieren

Die beste Option fuer Server, die strenge Zugangskontrolle brauchen, ist beides zu aktivieren. online-mode=true garantiert, dass der Spieler ist, wer er vorgibt zu sein. white-list=true beschraenkt den Zugang auf eine bestimmte Liste verifizierter Personen.

Das ist ideal fuer:

• Server in der Entwicklungsphase (damit keine zufaelligen Leute beitreten)
• Private Community-Server
• Server mit wertvollem Content (grosse Projekte, wo Griefing = riesige Verluste)
• Testserver, wo die Umgebung kontrolliert werden muss

Der einzige Nachteil ist, dass die Whitelist-Verwaltung Handarbeit erfordert. Jeder Spieler muss manuell hinzugefuegt werden. Aber fuer Sicherheit ist das ein kleiner Preis.

Server-Sicherheits-Checkliste

Hier ist eine grundlegende Checkliste, die fuer jeden Server durchgegangen werden sollte:

1. online-mode=true - ausser du hast einen starken Grund fuer den Offline-Modus
2. Whitelist - aktivieren, wenn der Server nicht oeffentlich ist
3. Firewall - alle Ports schliessen ausser den noetigsten (25565 fuer den Hauptserver, alles andere ueber VPN oder internes Netzwerk)
4. AuthMe - Pflicht fuer Offline-Server
5. Velocity Modern Forwarding - fuer Servernetzwerke
6. Backups - regelmaessig, auf einen separaten Server
7. Monitoring - verdaechtige Logins und Anomalien beobachten

Mehr Details zu jedem Punkt in unserer vollstaendigen Sicherheits-Checkliste.

Fazit

Online-Mode und Whitelist loesen unterschiedliche Probleme. Online-Mode dreht sich um Authentifizierung: "Bist du wirklich der, der du vorgibst zu sein?" Whitelist dreht sich um Autorisierung: "Darfst du hier rein?"

Beide Mechanismen ergaenzen sich. Online-Mode ohne Whitelist schuetzt vor Betruegern, aber nicht vor unerwuenschten Gaesten. Whitelist ohne Online-Mode schuetzt vor zufaelligen Beitritten, aber nicht vor gezieltem Spoofing.

Wenn du kannst - aktiviere beides. Wenn du im Offline-Modus arbeitest - kompensiere das Fehlen der Mojang-Authentifizierung mit Plugins. Und in jedem Fall - vergiss nicht die Netzwerksicherheit: Firewall, richtiges Forwarding und externen DDoS-Schutz.