GeyserMC i crossplay: jak zabezpieczyć serwer z graczami Bedrock

Crossplay w Minecrafcie dawno przestał być egzotyką. Gracze Bedrock na telefonach, konsolach i Windows 10 chcą grać na serwerach Java razem ze znajomymi. GeyserMC rozwiązuje to zadanie, tłumacząc protokół Bedrock na Java w locie. Brzmi świetnie, ale z punktu widzenia bezpieczeństwa otwiera to cały pokład problemów, o których mało kto myśli.

W tym artykule rozkminiam, co dzieje się pod maską GeyserMC, jakie ryzyka pojawiają się przy podłączeniu graczy Bedrock i jak to wszystko prawidłowo zamknąć.

Czym jest GeyserMC i jak działa

GeyserMC to warstwa proxy, która przyjmuje połączenia od klientów Bedrock i tłumaczy je do formatu Java Edition. Klient Bedrock myśli, że łączy się ze zwykłym serwerem Bedrock. Serwer Java myśli, że przyszedł do niego zwykły klient Java. GeyserMC siedzi pośrodku i tłumaczy pakiety w obie strony.

Kluczowa kwestia: Bedrock Edition używa UDP (protokół RakNet) na porcie 19132, a Java Edition działa przez TCP na porcie 25565. To dwa zasadniczo różne protokoły o różnych charakterystykach bezpieczeństwa.

Kiedy stawiasz GeyserMC, w zasadzie otwierasz drugi protokół na serwerze. Wcześniej miałeś tylko port TCP. Teraz pojawia się jeszcze UDP. I zmienia to sytuację kardynalnie.

Tryby instalacji

GeyserMC może działać w kilku trybach:

Plugin mode. Geyser instaluje się jako plugin bezpośrednio na twoim serwerze (Paper, Spigot) lub proxy (Velocity, BungeeCord). Najprostsza opcja, ale ruch Bedrock przychodzi bezpośrednio na maszynę z serwerem.

Standalone mode. Geyser odpala się jako osobna aplikacja na osobnej maszynie lub porcie. Przyjmuje połączenia Bedrock i proxy'uje je do serwera Java. Bardziej elastyczna opcja z punktu widzenia architektury.

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

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

Wybór trybu wpływa na bezpieczeństwo. O tym niżej.

Co konkretnie tłumaczy GeyserMC

Ważne, żeby zrozumieć skalę pracy, którą wykonuje GeyserMC. To nie zwykłe forwardowanie pakietów. Java Edition i Bedrock Edition używają zupełnie różnych formatów danych, różnych ID bloków i przedmiotów, różnych systemów chunków, różnej mechaniki ekwipunku.

Na przykład, Java Edition przechowuje bloki w formacie paletowym z globalnymi ID. Bedrock Edition używa własnego systemu runtime ID. GeyserMC wspiera mapowanie między nimi dla każdej wersji obu klientów. Dotyczy to tysięcy bloków, setek przedmiotów, dziesiątek typów entity.

Formy i formaty też się różnią. Bedrock Edition używa NBT w formacie little-endian, Java w big-endian. System skinów jest inny. Bedrock wspiera customowe geometrie skinów, Java nie. System cząsteczek, dźwięków, animacji - wszystko się różni.

Cała ta translacja dzieje się na każdy pakiet, w czasie rzeczywistym. I generuje to obciążenie, które trzeba uwzględnić przy planowaniu zasobów i odporności na DDoS.

Port UDP 19132: nowa powierzchnia ataku

Oto główny problem. Kiedy stawiasz GeyserMC, otwierasz port UDP 19132 dla świata zewnętrznego. A UDP i TCP to dwa bardzo różne zwierzęta z punktu widzenia ochrony DDoS.

Dlaczego UDP jest groźniejszy niż TCP

TCP ma mechanizm handshake (SYN, SYN-ACK, ACK). Zanim połączenie zostanie ustanowione, obie strony wymieniają pakiety i potwierdzają istnienie siebie nawzajem. Daje to podstawową ochronę przed spoofingiem adresów IP.

