GeyserMC und Crossplay: Server mit Bedrock-Spielern absichern

Crossplay in Minecraft ist laengst keine Nische mehr. Bedrock-Spieler auf Handys, Konsolen und Windows 10 wollen auf Java-Servern mit ihren Freunden spielen. GeyserMC macht das moeglich, indem es das Bedrock-Protokoll in Echtzeit nach Java uebersetzt. Klingt grossartig, aber aus Sicherheitssicht oeffnet das eine ganze Reihe von Problemen, ueber die kaum jemand nachdenkt.

In diesem Artikel analysiere ich, was unter der Haube passiert, welche Risiken beim Anschluss von Bedrock-Spielern entstehen und wie man alles richtig absichert.

Was GeyserMC macht und wie es funktioniert

GeyserMC ist eine Protokoll-Uebersetzungsschicht. Es nimmt Verbindungen von Bedrock-Clients an und uebersetzt sie ins Java-Edition-Format. Der Bedrock-Client denkt, er verbindet sich mit einem normalen Bedrock-Server. Der Java-Server denkt, ein normaler Java-Client hat sich verbunden. GeyserMC sitzt dazwischen und konvertiert Pakete in beide Richtungen.

Das Entscheidende: Bedrock Edition verwendet UDP (RakNet-Protokoll) auf Port 19132, waehrend Java Edition ueber TCP auf Port 25565 laeuft. Das sind grundlegend verschiedene Protokolle mit unterschiedlichen Sicherheitseigenschaften.

Wenn du GeyserMC installierst, oeffnest du im Grunde ein zweites Protokoll auf deinem Server. Vorher hattest du nur einen TCP-Port. Jetzt kommt noch UDP dazu. Das aendert die Situation grundlegend.

Installationsmodi

GeyserMC laeuft in mehreren Modi:

Plugin-Modus. Geyser wird als Plugin direkt auf deinem Server (Paper, Spigot) oder Proxy (Velocity, BungeeCord) installiert. Einfachste Option, aber Bedrock-Traffic kommt direkt auf der Maschine an, die deinen Spielserver betreibt.

Standalone-Modus. Geyser laeuft als eigenstaendige Anwendung, moeglicherweise auf einer separaten Maschine. Es nimmt Bedrock-Verbindungen an und leitet sie an den Java-Server weiter. Flexibler aus architektonischer Sicht.

# config.yml (Geyser)
bedrock:
  address: 0.0.0.0
  port: 19132
  motd1: "Mein Server"
  motd2: "Crossplay Aktiviert"

remote:
  address: 127.0.0.1
  port: 25565
  auth-type: online

Die Wahl des Modus beeinflusst deine Sicherheitslage. Mehr dazu weiter unten.

Was genau uebersetzt GeyserMC

Es ist wichtig, den Umfang der Arbeit zu verstehen, die GeyserMC leistet. Das ist kein einfaches Paket-Forwarding. Java Edition und Bedrock Edition verwenden voellig unterschiedliche Datenformate, Block-IDs, Chunk-Systeme und Inventarmechaniken.

Java Edition speichert Bloecke in einem palettierten Format mit globalen IDs. Bedrock Edition nutzt ein eigenes Runtime-ID-System. GeyserMC pflegt ein Mapping zwischen beiden fuer jede Version beider Clients. Das betrifft tausende Bloecke, hunderte Items und dutzende Entity-Typen. Auch NBT-Formate unterscheiden sich: Bedrock nutzt Little-Endian, Java Big-Endian. Skin-Systeme, Partikeleffekte, Sound-Events, alles muss uebersetzt werden. Diese Arbeit passiert in Echtzeit auf jedes einzelne Paket.

UDP-Port 19132: Die neue Angriffsflaeche

Hier liegt das Kernproblem. Wenn du GeyserMC installierst, oeffnest du den UDP-Port 19132 fuer die Aussenwelt. Und UDP und TCP sind beim DDoS-Schutz zwei sehr verschiedene Tiere.

