Checklista bezpieczeństwa serwera Minecraft: 15 punktów na 2026 rok

Bezpieczeństwo serwera Minecraft to nie jednorazowa akcja, tylko proces. Możesz postawić najmocniejszy hosting, najlepsze pluginy, ale jeśli zapomniałeś zamknąć RCON na zewnątrz albo zostawiłeś domyślne hasło, to wszystko nie ma znaczenia.

Ta checklista to 15 konkretnych punktów, które powinien wykonać każdy administrator serwera w 2026 roku. Nie ogólne rady z serii "bądź ostrożny", a konkretne działania z przykładami configów i komend. Przechodź po punktach, zaznaczaj wykonane, i pod koniec artykułu twój serwer będzie chroniony o rząd wielkości lepiej.

1. Aktualizuj oprogramowanie serwera

Brzmi banalnie, ale to właśnie przestarzałe wersje są przyczyną większości włamań. Paper, Velocity, pluginy, sama Java - wszystko musi być aktualne.

Paper regularnie wypuszcza łatki bezpieczeństwa. Gdy w 2024 roku wykryto lukę w obsłudze danych chunków, łatka wyszła w kilka godzin. Ale jeśli siedzisz na wersji sprzed trzech miesięcy, ta łatka ci nie pomoże.

Co robić konkretnie:

• Zapisz się na kanał Paper na Discordzie (sekcja announcements)
• Sprawdzaj aktualizacje pluginów przynajmniej raz w tygodniu
• Używaj Paper 1.21.x albo nowszego
• JDK 21+ (LTS) dla aktualnych łatek bezpieczeństwa Javy

# Sprawdź wersję Javy
java -version

# Pobierz najnowszy Paper (przykład)
wget https://api.papermc.io/v2/projects/paper/versions/1.21.4/builds/latest/downloads/paper-1.21.4-latest.jar

Nie aktualizuj wszystkiego od razu na produkcji. Najpierw testowy serwer, potem główny. Zrób osobny folder albo kontener Docker do testów. Wrzuciłeś aktualizację, puściłeś 30 minut, sprawdziłeś logi, upewniłeś się, że pluginy nie crashują - dopiero wtedy na prod.

Osobna sprawa z pluginami. Wielu adminów stawia plugin i zapomina o nim na lata. A plugin od dawna jest porzucony przez autora, i jest w nim luka. Raz w miesiącu przechodź po liście pluginów i usuwaj to, czego nie używasz. Mniej pluginów - mniejsza powierzchnia ataku.

2. Skonfiguruj firewall

Firewall to pierwsza linia obrony. Bez niego każdy może skanować porty twojego serwera i znajdować otwarte usługi.

Minimalny zestaw reguł iptables dla serwera Minecraft:

# Pozwalamy na established-połączenia
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Pozwalamy na loopback
iptables -A INPUT -i lo -j ACCEPT

# SSH (zmień port na swój, zobacz punkt 4)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Minecraft (główny port)
iptables -A INPUT -p tcp --dport 25565 -j ACCEPT

# Blokujemy całą resztę
iptables -A INPUT -j DROP

Jeśli używasz sieci z kilku serwerów, porty serwerów backendowych muszą być dostępne tylko z proxy:

# Serwery backendowe tylko z localhost
iptables -A INPUT -p tcp --dport 30001:30010 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 30001:30010 -j DROP

Jeśli chcesz zagłębić się bardziej, mamy osobny artykuł o iptables dla Minecrafta.

Nie zapomnij zapisać reguł, żeby przetrwały reboot:

apt install iptables-persistent
netfilter-persistent save

3. Klucze SSH zamiast haseł

Hasła do SSH to przeszłość. Ataki brute force na SSH idą nieustannie, i nawet skomplikowane hasło może być dobrane. Klucze SSH rozwiązują ten problem całkowicie.

# Na lokalnej maszynie: generujemy klucz
ssh-keygen -t ed25519 -C "minecraft-admin"

# Kopiujemy na serwer
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server

# Na serwerze: wyłączamy hasła
sudo nano /etc/ssh/sshd_config

W sshd_config muszą być te linie:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
MaxAuthTries 3

sudo systemctl restart sshd