UDP takiego mechanizmu nie ma. Pakiet wysłany - pakiet odebrany. Nie ma handshake, nie ma potwierdzenia, nie ma weryfikacji adresu zwrotnego. To znaczy:

1. IP spoofing jest trywialny. Atakujący może wysyłać pakiety UDP z dowolnym adresem IP źródłowym. Twój serwer nie potrafi odróżnić podrobionego pakietu od prawdziwego, dopóki nie zacznie go parsować.

2. Ataki amplification. Jeśli twój Geyser odpowiada na dowolne zapytania UDP pakietami o większym rozmiarze, może być użyty jako wzmacniacz (reflector) w ataku na osoby trzecie.

3. Flood łatwiej zorganizować. Dla flood TCP trzeba przynajmniej dokończyć handshake. Dla UDP flood wystarczy po prostu zasypać port pakietami.

Więcej o różnicach między atakami TCP i UDP w kontekście Minecrafta pisaliśmy w artykule Ataki TCP vs UDP.

RakNet i jego osobliwości

Bedrock Edition używa RakNet na bazie UDP. RakNet dokłada własny poziom niezawodności - retransmisję utraconych pakietów, porządkowanie, fragmentację. Ale wszystko to działa na bazie UDP, co znaczy, że pierwszy pakiet i tak przychodzi bez żadnej weryfikacji.

GeyserMC musi przyjąć i rozparsować przychodzący pakiet RakNet, zanim zdecyduje, czy to legitny klient. To znaczy, że każdy śmieciowy pakiet na porcie 19132 zużywa zasoby CPU na parsowanie.

Realne scenariusze ataków na port UDP

W praktyce ataki na port 19132 wyglądają tak. Atakujący ustala, że na serwerze działa GeyserMC (to łatwo sprawdzić, wysyłając RakNet ping). Potem możliwych jest kilka wariantów:

Wolumetryczny UDP flood. Zwykłe wysyłanie ogromnej liczby śmieciowych pakietów UDP na port 19132. Cel - zatkać kanał lub przeciążyć stos sieciowy. Ochrona: rate limiting na poziomie firewalla, filtracja na poziomie hostingu.

RakNet handshake flood. Sprytniejszy atak: wysyłanie ważnych pakietów RakNet Open Connection Request z podrobionymi IP. Geyser próbuje odpowiedzieć na każde zapytanie, marnuje zasoby na obsługę. Ponieważ IP są podrobione, odpowiedzi idą w kosmos, ale zasoby zostały już zużyte.

Slowloris dla UDP. Otwieranie wielu półgotowych sesji RakNet, które nie kończą handshake. Każda taka sesja zajmuje slot i pamięć. Jeśli liczba takich sesji zombie przekroczy limit, legitni klienci nie mogą się połączyć.

Wszystkie trzy scenariusze są aktualne i spotykane w praktyce. Do każdego potrzebne jest własne podejście w ochronie.

Floodgate: autentykacja graczy Bedrock

Jeden z kluczowych problemów crossplay to autentykacja. Java Edition używa kont Mojang/Microsoft. Bedrock Edition używa Xbox Live. To dwa różne systemy, i trzeba je jakoś połączyć.

Co robi Floodgate

Floodgate to plugin-towarzysz dla GeyserMC. Pozwala graczom Bedrock wchodzić na serwer Java bez konieczności posiadania konta Java. Floodgate sprawdza autentykację Xbox Live i przepuszcza gracza z prefiksem (zazwyczaj kropka: .PlayerName).

# config.yml (Floodgate)
# Prefiks dla nicków graczy Bedrock
username-prefix: "."

# Wyłączyć sprawdzanie nazwy po stronie Java dla graczy Bedrock
replace-spaces: true

Dlaczego Floodgate jest krytycznie ważny

Bez Floodgate masz dwie opcje:

Online mode (auth-type: online). Gracze Bedrock muszą mieć licencjonowane konto Java i wpisywać jego dane przy każdym podłączeniu przez GeyserMC. Niewygodnie, a większość graczy Bedrock po prostu nie ma konta Java.

