Ustawienia bezpieczeństwa Paper i Spigot: co włączyć, a co wyłączyć

Serwer Minecraft ma dziesiątki plików konfiguracyjnych. I w każdym z nich są ustawienia, które bezpośrednio wpływają na bezpieczeństwo. Problem w tym, że większość adminów zostawia wartości domyślne. A domyślne są nastawione na kompatybilność, nie na ochronę.

W tym artykule rozbierzemy każdy plik po kolei. Dla każdego ustawienia wyjaśnię nie tylko "ustaw taką wartość", ale dlaczego właśnie taką. Zrozumienie powodów jest ważniejsze niż kopiowanie cudzych configów.

server.properties: fundament

Ten plik jest czytany jako pierwszy przy uruchomieniu serwera. Zarządza podstawowym zachowaniem vanilla Minecraft i właśnie tutaj znajdują się krytycznie ważne przełączniki.

online-mode

online-mode=true

To najważniejsze ustawienie bezpieczeństwa na całym serwerze. Kropka. Kiedy online-mode=true, serwer sprawdza każdego łączącego się gracza przez serwery uwierzytelniania Mojang. To gwarantuje, że gracz faktycznie posiada konto, pod którym wchodzi.

Kiedy online-mode=false, każdy może wejść pod dowolnym nickiem. Chcesz wejść pod nickiem administratora? Proszę bardzo. Chcesz wejść pod nickiem innego gracza i zabrać jego rzeczy? Łatwizna. Wystarczy zmienić nick w launcherze.

Jedyny wyjątek: jeśli serwer działa za proxy (Velocity, BungeeCord). W tym przypadku online-mode=false na serwerach backendu jest dopuszczalne, bo uwierzytelnianie wykonuje proxy. Ale wtedy obowiązkowo potrzebna jest poprawna konfiguracja forwardingu (o tym niżej).

Jeśli masz standalone serwer bez proxy, online-mode musi być true. Bez wyjątków.

enable-query

enable-query=false

Protokół query pozwala zewnętrznym aplikacjom odpytywać informacje o serwerze: listę graczy, wersję, opis, zainstalowane pluginy. Brzmi niewinnie, ale w praktyce tworzy dwa wektory ataku.

Pierwszy: wyciek informacji. Atakujący dostaje listę pluginów i ich wersji. Wiedząc, że masz AuthMe 5.6.0, może poszukać znanych podatności dla tej wersji. Lista graczy online pomaga określić aktywność serwera i wybrać czas do ataku.

Drugi: query działa po UDP. A port UDP przyjmujący dowolne zapytania to gotowy wektor do amplifikacji. Atakujący może wykorzystać twój port query do ataków odbitych na inne serwery, a odpowiadać za to będziesz ty.

Wyłącz query. Do monitoringu są lepsze rozwiązania: pluginy z API, RCON (z ograniczeniami), zewnętrzne serwisy monitoringu.

enable-rcon

enable-rcon=false
rcon.port=25575
rcon.password=

RCON (Remote Console) daje pełny dostęp do konsoli serwera po sieci. To jak SSH, tylko dla Minecrafta. I problem jest dokładnie ten sam: jeśli ktoś dostanie dostęp do RCON, dostanie pełną kontrolę nad serwerem. Może wykonywać dowolne komendy, zmieniać ustawienia, banować graczy, instalować pluginy.

Jeśli RCON nie jest potrzebny, wyłącz. Jeśli jest potrzebny (do automatyzacji, panelu zarządzania), to:

1. Używaj złożonego hasła, co najmniej 20 znaków
2. Ogranicz dostęp firewallem tylko z localhost lub IP panelu
3. Nigdy nie otwieraj portu RCON na zewnątrz

# Zezwól na RCON tylko z localhost
iptables -A INPUT -p tcp --dport 25575 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 25575 -j DROP

network-compression-threshold

network-compression-threshold=256

Ten parametr określa minimalny rozmiar pakietu (w bajtach), po którym zostanie skompresowany. Wartość domyślna 256 oznacza, że pakiety większe niż 256 bajtów będą kompresowane przed wysyłką.