Warum UDP riskanter ist als TCP

TCP hat einen Handshake-Mechanismus (SYN, SYN-ACK, ACK). Bevor eine Verbindung aufgebaut wird, tauschen beide Seiten Pakete aus und bestaetigen die Existenz des Gegenueber. Das bietet grundlegenden Schutz vor IP-Spoofing.

UDP hat keinen solchen Mechanismus. Paket gesendet, Paket empfangen. Kein Handshake, keine Bestaetigung, keine Ueberpruefung der Absenderadresse. Das bedeutet:

1. IP-Spoofing ist trivial. Ein Angreifer kann UDP-Pakete mit beliebiger Quell-IP senden. Dein Server kann ein gefaelschtes Paket nicht von einem echten unterscheiden, bis er mit dem Parsen beginnt.

2. Amplification-Angriffe. Wenn dein Geyser auf beliebige UDP-Anfragen mit groesseren Paketen antwortet, kann er als Verstaerker (Reflector) bei Angriffen auf Dritte missbraucht werden.

3. Flooding ist einfacher. TCP-Floods erfordern mindestens einen abgeschlossenen Handshake. UDP-Floods muessen nur Pakete auf den Port schleudern.

Mehr zu den Unterschieden zwischen TCP- und UDP-Angriffen im Minecraft-Kontext findest du in unserem Artikel TCP vs UDP Angriffe.

RakNet-Besonderheiten

Bedrock Edition verwendet RakNet ueber UDP. RakNet fuegt eine eigene Zuverlaessigkeitsschicht hinzu: Neuuebertragung verlorener Pakete, Sortierung, Fragmentierung. Aber all das laeuft ueber UDP, was bedeutet, dass das erste Paket immer noch ohne jede Verifizierung ankommt.

GeyserMC muss das eingehende RakNet-Paket annehmen und parsen, bevor es entscheiden kann, ob ein Client legitim ist. Jedes Muell-Paket auf Port 19132 verbraucht CPU-Ressourcen fuer das Parsing.

Reale Angriffsszenarien auf den UDP-Port

In der Praxis sehen Angriffe auf Port 19132 so aus:

Volumetrischer UDP-Flood. Einfaches Senden riesiger Mengen von Muell-UDP-Paketen auf Port 19132. Ziel: den Kanal verstopfen oder den Netzwerkstack ueberlasten.

RakNet-Handshake-Flood. Intelligenterer Ansatz: Senden gueltig aussehender RakNet Open Connection Request Pakete von gefaelschten IPs. Geyser versucht, auf jede Anfrage zu antworten und verbraucht dabei Ressourcen. Da die IPs gefaelscht sind, gehen die Antworten ins Leere, aber die Ressourcen sind bereits verbraucht.

Session-Exhaustion. Oeffnen vieler halbfertiger RakNet-Sitzungen, die den Handshake nicht abschliessen. Jede solche Sitzung belegt einen Slot und Speicher. Wenn die Zombie-Sitzungen das Limit ueberschreiten, koennen sich legitime Clients nicht mehr verbinden.

Alle drei Szenarien treten in der Praxis auf und erfordern jeweils eigene Abwehrstrategien.

Floodgate: Authentifizierung von Bedrock-Spielern

Eines der kritischen Crossplay-Probleme ist die Authentifizierung. Java Edition nutzt Mojang/Microsoft-Konten. Bedrock Edition nutzt Xbox Live. Zwei verschiedene Systeme, die verbunden werden muessen.

Was Floodgate macht

Floodgate ist ein Begleit-Plugin fuer GeyserMC. Es ermoeglicht Bedrock-Spielern, Java-Servern beizutreten, ohne ein Java-Konto zu benoetigen. Floodgate verifiziert die Xbox-Live-Authentifizierung und laesst den Spieler mit einem Praefix durch (typischerweise ein Punkt: .SpielerName).