Offline mode (auth-type: offline). Gracze Bedrock wchodzą w ogóle bez weryfikacji. Każdy może się podłączyć na dowolny nick. To pełna katastrofa z punktu widzenia bezpieczeństwa - spoofing kont, kradzież ekwipunku, dupe uprawnień.

Floodgate rozwiązuje problem: autentykacja Xbox Live potwierdza tożsamość gracza, a prefiks zapobiega konfliktom z nickami Java.

Klucze szyfrowania Floodgate

Floodgate generuje parę kluczy (public/private). Publiczny klucz stawiany jest na GeyserMC, prywatny na serwerze backend. Pozwala to serwerowi sprawdzić, że dane o graczu Bedrock naprawdę przyszły od Geyser, a nie zostały podrobione.

Jeśli ktoś dostanie dostęp do twojego prywatnego klucza Floodgate, będzie mógł podrobić autentykację graczy Bedrock. Przechowuj klucze tak samo starannie, jak forwarding secret Velocity.

GeyserMC za proxy: prawidłowa architektura

Najbezpieczniejsza konfiguracja to GeyserMC za proxy Velocity. Jeśli jeszcze nie przeszedłeś na Velocity, polecam najpierw przeczytać Velocity vs BungeeCord: dlaczego pora migrować. Rozkminiamy, jak to wygląda.

Architektura

Klient Bedrock (UDP:19132)
    ↓
GeyserMC (standalone lub plugin na Velocity)
    ↓
Proxy Velocity (TCP)
    ↓
Serwery backend Paper

Klienci Java łączą się bezpośrednio z Velocity po TCP. Klienci Bedrock łączą się z GeyserMC po UDP, który tłumaczy ich do TCP i przekazuje do Velocity. Z punktu widzenia backendu wszyscy gracze wyglądają tak samo.

Geyser jako plugin Velocity

Rekomendowany wariant. Geyser stawiany jest bezpośrednio na 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 przy tym nasłuchuje UDP:19132 na tej samej maszynie, gdzie stoi Velocity. Translacja dzieje się wewnątrz jednego procesu, bez hopów sieciowych.

Floodgate na Velocity + backendach

Floodgate trzeba postawić i na Velocity, i na każdym serwerze backend. Na Velocity obsługuje autentykację. Na backendach potrzebny jest do poprawnego wyświetlania skinów i UUID graczy Bedrock.

Klucze muszą się zgadzać na wszystkich serwerach. Skopiuj key.pem z instancji Velocity na każdy backend.

Ochrona przed UDP flood na porcie 19132

Teraz do praktyki. Jak zabezpieczyć otwarty port UDP przed atakami.

Rate limiting przez iptables

Podstawowa ochrona - ograniczenie liczby pakietów z jednego IP:

# Limit nowych połączeń na 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

# Limit rozmiaru pakietu (pakiety RakNet nie powinny być ogromne)
iptables -A INPUT -p udp --dport 19132 -m length --length 1500:65535 -j DROP

Wartości 100/sec i burst 150 to punkt wyjścia. Dostosuj pod swój realny ruch. Jeśli masz 50 graczy Bedrock, 100 pakietów/sek na IP bardziej niż wystarczy. Jeśli widzisz tysiące pakietów z jednego IP - to na bank nie jest legitny klient.

Ograniczenie po GeoIP

Jeśli twoi gracze są głównie z określonego regionu, można ograniczyć port UDP po geografii. To nie rozwiązanie, ale zmniejsza powierzchnię ataku:

# Przykład: zezwól na UDP 19132 tylko z RU, UA, KZ, BY
iptables -A INPUT -p udp --dport 19132 \
  -m geoip ! --src-cc RU,UA,KZ,BY -j DROP

Wyłączenie odpowiedzi na nielegitne pakiety

W konfiguracji GeyserMC są ustawienia, które pomagają zmniejszyć obciążenie od śmieciowego ruchu:

# config.yml (Geyser)
bedrock:
  # Nie odpowiadać na ping od niepodłączonych klientów
  enable-proxy-protocol: false

  # Ograniczyć liczbę jednoczesnych połączeń
  # (nie out of the box, ale można przez pluginy)

Fail2ban dla UDP

Skonfiguruj fail2ban do monitoringu logów GeyserMC i blokowania adresów IP generujących błędy:

# /etc/fail2ban/jail.local
[geyser-flood]
enabled = true
port = 19132
protocol = udp
filter = geyser-flood
logpath = /path/to/geyser/logs/latest.log
maxretry = 50
findtime = 10
bantime = 3600

Standalone vs Plugin: co bezpieczniejsze

Rozkminiamy zalety i wady każdego trybu z punktu widzenia bezpieczeństwa.

Plugin mode

Geyser działa jako plugin na twoim serwerze lub proxy.

Plusy:

• Prosta konfiguracja, wszystko w jednym procesie
• Mniej punktów awarii
• Integracja Floodgate out of the box

Minusy:

• Port UDP otwarty na tej samej maszynie, gdzie działa serwer gry
• DDoS na UDP:19132 obciąża tę samą maszynę, która obsługuje graczy Java
• Luka w Geyserze teoretycznie kompromituje cały serwer

Standalone mode

Geyser działa jako osobna aplikacja, być może na osobnej maszynie.

Plusy:

• Izolacja: DDoS na port Bedrock nie wpływa na serwer Java
• Można postawić na osobnej maszynie z osobnym IP
• Elastyczniejsze zarządzanie zasobami
• Jeśli Geyser padnie, serwer Java nadal działa

Minusy:

• Trudniejszy w konfiguracji
• Dodatkowy hop sieciowy (nieduży lag)
• Trzeba osobno śledzić aktualizacje

Dla serwerów z poważnym online polecam standalone na osobnej maszynie. Dla małych serwerów - plugin na Velocity.

Izolacja Docker dla standalone

Jeśli wybrałeś standalone, rozważ uruchomienie GeyserMC w kontenerze Docker. Daje to dodatkowy poziom izolacji:

# 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
    networks:
      - minecraft
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 512M

Ograniczenie CPU i RAM przez Docker znaczy, że nawet jeśli GeyserMC zacznie zużywać zasoby z powodu ataku, nie zdoła "zjeść" zasobów całej maszyny. Serwer Java nadal będzie działał normalnie.

Dodatkowo można skonfigurować automatyczny restart kontenera przy padzie i monitoring zdrowia przez healthcheck. To nie ochrona przed DDoS, ale ochrona przed awarią usługi.

Autentykacja Xbox Live vs offline mode

To decyzja, która określa cały model bezpieczeństwa twojego crossplay-serwera.

Online mode (Xbox Live)

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

Każdy gracz Bedrock musi być autoryzowany przez Xbox Live. To znaczy:

• Zweryfikowana tożsamość każdego gracza
• Ochrona przed spoofingiem kont
• Możliwość bana po Xbox Live ID, a nie tylko po IP
• Kompatybilność z Floodgate

Minus jeden: gracze na customowych klientach lub pirackich wersjach Bedrock nie zalogują się. Dla większości serwerów to plus, a nie minus.

Offline mode

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

Brak jakiejkolwiek weryfikacji. Dowolny klient może połączyć się na dowolne imię. To akceptowalne tylko dla lokalnych testowych serwerów. Na produkcji offline mode dla Bedrock to zaproszenie do chaosu:

• Każdy może wejść na cudzy nick
• Ban po nicku bezużyteczny (zmienił nick - wszedł ponownie)
• Ban po IP bezużyteczny (VPN, mobilny internet)
• Spoofing kont administratorów

Używaj online mode. Zawsze.

Hybrydowe podejście: online mode + Floodgate

Optymalna konfiguracja wygląda tak:

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

# Floodgate obsługuje autentykację Bedrock
# Online mode zapewnia weryfikację kont Java

Przy takim podejściu:

• Gracze Java przechodzą standardową autentykację Mojang/Microsoft
• Gracze Bedrock autentykowani są przez Xbox Live
• Floodgate łączy oba procesy i dokłada prefiks do nicków Bedrock
• Żaden gracz nie zaloguje się bez weryfikacji