Wydawałoby się, co to ma wspólnego z bezpieczeństwem? Kompresja zmniejsza ruch, ale zwiększa obciążenie CPU. Atakujący, który wysyła serwerowi mnóstwo małych pakietów, może zmusić serwer do marnowania zasobów na niepotrzebną kompresję/dekompresję.

Wartość 256 jest uznawana za optymalny balans. Jeśli ustawić za nisko (np. 64), serwer będzie kompresował prawie każdy pakiet, marnując CPU na próżno. Jeśli ustawić -1, kompresja wyłączy się całkowicie, a ruch wzrośnie.

Dla serwerów za proxy można ustawić -1, bo kompresję wykonuje proxy. Dla standalone serwerów zostaw 256.

rate-limit

rate-limit=15

Ogranicza liczbę pakietów na sekundę z jednego połączenia. Wartość domyślna 0 oznacza brak limitu. To źle. Jeden klient ze zmodyfikowanym launcherem może wysyłać tysiące pakietów na sekundę, przeciążając serwer.

Wartość 15 oznacza, że serwer będzie wyrzucał połączenie, jeśli wysyła więcej niż 15 pakietów na tick (50 ms). To wystarczająco do normalnej gry, ale odcina agresywny spam.

Nie myl z packet-limiter w Paper (o nim niżej). rate-limit w server.properties działa na niższym poziomie, przed obsługą pakietów przez rdzeń serwera.

prevent-proxy-connections

prevent-proxy-connections=false

Ten parametr zmusza serwer do sprawdzania, czy gracz nie łączy się przez proxy lub VPN, używając API Mojang. Jeśli sprawdzenie pokaże, że IP gracza różni się od IP, z którego przechodziła autoryzacja, połączenie jest odrzucane.

Na papierze brzmi przydatnie. W praktyce ta weryfikacja powoduje kilka problemów. Po pierwsze, tworzy dodatkowe opóźnienie przy łączeniu, bo serwer wysyła zapytanie do Mojang API. Po drugie, może blokować legalnych graczy, którzy używają VPN dla zwiększenia bezpieczeństwa lub z powodu ograniczeń dostawcy.

Dla standalone serwerów można włączyć prevent-proxy-connections=true jako dodatkową warstwę ochrony. Ale jeśli już używasz pluginu do blokowania VPN (lub serwisu typu MineGuard, który filtruje boty i proxy na poziomie sieci), sens tego ustawienia jest mały.

Za proxy (Velocity/BungeeCord) to ustawienie trzeba zostawić na false, inaczej wszystkie połączenia będą odrzucane, bo IP proxy nie zgadza się z IP uwierzytelnienia.

max-players

max-players=100

Wydawałoby się, że to ustawienie pojemności, nie bezpieczeństwa. Ale pomyśl: jeśli na twoim serwerze normalnie gra 30 osób, po co trzymać limit 1000? Przy ataku botów wszystkie 1000 slotów będą zajęte przez boty, a każdy z nich tworzy obciążenie na serwerze.

Ustawiaj max-players nieco wyżej niż realne online. Jeśli zwykle jest 30 graczy, ustaw 50-70. To ograniczy skalę ataków botów i zmniejszy obciążenie przy próbie floodowania połączeniami.

spigot.yml: poziom wyżej

Spigot dodaje swoją warstwę ustawień nad vanilla. Wiele z nich wpływa na wydajność, ale niektóre są krytycznie ważne dla bezpieczeństwa.

connection-throttle

settings:
  connection-throttle: 4000

Określa minimalny odstęp (w milisekundach) między połączeniami z jednego IP. Wartość 4000 oznacza, że jedno IP może się łączyć nie częściej niż raz na 4 sekundy.

Po co: przy ataku botów setki połączeń idą z każdego IP na sekundę. Connection throttle blokuje powtórne próby, zmniejszając obciążenie na proces autoryzacji.