Po tym wejść na serwer będzie można tylko z kluczem. Żadnych haseł, żadnego brute force.

Ważne: przed wyłączeniem haseł upewnij się, że klucz działa. Otwórz drugie połączenie SSH z kluczem, sprawdź, że wszystko OK, i dopiero wtedy zamykaj pierwsze. Inaczej stracisz dostęp do serwera i będziesz musiał prosić dostawcę hostingu o zresetowanie ustawień.

Bonus: jeśli masz kilku administratorów, każdy musi używać swojego klucza. Nie dzielcie się jednym kluczem. W ten sposób zawsze widzisz w logach, kto się łączył, i możesz cofnąć dostęp konkretnej osobie, nie zmieniając kluczy wszystkim pozostałym.

4. Zmień domyślne porty

Port 22 dla SSH i 25565 dla Minecrafta zna każdy script-kiddie. Zmiana portów nie zatrzyma ukierunkowanego ataku, ale odcina 90% automatycznego skanowania.

Dla SSH:

# /etc/ssh/sshd_config
Port 2847  # Dowolny niestandardowy port

Port Minecrafta zmienić trudniej, bo gracze muszą go znać. Ale SSH - zmieniaj obowiązkowo. Jeśli masz sieć serwerów, porty backendowe ustawiaj niestandardowe i zamykaj firewallem (zobacz punkt 2).

Dodatkowo można zainstalować fail2ban dla SSH:

apt install fail2ban

# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = 2847
maxretry = 3
bantime = 3600
findtime = 600

Fail2ban będzie automatycznie banował IP, które próbują dobrać hasło albo klucz do SSH.

5. Ukryj prawdziwe IP serwera

Jeśli atakujący zna prawdziwy IP twojego serwera, może uderzać bezpośrednio, omijając dowolną ochronę. Ukrycie IP to kluczowy krok.

Główne sposoby:

• Używaj proxy albo ochrony DDoS (gracze łączą się z IP ochrony, a nie z twoim)
• Nie ujawniaj IP w rekordach DNS
• Nie używaj jednego IP do strony i serwera
• Sprawdź historyczne rekordy DNS (SecurityTrails, Shodan)

Często IP wycieka przez nieoczywiste miejsca: logi pluginów, webhooki Discord, panel zarządzania. Sprawdź wszystko.

Jeszcze jedno częste źródło wycieku: błędy w konfiguracji DNS. Mogłeś wcześniej przypisać główną domenę do serwera bezpośrednio, a potem dodać proxy. Ale historyczny rekord A został w bazach typu SecurityTrails. Atakujący patrzy w historię DNS i znajduje twój prawdziwy IP w minutę. Przed włączeniem proxy lepiej zmienić adres IP serwera, jeśli to możliwe.

Szczegółowo omawiamy ten temat w artykule o ukrywaniu IP serwera Minecraft.

6. Velocity zamiast BungeeCord

Jeśli masz sieć serwerów z proxy, BungeeCord to poważne ryzyko. Jego system IPForward przekazuje UUID gracza plain textem. To znaczy, że przy bezpośrednim dostępie do serwera backendowego atakujący może wejść na dowolne konto.

Velocity Modern Forwarding używa HMAC-SHA256 do podpisywania danych. Podrobić nie da się.

# velocity.toml
player-info-forwarding-mode = "modern"

# paper-global.yml na serwerach backendowych
proxies:
  velocity:
    enabled: true
    online-mode: false
    secret: "twoj-sekret-z-forwarding.secret"

Nawet jeśli port backendu przypadkowo okaże się otwarty na zewnątrz, bez ważnego podpisu HMAC połączenie będzie odrzucone. To zasadniczo inny poziom ochrony.

Szczegółowe porównanie i poradnik migracji: Velocity vs BungeeCord.

7. Bezpieczna konfiguracja server.properties

W server.properties jest kilka parametrów, które ludzie zapominają skonfigurować. A szkoda.

# Wyłączyć protokół query
enable-query=false

# Wyłączyć RCON (albo nie wystawiać na zewnątrz)
enable-rcon=false

# Jeśli RCON jest potrzebny - mocne hasło i tylko localhost
rcon.password=DlugieSkomplikowaneHaslo2026!
rcon.port=25575