To złoty standard dla serwerów crossplay. Tak, konfiguracja jest nieco trudniejsza niż samo auth-type: offline. Ale różnica między "działa" a "działa bezpiecznie" tkwi właśnie w tych szczegółach.

Wydajność i odporność na DDoS

GeyserMC dokłada overhead. Każdy pakiet Bedrock trzeba przyjąć po UDP, rozparsować z formatu RakNet, przekonwertować do formatu Java i przekazać dalej po TCP. Z powrotem to samo. To nie jest darmowe.

Ile zasobów zużywa GeyserMC

Na każdego gracza Bedrock GeyserMC zużywa około 1.5-2 razy więcej CPU niż na zwykłego gracza Java. Zużycie RAM też jest wyższe, bo trzeba trzymać stan translacji dla każdego połączenia.

Jeśli twój serwer przewidziany jest na 100 graczy, a 30 z nich to Bedrock, licz ich jako ~50 graczy Java pod kątem obciążenia. Planuj zasoby odpowiednio.

Jak to wpływa na odporność na DDoS

Podwyższone zużycie zasobów znaczy, że przy ataku DDoS zapas wytrzymałości serwera jest niższy. Jeśli 60% CPU idzie na translację protokołów w czasie spokoju, to do obróbki legitnego ruchu podczas ataku zostaje mniej headroomu.

Rekomendacje:

• Trzymaj zapas CPU minimum 40% w normalnym trybie
• Monitoruj zużycie GeyserMC osobno od głównego serwera
• Skonfiguruj alerty na anomalny wzrost ruchu UDP

Optymalizacja GeyserMC do zmniejszenia obciążenia

Kilka ustawień, które pomogą zmniejszyć zużycie zasobów:

# config.yml (Geyser)
# Wyłączyć wysyłanie MOTD w RakNet ping (zmniejsza obróbkę zapytań ping)
passthrough-motd: false
passthrough-player-counts: false

# Cachowanie danych (zmniejsza wielokrotną translację)
cache-chunks: true

# Ograniczyć maksimum jednoczesnych połączeń Bedrock
# (pomaga przy ataku botami)
max-players: 50

Ograniczenie max-players w GeyserMC osobno od limitu serwera Java pozwala kontrolować, jaka część zasobów idzie na crossplay. Jeśli twój serwer przewidziany jest na 200 graczy, rozsądnie jest ograniczyć Bedrock do 60-80, zostawiając gwarantowane sloty dla klientów Java.

Ochrona DDoS dla mieszanego ruchu TCP+UDP

Ochrona serwera z crossplay jest trudniejsza niż ochrona czystego serwera Java. Masz dwa protokoły, dwa porty, dwa różne modele ruchu.

Co potrzebne od ochrony DDoS

Filtracja TCP (Java). Standardowa historia: SYN flood, TCP amplification, ataki application-layer. Tu działają sprawdzone metody - SYN cookies, connection tracking, rate limiting.

Filtracja UDP (Bedrock). Tu jest trudniej. Trzeba umieć odróżniać legitny ruch RakNet od śmieci. Zwykły rate limiting po IP działa, ale zgrubnie. Bardziej zaawansowane podejście to parsowanie nagłówków RakNet i odsiewanie pakietów z niepoprawną strukturą.

Jednolity monitoring. Atakujący często uderzają w oba porty jednocześnie. TCP flood + UDP flood. Jeśli twoja ochrona obrabia je osobno i nie widzi wspólnego obrazu, może przepuścić kombinowany atak.

Rozwiązania w rodzaju MineGuard filtrują oba typy ruchu na poziomie sieciowym, zanim pakiety dotrą do twojego serwera. Jest to szczególnie ważne dla UDP, gdzie spoofing IP czyni ochronę application-level mniej skuteczną.

Proxy Protocol dla Bedrock