Ważny niuans: jeśli serwer stoi za proxy (Velocity/BungeeCord), to wszystkie połączenia przychodzą z jednego IP (IP proxy). W tym przypadku connection-throttle trzeba wyłączyć (ustawić -1), inaczej będzie blokował legalnych graczy.

# Za proxy:
settings:
  connection-throttle: -1

bungeecord

settings:
  bungeecord: false

Ten flag włącza wsparcie IP-forwardingu od BungeeCord. Jeśli bungeecord: true, serwer ufa danym o prawdziwym IP gracza, które przekazuje proxy przez specjalne pole w pakiecie handshake.

Problem: jeśli włączysz bungeecord: true na serwerze, który nie jest chroniony przez proxy, każdy może podrobić swoje IP. To nie teoretyczna podatność, są gotowe narzędzia do IP-spoofingu przez BungeeCord-forwarding. Atakujący może wejść pod IP administratora i obejść IP-bana, albo wejść z IP innego gracza.

Zasada prosta: bungeecord: true tylko jeśli serwer faktycznie stoi za BungeeCord I port backendu jest zamknięty firewallem od zewnętrznych połączeń. We wszystkich innych przypadkach false.

Jeszcze lepiej: zamiast BungeeCord używaj Velocity z modern forwarding. Więcej o tym w naszym artykule o Velocity vs BungeeCord.

moved-wrongly-threshold i moved-too-quickly-multiplier

settings:
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 10.0

Te parametry kontrolują sprawdzenia anticheat ruchu na poziomie serwera. moved-wrongly-threshold określa dopuszczalne odchylenie pozycji gracza od oczekiwanej. moved-too-quickly-multiplier zadaje mnożnik maksymalnej prędkości przemieszczania się.

Domyślne wartości są wystarczająco łagodne i pasują do większości serwerów. Jeśli ustawić za surowo, normalni gracze z lagami będą dostawać teleportacje w tył. Jeśli za łagodnie, cheaterzy będą mogli latać i teleportować się bez detekcji.

Dla serwerów PvP, gdzie krytyczne jest zapobiec speed-hack i fly, można ustawić trochę surowiej:

settings:
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 8.0

Ale do poważnej ochrony przed cheatami lepiej postawić plugin-anticheat (Grim, Vulcan), a nie polegać na wbudowanych sprawdzeniach.

log-filter i player-shuffle

settings:
  log-filter:
    - "Moved too quickly!"
    - "moved wrongly!"

Logowanie "Moved too quickly" i "moved wrongly" jest przydatne do diagnostyki, ale przy ataku botów te komunikaty mogą zapychać log tysiącami linii na sekundę, tworząc obciążenie IO. Jeśli skonfigurowałeś packet-limiter i anticheat, możesz dodać te komunikaty do filtru logów.

player-shuffle: 0 (domyślne) określa kolejność obsługi graczy. Wartość 0 wyłącza tasowanie. Na serwerach PvP zaleca się ustawić niezerową wartość, aby kolejność obsługi ticków nie dawała przewagi graczom, którzy połączyli się wcześniej.

timeout-time i restart-on-crash

settings:
  timeout-time: 30
  restart-on-crash: true

timeout-time określa, po ilu sekundach serwer uznaje zawieszone połączenie za martwe. Domyślne 60 sekund to za dużo. 30 sekund wystarcza do normalnej gry, ale martwe połączenia będą zamykane szybciej, uwalniając zasoby.

restart-on-crash: true automatycznie restartuje serwer przy crashu. Krytycznie ważne dla ochrony przed crash-exploitami: jeśli atakujący znalazł sposób na uszczuklenie serwera, to on chociaż podniesie się z powrotem automatycznie. Więcej o crash-exploitach przeczytaj w osobnym artykule.

paper-global.yml: potężne narzędzia Paper

Paper dodaje ogromną ilość ustawień bezpieczeństwa, których nie ma w Spigot. To jedna z głównych przyczyn, dlaczego warto używać Paper zamiast czystego Spigot.