# config.yml (Floodgate)
username-prefix: "."
replace-spaces: true

Warum Floodgate fuer die Sicherheit entscheidend ist

Ohne Floodgate hast du zwei Optionen:

Online-Modus (auth-type: online). Bedrock-Spieler muessen ein lizenziertes Java-Konto haben und dessen Zugangsdaten bei jeder Verbindung ueber GeyserMC eingeben. Unpraktisch, da die meisten Bedrock-Spieler kein Java-Konto besitzen.

Offline-Modus (auth-type: offline). Bedrock-Spieler treten ohne jede Ueberpruefung bei. Jeder kann unter jedem Namen verbinden. Eine Sicherheitskatastrophe auf Produktivservern: Account-Spoofing, Inventardiebstahl, Privilege Escalation.

Floodgate loest beides: Xbox-Live-Authentifizierung verifiziert die Identitaet, und das Praefix verhindert Konflikte mit Java-Nicknames.

Floodgate-Verschluesselungsschluessel

Floodgate generiert ein Schluesselpaar (oeffentlich/privat). Der oeffentliche Schluessel kommt auf GeyserMC, der private auf den Backend-Server. So kann der Server verifizieren, dass Bedrock-Spielerdaten wirklich von Geyser kamen und nicht gefaelscht wurden.

Wenn jemand deinen privaten Floodgate-Schluessel erlangt, kann er die Bedrock-Spieler-Authentifizierung faelschen. Bewahre diese Schluessel genauso sorgfaeltig auf wie dein Velocity-Forwarding-Secret.

GeyserMC hinter einem Proxy: Die richtige Architektur

Das sicherste Setup stellt GeyserMC hinter einen Velocity-Proxy. Falls du noch nicht auf Velocity umgestiegen bist, lies zuerst Velocity vs BungeeCord: Warum es Zeit zum Wechseln ist.

Architektur

Bedrock-Client (UDP:19132)
    |
GeyserMC (Standalone oder Velocity-Plugin)
    |
Velocity-Proxy (TCP)
    |
Paper-Backend-Server

Java-Clients verbinden sich direkt mit Velocity ueber TCP. Bedrock-Clients verbinden sich mit GeyserMC ueber UDP, das sie nach TCP uebersetzt und an Velocity weiterleitet. Aus Backend-Sicht sehen alle Spieler gleich aus.

Geyser als Velocity-Plugin

Der empfohlene Ansatz. Installiere Geyser direkt auf Velocity:

# velocity.toml
bind = "0.0.0.0:25565"

[servers]
lobby = "127.0.0.1:30001"
survival = "127.0.0.1:30002"

try = ["lobby"]

player-info-forwarding-mode = "modern"

Geyser lauscht auf UDP:19132 auf derselben Maschine wie Velocity. Die Uebersetzung findet innerhalb eines einzelnen Prozesses statt, ohne Netzwerk-Hops.

Floodgate auf Velocity + Backends

Floodgate muss sowohl auf Velocity als auch auf jedem Backend-Server installiert werden. Auf Velocity kuemmert es sich um die Authentifizierung. Auf Backends wird es fuer die korrekte Anzeige von Bedrock-Spieler-Skins und UUIDs benoetigt.

Die Schluessel muessen auf allen Servern uebereinstimmen. Kopiere key.pem von deiner Velocity-Instanz auf jedes Backend.

Schutz vor UDP-Floods auf Port 19132

Jetzt zur Praxis.

Rate-Limiting mit iptables

Grundschutz: Begrenzung der Paketrate pro Quell-IP.

# Rate-Limit auf Port 19132 (Bedrock)
iptables -A INPUT -p udp --dport 19132 -m hashlimit \
  --hashlimit-name bedrock \
  --hashlimit-above 100/sec \
  --hashlimit-burst 150 \
  --hashlimit-mode srcip \
  -j DROP

