Whitelist vs Online Mode w Minecrafcie - co jest bezpieczniejsze?

Dwa parametry w server.properties, które mylą nawet doświadczonych adminów: white-list i online-mode. Oba dotyczą dostępu graczy do serwera, ale działają zupełnie inaczej. Jeden sprawdza tożsamość gracza, drugi - jego obecność na liście. A jeśli niepoprawnie skonfigurujesz choć jeden z nich, konsekwencje mogą być od "ktoś wszedł pod moim nickiem" po "cały świat zniszczony przez grieferów".

Rozbijmy to. Co robi każdy z nich, jakie ryzyka niesie każda konfiguracja i jak zabezpieczyć serwer naprawdę.

Czym jest online-mode

online-mode=true to parametr w server.properties, który mówi serwerowi: "sprawdzaj każdego łączącego się gracza przez serwery Mojang". Gdy gracz wchodzi na serwer, klient wysyła zapytanie na sessionserver.mojang.com, a Mojang potwierdza, że to konto rzeczywiście należy do tego, kto próbuje się połączyć.

Co to daje w praktyce:

• Każdy gracz dostaje unikalny UUID przypięty do kupionego konta
• Nikt nie może wejść pod cudzym nickiem - serwer po prostu nie przepuści
• Wszystkie dane (ekwipunek, uprawnienia, banki) przypinane są do UUID, a nie do nicku
• Skiny ładują się poprawnie przez serwery Mojang

UUID to podstawa identyfikacji. Gdy online-mode=true, UUID wygląda jak 069a79f4-44e9-4726-a5be-fca90e38aaf5 i jest generowany przez Mojang dla każdego kupionego konta. Nie zmienia się, nawet jeśli gracz zmieni nick. Wszystkie pluginy, bazy danych i dane świata przypinane są właśnie do tego identyfikatora.

Co się dzieje przy online-mode=false

Gdy ustawiasz online-mode=false, serwer przestaje sprawdzać konta przez Mojanga. Dowolny klient może podłączyć się z dowolnym nickiem. UUID jest generowane offline z nicku wg wzoru UUID.nameUUIDFromBytes("OfflinePlayer:NickGracza") - to tzw. offline UUID.

Dlaczego to niebezpieczne:

• Każdy może wejść pod nickiem administratora i dostać jego uprawnienia
• UUID przypięty do nicku, nie konta - zmiana nicku = utrata wszystkich danych
• Nie sposób odróżnić prawdziwego gracza od samozwańca
• Ataki botów stają się trywialne - nie trzeba kupować kont, wystarczy losować nicki

Tak, tryb offline pozwala grać ludziom bez kupionego konta. Ale ceną jest całkowity brak wbudowanego systemu identyfikacji.

Czym jest whitelist

white-list=true włącza białą listę - plik whitelist.json zawierający listę graczy, którzy mają pozwolenie na łączenie się z serwerem. Wszyscy inni dostają komunikat "You are not white-listed on this server!" i nie mogą wejść.

Zarządzanie listą jest proste:

/whitelist add NickGracza
/whitelist remove NickGracza
/whitelist list
/whitelist reload

Whitelist działa na poziomie połączenia - serwer sprawdza nick (i UUID, jeśli online-mode=true) zanim gracz w ogóle wejdzie na serwer. Oznacza to, że nieznajomi nie tylko nie zagrają - nawet nie zobaczą świata.

Whitelist + online-mode: jak ze sobą współpracują

Tu kluczowy moment. Przy online-mode=true whitelist sprawdza UUID gracza. Przy online-mode=false - tylko nick. Różnica jest ogromna.

Z online-mode=true + whitelist: serwer sprawdza, że gracz to realnie osoba, za którą się podaje (przez Mojanga), I że jest na białej liście. Podwójne sprawdzenie. Maksymalne bezpieczeństwo.

Z online-mode=false + whitelist: serwer sprawdza tylko nick. A nick może wpisać ktokolwiek. Whitelist w tym przypadku to zamek w drzwiach, którego kluczem jest po prostu znajomość imienia właściciela.

Cracked serwery: realne ryzyka

Cracked serwery (z online-mode=false) to nie tylko "serwery dla piratów". To serwery z fundamentalnie innym modelem bezpieczeństwa, gdzie standardowe mechanizmy ochrony Minecrafta nie działają.

Oto co może pójść nie tak:

Kradzież kont. Bez autoryzacji Mojanga każdy może wejść pod dowolnym nickiem. Jeśli admin server.properties whitelist nie pomoże, bo atakujący po prostu wpisze nick admina. Bez dodatkowych pluginów wszystkie dane, uprawnienia i ekwipunek będą dostępne dla atakującego.

Ataki botów. Na serwer online-mode atak botów wymaga setek albo tysięcy kupionych kont (albo skradzionych tokenów). Na cracked - bot po prostu losuje nicki. Koszt ataku spada do zera. Bot może stworzyć 1000 połączeń na minutę z różnymi nickami i każde z nich serwer musi obsłużyć.