packet-limiter

packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0

To wbudowany anti-crash od Paper. Packet-limiter śledzi liczbę pakietów określonego typu za przedział czasu i wyrzuca klienta, jeśli limit jest przekroczony.

Domyślna konfiguracja: nie więcej niż 500 pakietów dowolnego typu za 7 sekund. Dla ServerboundCommandSuggestionPacket (autouzupełnianie komend) limit jest surowszy: 15 pakietów na sekundę. Czemu? Bo autouzupełnianie komend wywołuje obsługę po stronie serwera, a spam tymi pakietami może stworzyć znaczne obciążenie.

Dla dodatkowej ochrony można dodać limity na inne "ciężkie" pakiety:

packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0
    ServerboundContainerClickPacket:
      interval: 1.0
      max-packet-rate: 25.0
    ServerboundPlaceRecipePacket:
      interval: 1.0
      max-packet-rate: 5.0
    ServerboundSetCreativeModeSlotPacket:
      interval: 1.0
      max-packet-rate: 10.0

ServerboundContainerClickPacket odpowiada za kliknięcia w sloty ekwipunku. Spam klikami to klasyczny sposób na obciążenie serwera lub zduplikowanie przedmiotów. ServerboundPlaceRecipePacket jest używany do autocraftingu. ServerboundSetCreativeModeSlotPacket ogranicza szybkość umieszczania przedmiotów w kreatywie.

Nie ustawiaj limitów za nisko. Jeśli max-packet-rate dla all będzie 100, normalni gracze będą wyrzucani przy aktywnej grze (otwieranie skrzyń, handel, PvP). 500 za 7 sekund to około 71 pakietów na sekundę, co wystarcza do normalnej gry.

velocity-support

proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'złożony-sekretny-klucz-z-velocity'

Jeśli używasz Velocity jako proxy, ta sekcja zastępuje przestarzałe bungeecord: true w spigot.yml. Modern forwarding w Velocity używa HMAC do podpisywania danych gracza, co czyni podrabianie IP niemożliwym (w przeciwieństwie do BungeeCord).

secret musi się zgadzać z kluczem w forwarding-secret po stronie Velocity. Używaj długiego losowego klucza, nie "password123".

Nie włączaj velocity-support i bungeecord jednocześnie. To nie ma sensu i może stworzyć konflikty.

Więcej o przewagach Velocity nad BungeeCord pisaliśmy w osobnym artykule. Tam też omawiane są null-ataki i inne exploity, na które BungeeCord jest podatny.

incoming-packet-threshold

packet-limiter:
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0

Globalny próg pakietów przychodzących. Działa razem z packet-limiter. Jeśli klient przekracza max-packet-rate za podany interval, połączenie jest zrywane.

Domyślne 500 pakietów za 7 sekund zazwyczaj wystarcza. Na serwerach z ciężkim PvP (Factions, KitPvP) można podnieść do 600, bo aktywna walka generuje więcej pakietów ruchu i ataku.

Logowanie

logging:
  log-player-ip-addresses: false

Domyślnie Paper loguje adresy IP graczy. Jeśli jesteś w jurysdykcji z RODO (Europa) lub po prostu chcesz zminimalizować przechowywanie danych osobowych, wyłącz to. Adresy IP w logach to wyciek danych przy kompromitacji serwera.

paper-world-defaults.yml: ochrona świata

Te ustawienia są stosowane do wszystkich światów domyślnie. Wiele z nich zapobiega konkretnym exploitom.

max-entity-collisions

collisions:
  max-entity-collisions: 2

Ogranicza maksymalną liczbę kolizji bytów na tick. Domyślna wartość 8 pozwala tworzyć "ściskarki" z bytów, które generują ogromną liczbę obliczeń kolizji i zarzynają TPS.

Wartość 2 radykalnie zmniejsza obciążenie od entity cramming. Dla większości serwerów 2 wystarcza. Na serwerach z farmami zwierząt (SMP) można ustawić 4, ale wyżej niż 8 nie zaleca się.