# Paketgroesse begrenzen (RakNet-Pakete sollten nicht riesig sein)
iptables -A INPUT -p udp --dport 19132 -m length --length 1500:65535 -j DROP

Passe die Werte an deinen tatsaechlichen Traffic an. 100 Pakete/Sek pro IP sind fuer legitime Bedrock-Clients mehr als ausreichend.

GeoIP-Filterung

Wenn deine Spieler hauptsaechlich aus einer bestimmten Region kommen, kannst du den UDP-Port geografisch einschraenken:

# Beispiel: UDP 19132 nur aus DE, AT, CH erlauben
iptables -A INPUT -p udp --dport 19132 \
  -m geoip ! --src-cc DE,AT,CH -j DROP

Keine eigenstaendige Loesung, aber es reduziert die Angriffsflaeche.

Standalone vs Plugin: Sicherheitsabwaegungen

Plugin-Modus

Geyser laeuft als Plugin auf deinem Server oder Proxy.

Vorteile: Einfache Einrichtung, alles in einem Prozess, native Floodgate-Integration.

Nachteile: Der UDP-Port ist auf derselben Maschine wie dein Spielserver offen. Ein DDoS auf UDP:19132 belastet dieselbe Maschine, die Java-Spieler bedient. Eine Schwachstelle in Geyser koennte theoretisch den gesamten Server kompromittieren.

Standalone-Modus

Geyser laeuft als eigenstaendige Anwendung, moeglicherweise auf einer separaten Maschine.

Vorteile: Isolation: Ein DDoS auf den Bedrock-Port beeintraechtigt den Java-Server nicht. Kann auf einer dedizierten Maschine mit separater IP laufen. Wenn Geyser abstuerzt, laeuft der Java-Server weiter.

Nachteile: Komplexere Einrichtung. Zusaetzlicher Netzwerk-Hop (leichte Latenzsteigerung). Separates Update-Management.

Fuer Server mit ernsthafter Spielerzahl ist Standalone auf einer separaten Maschine der richtige Weg. Fuer kleinere Server funktioniert der Plugin-Modus auf Velocity gut.

Docker-Isolation fuer Standalone

Wenn du Standalone waehlst, erwaege GeyserMC in einem Docker-Container zu betreiben. Das gibt dir eine zusaetzliche Isolationsebene:

# docker-compose.yml
services:
  geyser:
    image: openjdk:21-slim
    command: java -Xms256M -Xmx512M -jar /app/Geyser.jar
    ports:
      - "19132:19132/udp"
    volumes:
      - ./geyser-config:/app
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 512M

CPU- und RAM-Limits ueber Docker bedeuten: Selbst wenn GeyserMC wegen eines Angriffs Ressourcen verschlingt, kann es nicht die Ressourcen der gesamten Maschine aufbrauchen. Der Java-Server laeuft normal weiter. Zusaetzlich kannst du automatische Neustarts bei Abstuerzen und Health-Checks konfigurieren.

Xbox-Live-Auth vs Offline-Modus

Diese Entscheidung definiert dein gesamtes Crossplay-Sicherheitsmodell.

Online-Modus (Xbox Live)

remote:
  auth-type: online

Jeder Bedrock-Spieler muss ueber Xbox Live authentifiziert sein. Verifizierte Identitaet, Schutz vor Account-Spoofing, Bans nach Xbox-Live-ID statt nur IP. Die einzig vernuenftige Wahl fuer Produktivserver.

Offline-Modus

remote:
  auth-type: offline

Keine Verifizierung. Jeder Client kann sich unter jedem Namen verbinden. Nur fuer lokale Testserver akzeptabel. In Produktion ist das eine Einladung zum Chaos.

Verwende den Online-Modus. Immer.

Hybridansatz: Online-Modus + Floodgate

Die optimale Konfiguration sieht so aus:

# config.yml (Geyser)
remote:
  auth-type: online