Jeśli twój Geyser stoi za sieciowym proxy lub ochroną DDoS, trzeba przepuścić realne adresy IP graczy. Bez tego wszyscy gracze Bedrock będą widoczni z adresu IP proxy, co czyni bany bezużytecznymi.

# config.yml (Geyser)
bedrock:
  enable-proxy-protocol: true
  proxy-protocol-whitelisted-ips:
    - "10.0.0.0/8"
    - "172.16.0.0/12"

Obowiązkowo ogranicz whitelist do adresów twojej ochrony. Inaczej atakujący będzie mógł podrobić nagłówek Proxy Protocol i podmienić IP.

Checklist bezpieczeństwa GeyserMC

Przejdź przez tę listę, zanim wypuścisz crossplay na produkcję:

Autentykacja:

• auth-type ustawiony na online
• Floodgate zainstalowany i skonfigurowany
• Klucze Floodgate skopiowane na wszystkie serwery backend
• username-prefix ustawiony (domyślnie ".")

Sieć:

• Port 19132 (UDP) ograniczony przez rate limiting w iptables
• Porty backend zamknięte dla zewnętrznego dostępu
• Filtracja GeoIP skonfigurowana (jeśli dotyczy)
• Proxy Protocol skonfigurowany, jeśli Geyser za proxy
• proxy-protocol-whitelisted-ips zawiera tylko adresy twojej ochrony

Architektura:

• Geyser zainstalowany jako plugin Velocity (nie bezpośrednio na backend)
• Velocity używa modern forwarding
• forwarding.secret jest unikalny i przechowywany bezpiecznie

Monitoring:

• Monitoring ruchu UDP na porcie 19132
• Alerty na anomalny wzrost pakietów
• Fail2ban skonfigurowany dla logów Geyser

Aktualizacje:

• GeyserMC zaktualizowany do najnowszej wersji
• Floodgate zaktualizowany do najnowszej wersji
• Wersje GeyserMC i Floodgate są kompatybilne

Częste błędy

Geyser na backendzie zamiast proxy. Jeśli masz Velocity, stawiaj Geysera na Velocity, a nie na serwerach Paper. Inaczej ruch od graczy Bedrock omija proxy i wszystkie jego zabezpieczenia (modern forwarding, rate limiting).

Zapomniany offline mode. Najczęstszy problem. Ludzie ustawiają auth-type: offline "do testu" i zapominają przełączyć. Efekt - na serwerze pojawiają się fejkowe konta.

Ten sam port dla Java i Bedrock. GeyserMC może działać na porcie 25565 (tym samym co Java). To wygodne dla graczy, ale komplikuje filtrację - teraz na jednym porcie są i TCP, i UDP, a ochronie trudniej odróżnić jedno od drugiego.

Brak rate limiting na UDP. Otworzyłeś port 19132, nie postawiłeś żadnego limitu. Pierwszy atak kładzie serwer.

Przestarzałe wersje. GeyserMC aktywnie się rozwija i w każdej aktualizacji domykane są luki. Nie uruchamiaj wersji sprzed miesiąca.

Podsumowanie

GeyserMC to świetne narzędzie, które otwiera twój serwer dla ogromnej publiki graczy Bedrock. Ale każde nowe drzwi to jeszcze jedno wejście, które trzeba pilnować.

Kluczowe sprawy:

1. Port UDP 19132 to nowa powierzchnia ataku. Chroń ją.
2. Używaj Floodgate + online mode. Zawsze.
3. Stawiaj Geyser na proxy (Velocity), a nie na backendzie.
4. Skonfiguruj rate limiting dla ruchu UDP.
5. Dla poważnych serwerów używaj standalone mode z izolacją.
6. Monitoruj ruch UDP osobno od TCP.

Crossplay jest wart tego, żeby skonfigurować go poprawnie. Mobilna i konsolowa publika rośnie szybciej niż Java. Ale tylko wtedy, gdy twój serwer jest gotowy, że razem z nowymi graczami przyjdą też nowe zagrożenia.

Do głębszego zrozumienia różnic między ochroną DDoS Java i Bedrock polecam artykuł Java vs Bedrock: ochrona DDoS.