To bezpośrednio ochrona przed określonym typem crash-exploitów: atakujący zagania setki mobów w jeden blok, a serwer wydaje wszystkie zasoby na obliczenia kolizji.

max-auto-save-chunks-per-tick

chunks:
  max-auto-save-chunks-per-tick: 8

Określa, ile chunków serwer zapisuje na dysk za jeden tick. Im większa wartość, tym szybszy zapis, ale tym większe lagi przy auto-save.

Z punktu widzenia bezpieczeństwa: jeśli atakujący modyfikuje mnóstwo chunków (wybuchy TNT, lava-casty), wysoka wartość oznacza, że serwer będzie próbował zapisać wszystkie uszkodzone chunki jednocześnie, tworząc sztorm IO.

Wartość 8 zapewnia płynny zapis bez zauważalnych spadków TPS.

entity-per-chunk-save-limit

entity-per-chunk-save-limit:
  experience_orb: 16
  snowball: 8
  ender_pearl: 8
  arrow: 16
  fireball: 8
  small_fireball: 8
  item: 32

Ogranicza liczbę bytów określonego typu, zapisywanych w jednym chunku. Bez tego limitu atakujący może stworzyć chunk z tysiącami bytów, który będzie się wiecznie ładował i lagował.

Najważniejsze limity:

• experience_orb: 16 zapobiega lag-maszynom z doświadczenia
• arrow: 16 nie daje zapisać tysięcy strzał z bot-strzelania
• item: 32 ogranicza liczbę wyrzuconych przedmiotów

Te limity nie wpływają na normalną grę, ale ratują przed celowym sabotażem.

fix-entity-position-desync

fixes:
  fix-entity-position-desync: true

Naprawia rozsynchronizację pozycji bytów między serwerem a klientem. Bez tego fixa niektóre cheaty mogą wykorzystywać rozsynchronizowanie do tworzenia niewidzialnych bytów lub przemieszczania się przez ściany. Zostaw włączone.

anti-xray

anticheat:
  anti-xray:
    enabled: true
    engine-mode: 2

Anti-Xray nie jest ustawieniem bezpieczeństwa w klasycznym sensie, ale zapobiega wykorzystaniu zasobów serwera przez xray-cheaty. engine-mode: 2 zastępuje ukryte rudy fałszywymi blokami, co tworzy obciążenie, ale zapewnia lepszą ochronę. engine-mode: 1 po prostu ukrywa rudy, zużywając mniej zasobów.

Dla serwerów z ekonomią na surowcach (SMP, survival) zaleca się engine-mode: 2. Dla mini-gier i PvP, gdzie rudy nie są ważne, można zostawić engine-mode: 1 lub wyłączyć.

bukkit.yml: bazowe ograniczenia

bukkit.yml zawiera ustawienia wspólne dla wszystkich serwerów opartych na CraftBukkit (włącznie ze Spigot i Paper).

connection-throttle

settings:
  connection-throttle: 4000

Działa analogicznie do connection-throttle w spigot.yml. W praktyce, jeśli obie wartości są ustawione, priorytet ma spigot. Ale lepiej ustawić tę samą wartość w obu plikach dla spójności.

Rekomendacja ta sama: 4000 dla standalone, -1 za proxy.

spawn-limits

spawn-limits:
  monsters: 50
  animals: 8
  water-animals: 3
  water-ambient: 5
  water-underground-creature: 3
  axolotls: 3
  ambient: 1

Ograniczenia na liczbę mobów w świecie. Domyślne wartości vanilla są zawyżone. 70 potworów na gracza to za dużo dla większości serwerów.

Z punktu widzenia bezpieczeństwa: mniej mobów oznacza mniejsze obciążenie serwera. Jeśli atakujący próbuje sprowokować lag przez tworzenie mobów (spawnery, jajka), niskie limity ograniczają jego możliwości.

Wartość monsters: 50 zapewnia normalny gameplay (moby się spawnują, farmy działają), ale nie pozwala przeciążyć serwera.