# Floodgate uebernimmt die Bedrock-Authentifizierung
# Online-Modus sichert die Java-Account-Verifizierung

Bei diesem Ansatz durchlaufen Java-Spieler die Standard-Mojang/Microsoft-Authentifizierung, Bedrock-Spieler authentifizieren sich ueber Xbox Live, und Floodgate verbindet beide Prozesse mit einem Nickname-Praefix. Kein Spieler kann ohne Verifizierung beitreten.

Das ist der Goldstandard fuer Crossplay-Server. Die Einrichtung ist etwas aufwaendiger als ein einfaches auth-type: offline. Aber der Unterschied zwischen "funktioniert" und "funktioniert sicher" liegt genau in diesen Details.

Performance-Auswirkungen und DDoS-Resilienz

GeyserMC erzeugt Overhead. Jedes Bedrock-Paket muss ueber UDP empfangen, aus dem RakNet-Format geparst, ins Java-Format konvertiert und ueber TCP weitergeleitet werden. Der Rueckweg ebenso. Das ist nicht kostenlos.

Jeder Bedrock-Spieler kostet etwa 1,5-2x so viel CPU wie ein regulaerer Java-Spieler. RAM-Verbrauch ist ebenfalls hoeher wegen der Notwendigkeit, den Uebersetzungszustand fuer jede Verbindung zu speichern.

Wenn dein Server fuer 100 Spieler ausgelegt ist und 30 davon Bedrock sind, kalkuliere sie als ~50 Java-Spieler in Bezug auf die Last.

Hoeherer Ressourcenverbrauch bedeutet weniger Reserven waehrend eines DDoS-Angriffs. Wenn 60% der CPU in Friedenszeiten fuer Protokolluebersetzung draufgehen, bleibt weniger Raum fuer die Verarbeitung von legitimem Traffic unter Angriff.

Empfehlungen:

• Halte mindestens 40% CPU-Reserve im Normalbetrieb
• Ueberwache den GeyserMC-Verbrauch separat vom Hauptserver
• Richte Alerts fuer anomales UDP-Traffic-Wachstum ein

GeyserMC-Optimierung fuer geringere Last

Einige Einstellungen helfen, den Ressourcenverbrauch zu senken:

# config.yml (Geyser)
passthrough-motd: false
passthrough-player-counts: false
cache-chunks: true
max-players: 50

Das Begrenzen von max-players in GeyserMC separat vom Java-Server-Limit gibt dir Kontrolle darueber, welchen Anteil der Ressourcen Crossplay verbraucht. Bei einem Server fuer 200 Spieler ist es vernuenftig, Bedrock auf 60-80 zu begrenzen und garantierte Slots fuer Java-Clients zu reservieren.

DDoS-Schutz fuer gemischten TCP+UDP-Traffic

Den Schutz eines Crossplay-Servers abzusichern ist schwieriger als bei einem reinen Java-Server. Du hast zwei Protokolle, zwei Ports, zwei verschiedene Traffic-Modelle.

Was dein DDoS-Schutz koennen muss:

TCP-Filterung (Java). Standard: SYN-Flood, TCP-Amplification, Application-Layer-Angriffe. SYN-Cookies, Connection-Tracking, Rate-Limiting.

UDP-Filterung (Bedrock). Schwieriger. Du musst legitimen RakNet-Traffic von Muell unterscheiden koennen. Einfaches IP-basiertes Rate-Limiting funktioniert, ist aber grob. Ein besserer Ansatz parst RakNet-Header und verwirft Pakete mit ungueltiger Struktur.

Einheitliches Monitoring. Angreifer schlagen oft auf beide Ports gleichzeitig: TCP-Flood + UDP-Flood. Wenn dein Schutz sie getrennt behandelt, ohne das Gesamtbild zu sehen, kann er kombinierte Angriffe uebersehen.