Spoofing UUID. W trybie offline UUID jest przewidywalne - liczone z nicku. Oznacza to, że atakujący może z góry wyliczyć UUID dowolnego gracza i potencjalnie manipulować danymi.

Exploity przez fake-nicki. Niektóre pluginy ufają nickowi albo UUID bez dodatkowej weryfikacji. Na cracked-serwerze otwiera to dziury - od eskalacji uprawnień do SQLi, jeśli plugin nie escape'uje nicku przy zapytaniu do bazy danych.

AuthMe: proteza, która stała się standardem

Jeśli twój serwer działa w trybie offline, AuthMe to pierwsza rzecz, którą musisz zainstalować. Dodaje system rejestracji i logowania ponad standardowym połączeniem.

Jak to działa: przy pierwszym wejściu gracz musi wykonać /register hasło hasło. Przy kolejnych wejściach - /login hasło. Do autoryzacji gracz nie może się ruszać, łamać bloków, pisać na czacie ani interagować ze światem.

AuthMe trzyma hasła w formie zhashowanej (bcrypt domyślnie), wspiera MySQL/MariaDB, ma ochronę przed brute force i kupę ustawień. Dla offline-serwerów to obowiązkowe minimum.

Ale AuthMe to nie zamiennik online-mode. To łatka. Oto dlaczego:

• Gracz musi pamiętać jeszcze jedno hasło (i wielu ustawia "123456")
• Jeśli baza danych AuthMe wycieknie, wszystkie konta są skompromitowane
• Istnieją timing-ataki i inne sposoby obejścia
• Nowi gracze gubią się przy rejestracji i odchodzą

Dla serwerów z dużą audiencją krakerów AuthMe w parze z FastLogin (autologin dla kont licencyjnych) to działająca konfiguracja. Ale jeśli masz możliwość działać w online-mode - działaj w online-mode.

Więcej o pluginach bezpieczeństwa i ich konfiguracji w naszym przeglądzie pluginów.

BungeeCord i Velocity: tryby forwarding i bezpieczeństwo

Gdy masz sieć serwerów za proxy (BungeeCord albo Velocity), sytuacja się komplikuje. Proxy odpowiada za autoryzację, a serwery backend działają w online-mode=false, bo sprawdzenie wykonało już proxy. Ale otwiera to nowy wektor ataku - jeśli ktoś podłączy się do backendu bezpośrednio, omijając proxy, obejdzie całą autoryzację.

Legacy forwarding (BungeeCord)

Stary mechanizm. BungeeCord przekazuje UUID i IP gracza przez specjalne pola w pakiecie handshake. Backend ślepo ufa tym danym, jeśli w spigot.yml stoi bungeecord: true.

Problem: każdy może podrobić te pola. Jeśli backend jest dostępny po bezpośrednim IP, atakujący może się podłączyć i udawać kogokolwiek - choćby administratora. Dlatego firewall zamykający porty backendu od dostępu zewnętrznego to nie opcja, a konieczność.

BungeeGuard

BungeeGuard rozwiązuje problem legacy forwarding przez wspólny sekretny token. Proxy dodaje token do handshake, a backend sprawdza jego obecność. Jeśli tokenu nie ma albo jest błędny - połączenie odrzucone. To proste i skuteczne rozwiązanie, jeśli z jakichś powodów nie możesz przejść na Velocity.

Modern forwarding (Velocity)

Velocity używa własnego mechanizmu forwarding, który kryptograficznie podpisuje dane gracza. Backend sprawdza podpis za pomocą wspólnego sekretu. Podrobić tych danych bez znajomości sekretu nie da się.

W configu Velocity to player-info-forwarding-mode = "modern", a na backendzie w paper-global.yml trzeba podać ten sam sekret. To najbezpieczniejszy sposób przekazywania danych o graczu w 2026 roku.

Rekomendacja: jeśli stawiasz sieć od zera - używaj Velocity z modern forwarding. Jeśli jesteś już na BungeeCord i nie możesz migrować - stawiaj BungeeGuard i zamykaj porty.

Realne scenariusze ataków

Zobaczmy, jak to wygląda w praktyce. Parę sytuacji, które widziałem nieraz.

Scenariusz 1: Przejęcie konta admina na cracked-serwerze

Serwer z online-mode=false, bez AuthMe. Admin z nickiem "ServerAdmin" ma OP. Atakujący wchodzi pod nickiem "ServerAdmin", dostaje wszystkie uprawnienia, robi /op swojemu głównemu kontu, niszczy spawn i banuje wszystkich. Cały proces zajmuje 30 sekund.

Ochrona: AuthMe + silne hasła, OP tylko przez konsolę (nigdy przez /op w grze), użycie pluginów uprawnień zamiast OP.