# Enforce secure profile
enforce-secure-profile=true

# Ograniczenie prędkości łączenia
rate-limit=10

# Ukryj online-count jeśli trzeba
hide-online-players=false

# Biała lista
white-list=false
enforce-whitelist=false

Jeśli masz proxy (Velocity), serwery backendowe muszą nasłuchiwać tylko na localhost:

server-ip=127.0.0.1
server-port=30001

Osobno o online-mode: jeśli serwer jest za proxy, online-mode ustawiasz false na backendzie i true na proxy. Bez proxy - zawsze true, chyba że chcesz serwer piracki.

Jeszcze jeden ważny parametr - max-players. Ustaw realistyczną wartość. Jeśli zwykle masz 50 graczy, nie ma sensu ustawiać 1000. To nie tyle o bezpieczeństwie, co o ochronie przed przeciążeniem. Jeśli botnet zacznie wrzucać boty, ograniczenie slotów przynajmniej częściowo spowolni obciążenie serwera.

Parametr prevent-proxy-connections warto włączyć, jeśli nie używasz proxy. Blokuje połączenia przez VPN i proxy, co utrudnia życie atakującym. Ale jeśli twoi gracze często używają VPN, spowoduje to problemy.

8. System uprawnień dostępu

Domyślny system uprawnień Minecrafta jest minimalny. Potrzebny ci LuckPerms.

Główne zasady:

• Nie dawaj op przez ops.json. Używaj grup uprawnień
• Utwórz hierarchię: default > vip > moderator > admin > owner
• Każda grupa dostaje tylko te uprawnienia, które są jej potrzebne
• Nigdy nie dawaj * (wszystkie uprawnienia) żadnej grupie

# Główne komendy LuckPerms
/lp group default permission set minecraft.command.msg true
/lp group moderator permission set essentials.kick true
/lp group moderator permission set essentials.ban true
/lp group admin parent add moderator

Osobno obserwuj uprawnienia pluginów. Niektóre pluginy przy instalacji dają domyślnej grupie dostęp do niebezpiecznych komend. Sprawdzaj plugin.yml każdego nowego pluginu.

WorldEdit, FAWE, Multiverse - te pluginy dają ogromną władzę. Uprawnienia do nich muszą mieć tylko owner i może senior admin.

Częsty błąd: dać moderatorom uprawnienia do /give albo /gamemode. Przejęte konto moderatora z takimi uprawnieniami zniszczy ekonomię serwera w minuty. Moderatorowi potrzebne są uprawnienia na kick, ban, mute i teleportację. Cała reszta jest zbędna.

Regularnie sprawdzaj uprawnienia. Używaj /lp user <nick> permission info, żeby zobaczyć, jakie uprawnienia ma konkretny gracz. Możesz się zdziwić, ile zbędnych pozwoleń się nazbierało.

9. Anticheat

Cheaterzy to nie tylko problem gameplay'u, ale i bezpieczeństwa. Niektóre cheaty mogą wywołać crash serwera przez exploit pakietów, dupy przedmiotów albo przeciążenie chunków.

Popularne rozwiązania w 2026 roku:

• Grim - darmowy, otwarty kod, dobrze łapie movement cheaty
• Vulcan - płatny, ale bardziej kompletny. Łapie combat, movement, player exploits
• Spartan - średnia opcja, nadaje się do małych serwerów

Każdy anticheat jest lepszy niż żaden. Ale skonfiguruj go prawidłowo: za agresywne ustawienia będą banować zwykłych graczy ze słabym internetem.

# Przykład minimalnej konfiguracji (zależy od pluginu)
# Zwykle włącza się w config.yml anticheata
punishments:
  fly:
    threshold: 10
    action: "kick %player% Unfair advantage detected"
  speed:
    threshold: 8
    action: "kick %player% Unfair advantage detected"

Oprócz standardowego anticheata zwróć uwagę na ochronę przed crasherami. Istnieją specjalne klienty (typu Meteor, Wurst), które wysyłają nieważne pakiety albo książki z ogromnym NBT, wywołując crash serwera albo pojedynczych graczy. Pluginy typu Grim albo osobne rozwiązania typu PacketLimiter pomagają filtrować takie pakiety, zanim zaszkodzą serwerowi.