chunk-gc

chunk-gc:
  period-in-ticks: 400

Garbage collector dla chunków. Określa, jak często serwer sprawdza i wyładowuje chunki bez graczy w pobliżu. Domyślne 600 ticków (30 sekund) można zmniejszyć do 400 (20 sekund).

Po co: im szybciej wyładowują się niepotrzebne chunki, tym mniej pamięci zajmuje serwer. Przy atakach związanych z generowaniem nowych chunków (chunk-loading exploits), szybkie wyładowanie zmniejsza kumulację obciążenia.

Kompleksowa konfiguracja: zbieramy wszystko razem

Oto końcowy zestaw ustawień bezpieczeństwa dla standalone Paper serwera:

# server.properties
online-mode=true
enable-query=false
enable-rcon=false
network-compression-threshold=256
rate-limit=15
max-players=100
prevent-proxy-connections=false

# spigot.yml
settings:
  bungeecord: false
  connection-throttle: 4000
  timeout-time: 30
  restart-on-crash: true
  moved-wrongly-threshold: 0.0625
  moved-too-quickly-multiplier: 10.0

# paper-global.yml
packet-limiter:
  kick-message: '<red><lang:disconnect.exceeded_packet_rate>'
  limits:
    all:
      interval: 7.0
      max-packet-rate: 500.0
    ServerboundCommandSuggestionPacket:
      interval: 1.0
      max-packet-rate: 15.0
proxies:
  velocity:
    enabled: false
    online-mode: true
    secret: ''
logging:
  log-player-ip-addresses: false

# paper-world-defaults.yml
collisions:
  max-entity-collisions: 2
chunks:
  max-auto-save-chunks-per-tick: 8
entity-per-chunk-save-limit:
  experience_orb: 16
  arrow: 16
  item: 32
  snowball: 8

# bukkit.yml
settings:
  connection-throttle: 4000
spawn-limits:
  monsters: 50
  animals: 8
  water-animals: 3
  ambient: 1
chunk-gc:
  period-in-ticks: 400

Konfiguracja za proxy (Velocity)

Jeśli serwer stoi za Velocity, konfiguracja wygląda inaczej:

# server.properties
online-mode=false
enable-query=false
enable-rcon=false
network-compression-threshold=-1
rate-limit=0

# spigot.yml
settings:
  bungeecord: false
  connection-throttle: -1

# paper-global.yml
proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: 'twój-sekretny-klucz-z-velocity-forwarding-secret'

Zwróć uwagę: online-mode=false w server.properties, ale online-mode: true w velocity-support. Uwierzytelnianie wykonuje Velocity, a backend serwer ufa danym od proxy. network-compression-threshold=-1, bo kompresję wykonuje Velocity. connection-throttle: -1, bo wszystkie połączenia idą z IP proxy.

I obowiązkowo: zamknij port backend serwera firewallem. Jeśli port 25565 jest otwarty na zewnątrz przy online-mode=false, każdy może wejść bezpośrednio, omijając proxy i uwierzytelnianie.

# Zezwól na połączenia do backendu tylko z IP proxy
iptables -A INPUT -p tcp --dport 25565 -s IP_PROXY -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 -j DROP

Czego nie warto ruszać

Nie wszystkie ustawienia trzeba zmieniać. Oto co lepiej zostawić domyślnie:

• max-tick-time w server.properties. Ustawianie -1 ("nie crashować serwera przy zawieszeniu") wydaje się dobrym pomysłem, ale w praktyce oznacza to, że zawieszony serwer będzie wisieć wiecznie zamiast restartu. Lepiej zostawić domyślne 60000 i ustawić restart-on-crash: true.
• view-distance w spigot.yml. Zmniejszenie obniża obciążenie, ale to ustawienie wydajności, nie bezpieczeństwa. Nie ustawiaj poniżej 6, inaczej gameplay ucierpi.
• allow-end i allow-nether w bukkit.yml. Wyłączenie wymiarów nie zwiększa bezpieczeństwa, tylko psuje gameplay.

