Bezpieczny serwer Minecraft to nie jeden plugin antygriefingowy. To połączenie uwierzytelniania, minimalnych uprawnień, kontroli dostępu do konsoli, zaufanego oprogramowania i backupu, który pozwala cofnąć skutki błędu.
Najważniejsze konkrety
- Uwierzytelnianie
- Dla zwykłego serwera publicznego pozostaw online-mode=true; wyjątki wymagają świadomej architektury proxy.
- Operator
- OP otrzymują wyłącznie osoby, które naprawdę administrują; pozostałe prawa nadaj grupami i pojedynczymi węzłami.
- Panel i SSH
- Unikalne hasło, MFA, osobne konta oraz brak współdzielenia dostępu przez wiadomości lub pliki tekstowe.
- Odzyskanie
- Kopie poza serwerem, log zmian i przećwiczona procedura przywrócenia ograniczają skutki włamania lub griefu.
1. Nie wyłączaj uwierzytelniania jako szybkiej naprawy
W publicznym serwerze Java ustaw online-mode=true, chyba że masz bardzo konkretny, świadomy powód i rozumiesz konsekwencje architektury proxy. Wyłączenie uwierzytelniania nie jest rozwiązaniem problemu z logowaniem - zmienia model zaufania i może pozwolić na podszywanie się pod cudze nazwy. Osobny poradnik wyjaśnia, co naprawdę oznacza serwer non-premium, jak zmieniają się UUID i dlaczego lokalne /register nie zastępuje weryfikacji konta.
Weryfikuj też, czy adres i wersja podane graczom są prawidłowe. Jeżeli używasz proxy albo crossplay, bezpieczeństwo trzeba ocenić dla całej ścieżki: proxy, backendu, pluginów i panelu administracyjnego, a nie tylko dla jednego pliku.
2. Włącz whitelistę podczas testów
Whitelist ogranicza możliwość wejścia do wybranych graczy, ale nie zastępuje ochrony budowli ani moderacji. Przed premierą ustaw white-list=true, dodaj testerów i sprawdź onboarding bez narażania otwartego serwera na przypadkowe wejścia. Przy projekcie zamkniętym włącz także enforce-whitelist=true, aby serwer odrzucał osoby spoza listy.
W trybie publicznym możesz wyłączyć whitelistę dopiero, gdy działa spawn, regulamin, system zgłoszeń i backup. Opisz graczom, jakie dane są wymagane do wejścia i gdzie zgłaszać nadużycia. Sama whitelist nie wykrywa grieferów, nie naprawia pluginów i nie cofa zmian w świecie.
3. Ogranicz liczbę operatorów
Ranga operatora daje bardzo szerokie możliwości, więc nie rozdawaj jej wszystkim moderatorom i testerom. Utrzymuj krótką listę osób z dostępem, przeglądaj ops.json i odbieraj operatora po zakończeniu testów. Do codziennej moderacji użyj systemu uprawnień z osobnymi rangami i minimalnymi permission nodes.
Nie wklejaj do konsoli przypadkowych komend z filmu lub czatu. Najpierw sprawdź dokumentację pluginu, zakres działania i możliwość cofnięcia zmiany. Przy operacjach na świecie zapisz backup oraz osobę, która zatwierdziła działanie.
4. Traktuj RCON jak dostęp do konsoli
Jeśli nie korzystasz z RCON, nie włączaj go „na wszelki wypadek”. Gdy jest potrzebny, użyj osobnego, długiego sekretu, ogranicz dostęp zaporą do konkretnego panelu lub adresu i nie publikuj portu oraz hasła w Discordzie. Nie zapisuj danych RCON w publicznym repozytorium ani w logach aplikacji.
To samo dotyczy panelu hostingu, SFTP i konta właściciela. Włącz wieloskładnikowe logowanie tam, gdzie jest dostępne, używaj osobnych kont dla zespołu i odbieraj dostęp osobom, które przestały pracować przy projekcie. Uprawnienia infrastruktury i uprawnienia w grze powinny być rozdzielone.
5. Instaluj tylko zaufane pluginy
Plugin nie jest zwykłym dodatkiem graficznym. PaperMC ostrzega, że pluginy mają pełny, nieograniczony dostęp do serwera i maszyny (otwiera w nowej karcie). Pobieraj je z oficjalnej strony projektu, sprawdź autora, wersję, zależności i komentarze o bezpieczeństwie. Nie uruchamiaj plików JAR z przypadkowego załącznika.
Po instalacji sprawdź logs/latest.log, listę aktywnych pluginów i nowe połączenia. Jeden plugin nie powinien zastępować backupu, kontroli operatorów i aktualizacji. Jeśli dodatek ma dostęp do ekonomii, komend lub danych graczy, traktuj jego wybór jak decyzję infrastrukturalną.
6. Połącz kontrolę dostępu z reakcją na awarię
Regularnie przeglądaj logi, backupy, listę operatorów, whitelistę i aktualizacje pluginów. Ustal, kto reaguje na crash, griefing i podejrzane logowania. Przy incydencie najpierw ogranicz dostęp, zachowaj logi i wykonaj kopię bieżącego stanu, a dopiero potem przywracaj świat lub usuwaj pliki.
Dokumentacja server.properties w PaperMC (otwiera w nowej karcie) opisuje między innymi whitelistę, online-mode, port RCON i poziom uprawnień operatora. Trzymaj się referencji dla swojej wersji, bo nazwy i wartości mogą się zmieniać.
Po zmianie członka zespołu unieważnij jego dostęp do panelu, SFTP, RCON i Discorda, a przy podejrzeniu wycieku zmień sekrety zamiast tylko usuwać wiadomość z czatu. Rotacja ma sens tylko wtedy, gdy nowe hasło nie trafia do starego skryptu lub wspólnego pliku bez kontroli dostępu.
Przed otwarciem serwera
online-mode=truejest świadomą decyzją dla serwera publicznego;- whitelist działa podczas testów i ma tylko potrzebnych graczy;
- operatorów jest minimum, a moderatorzy korzystają z ograniczonych rang;
- RCON jest wyłączony albo chroniony sieciowo i silnym sekretem;
- pluginy pochodzą ze sprawdzonych źródeł i mają znaną wersję;
- backup, logi i procedura incydentu zostały przetestowane;
- konta panelu, SFTP i administracji mają osobne dostępy.
Bezpieczeństwo warto komunikować także graczom: aktualny regulamin, oficjalny Discord i prawidłowy adres w profilu serwera Java ograniczają liczbę pomyłek jeszcze przed wejściem.
Plan działania krok po kroku
- 1
Zrób ewidencję kont z dostępem do panelu, SSH, konsoli, RCON i operatora; usuń dostęp, którego nie potrafisz uzasadnić.
- 2
Włącz MFA, zmień współdzielone hasła i ogranicz porty zaporą do usług faktycznie wystawianych publicznie.
- 3
Skonfiguruj grupy uprawnień zgodnie z zasadą najmniejszego dostępu i przetestuj osobno konto gracza, moderatora oraz administratora.
- 4
Wykonaj kopię poza maszynę, sprawdź logi i przećwicz scenariusz: wyłączenie wejść, rotacja sekretów, analiza zmian i przywrócenie.