Skonfiguruj logowanie podejrzanej aktywności. Gdy anticheat kickuje gracza, ta informacja musi być zapisywana ze szczegółami: który check zadziałał, współrzędne, czas. To pomaga odróżnić fałszywe alarmy od prawdziwych cheaterów.

10. Automatyczne backupy

Backupy to nie "jeśli coś się stanie", tylko "kiedy coś się stanie". Bez backupów jeden usunięty świat albo jeden wipe bazy danych oznacza koniec serwera.

Minimalny schemat:

• Codzienne backupy świata, configów i bazy danych
• Przechowywanie na osobnym serwerze albo w chmurze (nie na tym samym dysku)
• Rotacja: trzymać minimum 7 dziennych + 4 tygodniowe

#!/bin/bash
# Prosty skrypt backupu
DATE=$(date +%Y-%m-%d_%H-%M)
BACKUP_DIR="/backups/minecraft"
SERVER_DIR="/opt/minecraft"

# Zatrzymaj autosave
screen -S minecraft -p 0 -X stuff "save-off$(printf '\r')"
screen -S minecraft -p 0 -X stuff "save-all$(printf '\r')"
sleep 5

# Backup
tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" \
    "$SERVER_DIR/world" \
    "$SERVER_DIR/world_nether" \
    "$SERVER_DIR/world_the_end" \
    "$SERVER_DIR/plugins"

# Włącz autosave
screen -S minecraft -p 0 -X stuff "save-on$(printf '\r')"

# Usun backupy starsze niz 14 dni
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +14 -delete

Dodaj do crona:

# Codziennie o 4:00
0 4 * * * /opt/scripts/backup.sh

I koniecznie sprawdzaj backupy. Backup, którego nie da się przywrócić, jest bezużyteczny. Raz w miesiącu próbuj rozpakować backup na testowym serwerze.

Nie zapomnij backupować bazy danych, jeśli używasz MySQL/MariaDB dla pluginów (LuckPerms, ekonomia, dane graczy):

# Backup bazy MySQL
mysqldump -u minecraft -p minecraft_db > "$BACKUP_DIR/db-$DATE.sql"

Trzymaj backupy nie na tym samym serwerze. Jeśli serwer padnie albo zostanie zhakowany, backupy na nim też przepadną. Używaj rsync na drugi serwer, S3-kompatybilnego storage (Backblaze B2 - tanio), albo nawet zwykłego FTP na innej maszynie. Najważniejsze - fizyczne rozdzielenie.

11. Monitoring zasobów

Jeśli nie monitorujesz serwera, nie dowiesz się o problemie, dopóki gracze nie zaczną narzekać. W tym momencie może już być za późno.

Co monitorować:

• CPU - stałe obciążenie powyżej 80% to problem
• RAM - wycieki pamięci od pluginów
• Dysk - logi i chunki mogą zjeść całe miejsce
• Sieć - anomalny ruch wskazuje na atak
• TPS - poniżej 18 to zauważalne lagi

Do prostego monitoringu:

# Zainstaluj htop do ręcznej kontroli
apt install htop

# Spark - monitoring TPS i profilowanie wewnątrz Minecrafta
# Zainstaluj jako plugin i używaj /spark tps, /spark profiler

Do poważnego monitoringu używaj Prometheus + Grafana. Paper wspiera eksport metryk przez spark. Skonfiguruj alerty na anomalie: gwałtowny wzrost CPU, spadek TPS, skok ruchu przychodzącego.

Przydatne też monitorować liczbę połączeń. Jeśli normalnie masz 20-50 graczy, a nagle jest 500 połączeń - to pewnie atak botów. Prosty sposób sprawdzenia:

# Liczba połączeń TCP na port Minecrafta
ss -tn state established '( dport = :25565 )' | wc -l

# Albo liczba unikalnych IP
ss -tn state established '( dport = :25565 )' | awk '{print $5}' | cut -d: -f1 | sort -u | wc -l

Skonfiguruj alerty w Telegramie albo Discordzie. Gdy TPS spada poniżej 15 albo CPU jest powyżej 90%, musisz się dowiedzieć o tym natychmiast, a nie za pół godziny ze skarg graczy.