Czego configi nie rozwiązują

Poprawne ustawienia configów zamykają wiele wektorów ataku. Ale nie zastępują innych warstw ochrony.

Configi nie ochronią przed atakami DDoS na poziomie sieci. Do tego potrzebna jest zewnętrzna filtracja ruchu, na przykład przez MineGuard. Limity pakietów Paper odcinają crash-exploity, ale przeciwko strumieniowi 10 Gbit/s są bezsilne.

Configi nie zastępują firewalla. Nawet z idealnymi ustawieniami server.properties, otwarte porty SSH, RCON, baz danych to dziury w bezpieczeństwie. Firewall jest obowiązkowy.

Configi nie zastępują aktualizacji. Jeśli w Paper znajdą podatność, żadne ustawienia nie pomogą, potrzebny jest patch. Aktualizuj się regularnie.

Najlepsze podejście to kombinacja: poprawne configi + firewall + ochrona DDoS + regularne aktualizacje. Każda warstwa zamyka swoje zagrożenia. Więcej o kompleksowym podejściu do bezpieczeństwa przeczytaj w checkliście bezpieczeństwa serwera Minecraft.

Automatyzacja sprawdzania

Nie chcesz sprawdzać configów ręcznie? Oto prosty skrypt, który pokaże główne problemy:

#!/bin/bash
echo "=== Security Config Check ==="

# server.properties
if grep -q "online-mode=false" server.properties 2>/dev/null; then
  echo "[WARN] online-mode is FALSE"
fi
if grep -q "enable-query=true" server.properties 2>/dev/null; then
  echo "[WARN] query is enabled"
fi
if grep -q "enable-rcon=true" server.properties 2>/dev/null; then
  echo "[WARN] RCON is enabled"
fi
if grep -q "rate-limit=0" server.properties 2>/dev/null; then
  echo "[WARN] rate-limit is disabled"
fi

echo "=== Check complete ==="

Dodaj go do cron albo uruchamiaj po każdej zmianie konfiguracji.

Częste błędy

Kilka typowych błędów, które popełniają nawet doświadczeni admini:

Włączony bungeecord bez proxy. To chyba najbardziej niebezpieczny błąd. Admin kiedyś testował BungeeCord, włączył bungeecord: true, potem usunął proxy, ale zapomniał wyłączyć flag. Teraz każdy może podrobić IP przy łączeniu.

RCON z prostym hasłem, otwarty na zewnątrz. Często spotykane na serwerach z panelami zarządzania. Panel działa na innym serwerze i łączy się do RCON po sieci. Ale port jest otwarty dla wszystkich, a hasło to "minecraft123". Rezultat przewidywalny.

online-mode: false na standalone bez powodu. Niektórzy admini wyłączają uwierzytelnianie "żeby piraci mogli wchodzić". To otwiera drzwi do podmiany kont. Jeśli potrzebne jest wsparcie nielicencjonowanych klientów, używaj AuthMe lub podobnego pluginu, ale najlepiej pracować z online-mode: true.

Zbyt agresywne limity pakietów. Jeśli ustawisz max-packet-rate: 50 w packet-limiter, gracze będą masowo wyrzucani przy otwieraniu ekwipunku sprzedawcy lub aktywnym PvP. Testuj limity na serwerze testowym przed zastosowaniem na prodzie.

Podsumowanie

Bezpieczeństwo serwera Minecraft zaczyna się od poprawnych configów. Nie od pluginów, nie od ochrony DDoS, tylko od pięciu plików, które kontrolują bazowe zachowanie serwera.

Skonfiguruj server.properties, spigot.yml, paper-global.yml, paper-world-defaults.yml i bukkit.yml zgodnie z rekomendacjami z tego artykułu. To zajmie 15 minut i zamknie dziesiątki wektorów ataku, które są eksploatowane codziennie.

A dalej: firewall, proxy, monitoring i regularne aktualizacje. Każda warstwa dodaje ochronę, i żadna z nich nie jest zbędna.