Loesungen wie MineGuard filtern beide Traffic-Typen auf Netzwerkebene, bevor Pakete deinen Server erreichen. Das ist besonders wichtig fuer UDP, wo IP-Spoofing Application-Level-Abwehr weniger effektiv macht.

Proxy-Protokoll fuer Bedrock

Wenn dein Geyser hinter einem Netzwerk-Proxy oder DDoS-Schutz steht, musst du die echten Spieler-IPs weiterleiten. Ohne das erscheinen alle Bedrock-Spieler mit der IP des Proxys, was Bans nutzlos macht.

bedrock:
  enable-proxy-protocol: true
  proxy-protocol-whitelisted-ips:
    - "10.0.0.0/8"
    - "172.16.0.0/12"

Beschraenke die Whitelist auf die Adressen deines Schutzes. Sonst kann ein Angreifer den Proxy-Protocol-Header faelschen und IPs spoofen.

Sicherheits-Checkliste

Gehe diese Liste durch, bevor du Crossplay in Produktion startest:

Authentifizierung:

• auth-type auf online gesetzt
• Floodgate installiert und konfiguriert
• Floodgate-Schluessel auf alle Backend-Server kopiert
• username-prefix gesetzt (Standard ".")

Netzwerk:

• Port 19132 (UDP) per iptables Rate-Limited
• Backend-Ports fuer externen Zugriff geschlossen
• GeoIP-Filterung konfiguriert (falls zutreffend)
• Proxy-Protokoll konfiguriert, wenn Geyser hinter einem Proxy steht

Architektur:

• Geyser als Velocity-Plugin installiert (nicht direkt auf Backend)
• Velocity verwendet Modern Forwarding
• forwarding.secret ist einzigartig und sicher gespeichert

Monitoring:

• UDP-Traffic auf Port 19132 ueberwacht
• Alerts bei anomalen Paketraten-Anstiegen
• Fail2ban fuer Geyser-Logs konfiguriert

Haeufige Fehler

Geyser auf Backend statt Proxy. Wenn du Velocity nutzt, installiere Geyser auf Velocity, nicht auf Paper-Servern. Sonst umgeht Bedrock-Traffic den Proxy und all seine Schutzmechanismen.

Vergessener Offline-Modus. Leute setzen auth-type: offline "zum Testen" und vergessen, es umzuschalten. Ergebnis: Fake-Accounts erscheinen auf dem Server.

Kein Rate-Limiting auf UDP. Port 19132 geoeffnet, kein Limit gesetzt. Der erste Angriff legt den Server lahm.

Veraltete Versionen. GeyserMC wird aktiv entwickelt, und jedes Update schliesst Schwachstellen. Betreibe keine Version, die einen Monat alt ist.

Fazit

GeyserMC ist ein hervorragendes Tool, das deinen Server fuer die riesige Bedrock-Spielerbasis oeffnet. Aber jede neue Tuer ist ein weiterer Eingang, der bewacht werden muss.

Kernpunkte:

1. UDP-Port 19132 ist eine neue Angriffsflaeche. Schuetze ihn.
2. Verwende Floodgate + Online-Modus. Immer.
3. Installiere Geyser auf deinem Proxy (Velocity), nicht auf Backends.
4. Richte Rate-Limiting fuer UDP-Traffic ein.
5. Fuer ernsthafte Server nutze den Standalone-Modus mit Isolation.
6. Ueberwache UDP-Traffic getrennt von TCP.

Crossplay lohnt sich, wenn man es richtig einrichtet. Die mobile und Konsolen-Audience waechst schneller als Java. Aber nur, wenn dein Server auf die neuen Bedrohungen vorbereitet ist, die zusammen mit den neuen Spielern kommen.

Fuer ein tieferes Verstaendnis der Unterschiede zwischen Java- und Bedrock-DDoS-Schutz empfehle ich den Artikel Java vs Bedrock: DDoS-Schutz.