12. Ochrona DDoS

Ataki DDoS na serwery Minecraft to codzienność. Konkurenci, obrażeni gracze, script-kiddies - motywacja może być dowolna. Bez ochrony nawet mały atak położy serwer.

Co trzeba zrozumieć:

• Dostawca hostingu zwykle chroni przed atakami volumetrycznymi (L3/L4), ale nie przed application-level (L7)
• Ataki specyficzne dla Minecrafta (bot join flood, null ping, handshake flood) wymagają wyspecjalizowanej filtracji
• Zwykły TCPShield albo HAProxy nie pomoże przeciwko zaawansowanym atakom

Wyspecjalizowana ochrona dla Minecrafta (taka jak MineGuard) analizuje protokół Minecrafta i odcina boty na poziomie handshake. Zwykłe filtry L3/L4 nie widzą różnicy między botem a graczem, bo oboje używają identycznych pakietów TCP.

Jeśli chcesz zrozumieć podstawy, zacznij od naszego poradnika dla początkujących o ochronie serwera Minecraft.

Osobno warto wspomnieć o exploitach Javy. Log4Shell (CVE-2021-44228) w swoim czasie dotknął tysiące serwerów Minecraft. Chociaż ten konkretny exploit jest dawno załatany, podobne luki na poziomie JVM wciąż się pojawiają. Ochrona DDoS nie pomoże przeciwko exploitowi w kodzie. Dlatego aktualizacje (punkt 1) i ochrona DDoS działają razem, pokrywając różne typy zagrożeń.

13. Ochrona paneli zarządzania

Pterodactyl, AMP, Multicraft - każdy serwer ma jakiś panel zarządzania. I często jest zabezpieczony gorzej niż sam serwer.

Cheklista dla panelu:

• Mocne hasło + 2FA dla wszystkich kont
• HTTPS (nie HTTP) - Let's Encrypt jest darmowy
• Ogranicz dostęp po IP, jeśli możliwe
• Aktualizuj panel regularnie
• Osobny subdomen (panel.example.com), nie na głównym IP serwera

Dla Pterodactyla konkretnie:

# Włącz 2FA dla administratorów (w ustawieniach panelu)
# Skonfiguruj nginx z SSL
apt install certbot python3-certbot-nginx
certbot --nginx -d panel.example.com

# Ogranicz dostęp do panelu admina po IP w nginx
location /admin {
    allow 1.2.3.4;  # Twoj IP
    deny all;
}

Wings (daemon Pterodactyla) też trzeba chronić. Port 8080 nie może być dostępny publicznie.

Jeśli używasz SFTP do wgrywania plików, upewnij się, że użytkownik SFTP ma dostęp tylko do folderu serwera, a nie do całego systemu plików. Pterodactyl robi to automatycznie przez izolację Docker, ale jeśli używasz zwykłego SFTP, skonfiguruj chroot.

Hasła do paneli muszą być unikalne. Nie używaj tego samego hasła, co do SSH albo bazy danych. Jeśli jedna usługa zostanie skompromitowana, pozostałe pozostaną bezpieczne.

14. Wyłącz niepotrzebne funkcje

Każdy otwarty port i każda włączona usługa to potencjalny punkt wejścia. Wyłączaj wszystko, czego nie używasz.

Najczęstsi winowajcy:

Query Protocol (port 25565 UDP) - używany do list serwerów. Jeśli nie listujesz serwera na GameTrackerze albo podobnych, wyłączaj.

# server.properties
enable-query=false

RCON (port 25575) - zdalna konsola. Jeśli używasz, przypisz do localhost. Jeśli nie - wyłączaj.

enable-rcon=false
# Albo jesli potrzebny:
enable-rcon=true
rcon.port=25575
rcon.password=BardzoSkomplikowaneHaslo

# Przypisz RCON do localhost przez iptables
iptables -A INPUT -p tcp --dport 25575 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25575 -j DROP

JMX Monitoring - Java Management Extensions. Jeśli włączony, daje pełny dostęp do JVM. Upewnij się, że port JMX jest zamknięty.