Scenariusz 2: Flood botów na cracked-serwerze

Atakujący odpala botnet, który generuje setki połączeń na sekundę z losowymi nickami. Serwer traci zasoby na obsługę każdego połączenia, TPS leci w dół, prawdziwi gracze nie mogą wejść. Jeśli AuthMe jest zainstalowany - boty utykają na ekranie logowania, ale i tak żrą zasoby.

Ochrona: LimboFilter na proxy (odsiewa boty przed trafieniem na główny serwer), rate-limiting po IP, zewnętrzne filtrowanie ruchu.

Scenariusz 3: Bezpośrednie podłączenie do backendu

Sieć serwerów: BungeeCord + kilka Spigotów. Admin zapomniał zamknąć port 25566 (jeden z serwerów backend). Na backendzie stoi bungeecord: true i online-mode=false. Atakujący łączy się bezpośrednio, podrabia handshake z UUID admina, dostaje pełny dostęp.

Ochrona: firewall (tylko proxy może podłączyć się do backendu), BungeeGuard albo przejście na Velocity modern forwarding, regularny audyt otwartych portów.

Scenariusz 4: UUID collision na offline-serwerze

Na offline-serwerze UUID liczony jest z nicku. Atakujący tworzy konto z nickiem, który daje taki sam UUID jak u celowego gracza (przez brute force albo specjalne narzędzia). Rezultat: dostęp do ekwipunku, enderchesta i danych pluginów celowego gracza.

Ochrona: online-mode=true rozwiązuje problem w pełni, bo UUID wydawane jest przez Mojanga i nie zależy od nicku.

Którą konfigurację wybrać

Oto moje rekomendacje w zależności od typu serwera:

Prywatny serwer dla znajomych: online-mode=true + white-list=true. Maksymalna ochrona minimalnym wysiłkiem. Nikt z zewnątrz nie wejdzie.

Publiczny serwer licencyjny: online-mode=true + whitelist wyłączony. Autoryzacja Mojanga daje podstawowe bezpieczeństwo. Dodaj pluginy bezpieczeństwa w razie potrzeby.

Publiczny cracked-serwer: online-mode=false + AuthMe + FastLogin + LimboFilter. To zestaw minimalny. Bez tego serwer będzie stale atakowany. A nawet z tym - ryzyka wyższe niż u licencyjnego.

Sieć serwerów (BungeeCord/Velocity): proxy w online-mode=true, backend w online-mode=false + Velocity modern forwarding (albo BungeeGuard). Firewall na backendach obowiązkowo.

Łączenie whitelist + online-mode

Najlepsza opcja dla serwerów, gdzie potrzebna ścisła kontrola dostępu - włączyć oba. online-mode=true gwarantuje, że gracz to ten, za kogo się podaje. white-list=true ogranicza dostęp do konkretnej listy zweryfikowanych osób.

To idealne dla:

• Serwerów w fazie developmentu (żeby przypadkowi ludzie nie wchodzili)
• Prywatnych serwerów społecznościowych
• Serwerów z wartościową zawartością (duże projekty, gdzie griefing = ogromne straty)
• Serwerów testowych, gdzie trzeba kontrolować środowisko

Jedyny minus - zarządzanie whitelistą wymaga ręcznej roboty. Każdego gracza trzeba dodawać ręcznie. Ale dla bezpieczeństwa to drobna cena.

Checklista bezpieczeństwa serwera

Oto podstawowa checklista, którą warto przejść dla dowolnego serwera:

1. online-mode=true - jeśli nie ma ważnych powodów do trybu offline
2. whitelist - włącz, jeśli serwer nie jest publiczny
3. Firewall - zamknij wszystkie porty poza potrzebnymi (25565 dla głównego, reszta przez VPN albo sieć wewnętrzną)
4. AuthMe - obowiązkowo dla offline-serwerów
5. Velocity modern forwarding - dla sieci serwerów
6. Backupy - regularne, na osobny serwer
7. Monitoring - śledź podejrzane logowania i anomalie

Więcej szczegółów do każdego punktu - w naszej pełnej checkliście bezpieczeństwa.

W sumie

Online-mode i whitelist rozwiązują różne zadania. Online-mode to o autoryzacji: "czy jesteś tym, za kogo się podajesz?". Whitelist to o autoryzacji dostępu: "czy masz pozwolenie, żeby tu wejść?".

Oba mechanizmy uzupełniają się. Online-mode bez whitelisty chroni przed samozwańcami, ale nie przed niechcianymi gośćmi. Whitelist bez online-mode chroni przed przypadkowymi wejściami, ale nie przed celowym spoofingiem.

Jeśli możesz - włącz oba. Jeśli działasz w trybie offline - kompensuj brak autoryzacji Mojanga pluginami. I w każdym przypadku - nie zapominaj o bezpieczeństwie sieciowym: firewall, poprawny forwarding i zewnętrzna ochrona przed DDoS.