GeyserMC - jeśli używasz dla graczy Bedrock, port 19132 UDP musi być otwarty. Jeśli nie używasz - usuń plugin.

Zasada jest prosta: jeśli nie wiesz, po co port jest otwarty, zamknij go i zobacz, co się popsuje. Nic się nie popsuło? Znaczy, że był zbędny.

Przydatna komenda do audytu otwartych portów:

# Pokaz wszystkie porty, ktore nasluchuja
ss -tlnp

# Albo przez nmap (skanuj swoj serwer z zewnatrz)
nmap -sT -p 1-65535 your-server-ip

Skanuj swój serwer z zewnątrz raz w miesiącu. Zdziwisz się, ile portów może być otwartych bez twojej wiedzy: plugin podniósł serwer HTTP na porcie 8123, DynMap otworzył interfejs webowy, MySQL nasłuchuje na 3306 na zewnątrz.

15. Plan reagowania na incydenty

To punkt, który wszyscy pomijają. A potem o 3 w nocy, gdy serwer leży, gorączkowo googlują "co robić".

Twój plan musi zawierać:

Przy ataku DDoS:

1. Włączyć ochronę / skontaktować się z dostawcą ochrony
2. Sprawdzić, czy nie wyciekł prawdziwy IP (jeśli tak - zmieniać IP)
3. Powiadomić graczy przez Discorda
4. Logować atak do analizy

Przy włamaniu:

1. Natychmiast odłączyć serwer od sieci
2. Zmienić wszystkie hasła (SSH, panele, RCON, baza)
3. Sprawdzić logi - co zostało zmienione
4. Przywrócić z backupu (zobacz punkt 10)
5. Usunąć lukę, przez którą weszli
6. Powiadomić graczy, jeśli dane mogły wyciec

Przy dupe/exploicie:

1. Zatrzymać serwer
2. Wycofać do backupu sprzed exploitu
3. Zaktualizować plugin, który wywołał problem
4. Sprawdzić szkody w ekonomii serwera

Zapisz ten plan w dokumencie i daj dostęp wszystkim administratorom. Gdy zdarza się incydent, nie ma czasu na myślenie. Trzeba działać zgodnie z planem.

Kontakty muszą być pod ręką:

• Dostawca hostingu (telefon, system zgłoszeń)
• Dostawca ochrony DDoS
• Starszy administrator (telefon)

Rób "ćwiczenia" raz na pół roku. Udawaj, że zdarzył się incydent, i przejdź po planie. Zmierz czas odzyskiwania. Jeśli odzyskiwanie z backupu zajmuje 4 godziny, a myślałeś że 30 minut - lepiej dowiedzieć się tego na ćwiczeniach, a nie w trakcie prawdziwego włamania.

Trzymaj plan w miejscu dostępnym, nawet jeśli serwer leży. Google Docs, Notion, wydrukowana kartka - cokolwiek, byle nie na samym serwerze. Bo gdy serwer jest zhakowany, nie przeczytasz planu, który leży na tym serwerze.

Podsumowanie

Przejdźmy po checkliście krótko:

1. Aktualizuj Paper, pluginy, Javę
2. Skonfiguruj iptables/ufw
3. Klucze SSH, bez haseł
4. Niestandardowe porty dla SSH
5. Ukryj prawdziwe IP
6. Velocity zamiast BungeeCord
7. Bezpieczny server.properties
8. LuckPerms, bez op
9. Anticheat
10. Backupy codziennie
11. Monitoring CPU/RAM/TPS
12. Ochrona DDoS
13. Ochrona paneli (2FA, HTTPS)
14. Wyłącz query, RCON, zbędne
15. Plan reagowania na incydenty

Nie musisz robić wszystkiego w jeden dzień. Zacznij od pierwszych pięciu punktów - są najważniejsze i zajmują parę godzin. Potem stopniowo zamykaj resztę.

Bezpieczeństwo to nie stan, tylko proces. Nowe luki pojawiają się nieustannie. Przeglądaj tę checklistę raz na kwartał i aktualizuj ustawienia.

Lepiej poświęcić weekend na bezpieczeństwo, niż stracić serwer i graczy przez atak, któremu można było zapobiec.