Ochrona serwera Minecraft Bedrock przed atakami DDoS

Serwer Minecraft Bedrock, który wieczorami na kilka minut znika z listy serwerów, a potem wraca, rzadko ma problem ze sprzętem. Zwykle trwa atak, i trwa dokładnie wtedy, gdy online jest najwięcej graczy. Ten artykuł pokazuje, jak chronić serwer Minecraft Bedrock przed atakami DDoS: najpierw to, co możesz zabezpieczyć sam i bez dodatkowych kosztów, potem miejsce, w którym te działania kończą się fizycznie, a na koniec to, co musi wydarzyć się w sieci przed serwerem.

Wszystkie informacje dotyczą Bedrock Dedicated Server, PocketMine-MP albo Nukkit na Debianie 12, Debianie 13, Ubuntu 22.04 LTS albo Ubuntu 24.04 LTS. Polecenia są napisane dla użytkownika root, jako zwykły użytkownik poprzedź je poleceniem sudo. Kto prowadzi Java Edition, znajdzie typowe dla niej ataki protokołowe we wpisie Ochrona Minecraft przed DDoS i ochrona nullping. Samą instalację serwera Bedrock opisuje Instalacja serwera Minecraft Bedrock z Nukkit.

Jeśli atak trwa właśnie teraz: nie zmieniaj niczego w konfiguracji i nie restartuj serwera. Zabezpiecz najpierw pomiary (rozdział „Zbieraj pomiary, zanim gruchnie”), po ataku będą bezpowrotnie stracone.

Dlaczego serwery Minecraft Bedrock tak często są celem ataków DDoS

Bedrock Edition to wersja, która działa na konsolach, smartfonach, tabletach i Windowsie, i stanowi największą bazę graczy Minecrafta w ogóle. Gdzie stoi wiele serwerów, tam powstaje największa zachęta do ataków: konkurencyjne sieci, zbanowani gracze, wewnętrzne spory. Atak nie kosztuje przy tym zlecającego ani umiejętności, ani liczących się pieniędzy, a server booter sprzedawany jest w abonamencie.

Powód techniczny leży głębiej. Serwer Bedrock mówi po UDP, a nie po TCP, i odpowiada każdemu, kto zapyta, na długo zanim doszło do jakiegokolwiek logowania. Dokładnie te dwie cechy czynią z portu 19132 UDP wdzięczny cel. Czym zasadniczo jest atak DDoS, wyjaśnia wpis Czym jest atak DDoS?.

RakNet: protokół UDP, który odpowiada, zanim ktokolwiek się zalogował

RakNet to biblioteka sieciowa UDP, przez którą Minecraft Bedrock Edition prowadzi cały swój ruch gry. UDP nie zna nawiązywania połączenia, którego serwer mógłby wymagać, a adresy nadawcy da się przez to podrobić. RakNet buduje nad tym własną warstwę niezawodności: numery sekwencyjne, potwierdzenia (ACK) i potwierdzenia negatywne (NAK), którymi klient może upomnieć się o zgubione pakiety.

Nawiązanie połączenia składa się z siedmiu pakietów, czterech od klienta i trzech od serwera:

Client  -> Server   Open Connection Request 1
Server  -> Client   Open Connection Reply 1
Client  -> Server   Open Connection Request 2
Server  -> Client   Open Connection Reply 2
Client  -> Server   Connection Request
Server  -> Client   Connection Request Accepted
Client  -> Server   New Incoming Connection

Dopiero potem klient wysyła pakiet logowania ze swoimi poświadczeniami Xbox Live. To zdanie decydujące dla każdego, kto chce zabezpieczyć swój serwer Bedrock: serwer przetworzył siedem pakietów, zużył czas procesora i pamięć oraz odpowiedział kilka razy, zanim w ogóle dowiaduje się, kto puka. Każde działanie, które zaczepia się o logowanie, zadziała więc dopiero wtedy, gdy obciążenie już powstało.

Dochodzi do tego drugi, jeszcze wcześniejszy punkt wejścia. Żeby serwer pojawił się na liście serwerów gracza z nazwą, wersją i liczbą graczy, odpowiada on na Unconnected Ping (ID pakietu 0x01) pakietem Unconnected Pong (ID pakietu 0x1C). Ta wymiana odbywa się przed właściwym nawiązaniem połączenia, nie wymaga żadnego poświadczenia i przy Bedrock Dedicated Server nie da się jej wyłączyć bez usunięcia serwera z każdej listy serwerów.

Unconnected Ping jako wektor wzmocnienia: liczby

Atak wzmocnieniowy (amplification) to atak, w którym atakujący wysyła małe zapytania z podrobionym adresem nadawcy do obcych serwerów, żeby ich większe odpowiedzi wylądowały u ofiary. Serwer Bedrock nie jest przy tym atakowany, tylko używany. Przy Unconnected Ping rachunek wygląda tak:

Dwie rzeczy wynikają z tego bezpośrednio. Po pierwsze: długa nazwa serwera powiększa odpowiedź, a tym samym współczynnik wzmocnienia, który oddajesz do dyspozycji obcym atakującym. Krótka nazwa to nie kosmetyka, tylko środek ochronny. Po drugie: współczynnik 4 w konfiguracji domyślnej jest na tyle mały, że twój serwer pozostaje nieciekawy jako reflektor, ale na tyle duży, że zalew pingów obciąża twoje własne łącze wyjściowe czterokrotnością tego, co przychodzi.

Błąd wzmocnienia z 2024 roku pokazuje, jak źle może być, gdy nadużyta zostaje sama warstwa niezawodności. W używanej wtedy bibliotece RakNet pakiet Connection Request Accepted był oznaczony jako niezawodny. Atakujący mógł rozegrać nawiązanie połączenia z podrobionym adresem nadawcy aż do tego punktu, a potem wysłać jedno jedyne potwierdzenie negatywne z zakresem od 0 do 8191. Serwer wysyłał w odpowiedzi tysiące pakietów na podrobiony adres, a atakujący nie musiał robić już nic więcej. Naprawiono to, przestawiając ten pakiet na zawodny, dosyłając w Open Connection Reply 1 ciasteczko, które prawdziwy klient odbija z powrotem, oraz wprowadzając granice pakietów: 120 pakietów na adres źródłowy i takt 10 milisekund, 1 000 pakietów łącznie na takt.

Bedrock Edition czy Java Edition: co się różni w ochronie DDoS

Kto zabezpieczał już kiedyś serwer Java, przeniesie prawie wszystko błędnie. Obie edycje dzielą nazwę, ale nie protokół sieciowy:

Wiersz o SYN-cookies jest najważniejszy. Przy Java Edition kernel Linuksa odpiera zalew SYN, a proces Minecrafta niczego z tego nie zauważa. Przy Bedrock Edition tej pomocy nie ma: każdy pojedynczy pakiet UDP jest przepuszczany aż do procesu serwera i tam analizowany. Serwer Bedrock nie ma przeciw floodowi na porcie 19132 żadnej wbudowanej ochrony w systemie operacyjnym, bo UDP takiej nie zna.

Wiersz o braku wpisu SRV ma praktyczną konsekwencję, która wielu zaskakuje: portu przy Bedrock Edition nie da się schować za wpisem DNS. Gracze wpisują adres i port ręcznie. Kto przenosi port, musi podać nowy port każdemu graczowi.

Porty, o które naprawdę chodzi

Bedrock Dedicated Server wiąże się z dokładnie dwoma portami, i to na obu po UDP. W pliku server.properties:

server-port=19132
server-portv6=19133
enable-lan-visibility=true
online-mode=true
allow-list=false
max-players=10
player-idle-timeout=30
max-threads=8

To są ustawienia domyślne Microsoftu, do przeczytania w dokumentacji Bedrock Dedicated Server. Wokół tych dwóch portów leżą kolejne usługi, które działają zależnie od oprogramowania serwerowego:

Trzeci i czwarty wiersz to najczęstsze możliwe do uniknięcia błędy na serwerach Bedrock. Przy Nukkit i PocketMine-MP enable-query stoi fabrycznie na włączonym, a przy Nukkit przypadkowo włączony RCON ląduje na 19132 TCP, czyli na tym samym numerze portu co gra. Kto patrzy tylko na „19132 jest otwarty, w porządku”, tego nie zauważy.

Cecha oficjalnego Bedrock Dedicated Server należy tu równie dobrze: on nie zna dyrektywy server-ip. PocketMine-MP i Nukkit ją mają (server-ip, przy PocketMine dodatkowo server-ipv6), oficjalny serwer nie. Nasłuchuje więc zawsze na wszystkich adresach systemu, a firewall jest twoją jedyną możliwością, żeby to ograniczyć.

Co możesz zrobić sam, zanim wydasz pieniądze

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer Bedrock wytrzyma małe i średnie ataki o własnych siłach, niezależnie od tego, u kogo stoi.

1. Inwentaryzacja: co w ogóle nasłuchuje na 19132?

Zanim napiszesz choć jedną regułę, sprawdź, co twój serwer wystawia na zewnątrz. Nie zgaduj, sprawdź:

ss -lntup
ss -lnup sport = :19132

Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:19132 i [::]:19133 oznaczają „osiągalny z całego internetu”. Jeśli obok pojawia się wpis TCP na tym samym numerze portu, działa RCON. Spojrzenie oczami atakującego daje skan portów z zewnątrz, dla UDP z -sU:

nmap -Pn -sU -p 19132,19133 TWOJ.ADRES.IP.SERWERA
nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

2. Zostaw otwarty tylko 19132 UDP, całą resztę zamknij

Dla serwera Bedrock wystarczy jedno udostępnienie na zewnątrz, dwa z IPv6. W UFW wygląda to tak, dokładnie w tej kolejności, żebyś nie zamknął dostępu samemu sobie:

ufw allow 22/tcp comment 'SSH'
ufw allow 19132/udp comment 'Bedrock IPv4'
ufw allow 19133/udp comment 'Bedrock IPv6'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Jeśli nie masz graczy po IPv6, pomiń wiersz dla 19133 i ustaw przy PocketMine-MP dodatkowo enable-ipv6=false. Każdy port, którego nie udostępnisz, to port, którego nie musisz bronić. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

3. Wyłącz widoczność w sieci LAN, inaczej 19132 zostaje otwarty

To jest pułapka, w którą wpada prawie każdy, kto chce przenieść port. Dyrektywa enable-lan-visibility stoi fabrycznie na true i sprawia, że serwer odpowiada na zapytania wyszukujące w sieci lokalnej. Microsoft pisze o tym wyraźnie, że serwer wiąże się przez to dodatkowo z portami standardowymi 19132 i 19133, nawet jeśli server-port i server-portv6 mają inne wartości.

Kto więc przenosi port na 19140 i czuje się bezpiecznie, nadal nasłuchuje na 19132. Dla serwera w internecie do server.properties należy więc:

enable-lan-visibility=false

Potem sprawdź przez ss -lnup, czy 19132 naprawdę zniknął. Przy okazji to samo ustawienie rozwiązuje problem, że dwa serwery Bedrock na tym samym hoście odbierają sobie nawzajem port.

4. Wyłącz query i RCON

PocketMine-MP i Nukkit przynoszą ze sobą query GS4, czyli zapytanie o serwer po UDP według wzorca protokołu UT3, i odpowiadają na te zapytania na tym samym porcie 19132, na którym działa gra. Rozbudowana odpowiedź zawiera nazwę serwera, wersję, nazwę świata, stan whitelisty, adres i port, liczbę graczy, nazwy wszystkich połączonych graczy, a przy PocketMine-MP na życzenie pełną listę wtyczek. To wygodne dla stron ze statusem i botów Discord, ale zdradza atakującemu dokładnie, kiedy atak się opłaca, i kosztuje czas procesora przy każdym zapytaniu.

enable-query=off
enable-rcon=off

Przy PocketMine-MP wartości brzmią false zamiast off, a listę wtyczek wyłączasz w pocketmine.yml przez settings.query-plugins: false. Uporządkowanie, które czyta się rzadko: query GS4 z PocketMine-MP sprawdza token zasolony adresem nadawcy. Dużej odpowiedzi nie da się więc odbić na podrobiony adres. Zapytanie kosztuje mimo to czas procesora, a opublikowane dane pomagają atakującemu w doborze celu. Oficjalny Bedrock Dedicated Server nie zna ani query, ani RCON, tam ten punkt odpada.

Jeśli naprawdę potrzebujesz RCON, ustaw przy Nukkit koniecznie rcon.port na własną wartość i udostępnij go tylko dla własnego adresu. Powrót do server-port oznacza inaczej, że zdalne sterowanie twoim serwerem nasłuchuje na 19132 TCP, czyli na tej samej liczbie, którą i tak wszędzie wpisałeś jako „otwartą”.

5. Wymuś uwierzytelnianie Xbox Live

Uwierzytelnianie Xbox Live to sprawdzenie, czy dołączający gracz ma prawdziwe konto podpisane przez Microsoft. We wszystkich trzech programach serwerowych stoi ono fabrycznie na włączonym i tam też musi zostać.

Przy Bedrock Dedicated Server dyrektywa nazywa się online-mode, przy PocketMine-MP i Nukkit nazywa się xbox-auth. W obu przypadkach true jest stanem fabrycznym i wartością właściwą:

online-mode=true
xbox-auth=true

Microsoft formułuje przy tym ważne zastrzeżenie: klienci, którzy łączą się z serwerem poza siecią lokalną, i tak zawsze potrzebują uwierzytelnienia Xbox Live, niezależnie od tego ustawienia. Poświadczenie przenoszone jest jako podpisany łańcuch tokenów w pakiecie logowania, razem z identyfikatorem Xbox (XUID) oraz nazwą wyświetlaną.

A teraz część, która pomaga przeciw nieporozumieniom: uwierzytelnianie Xbox Live chroni twoją logikę gry, a nie twoje łącze. Odbywa się w pakiecie logowania, czyli po pełnym nawiązaniu połączenia RakNet. Atakujący, który zalewa twój serwer, wcale nie chce dołączyć. Jego pakiety zostaną odrzucone, ale i tak już dotarły, i o to właśnie chodzi.

6. Allowlist i górny limit graczy, oraz czego one nie potrafią

Allowlist (dawniej whitelist) to lista graczy, którzy mogą dołączyć. Przy Bedrock Dedicated Server włączasz ją przez allow-list=true, a wpisy stoją w allowlist.json z nazwą, XUID i polem ignoresPlayerLimit. Przy Nukkit i PocketMine-MP dyrektywa nadal nazywa się white-list.

allow-list=true
max-players=60
player-idle-timeout=15

Krótki czas bezczynności przez player-idle-timeout działa przeciw wyczerpaniu slotów: gracze, którzy tylko zajmują miejsce, wylatują po podanej liczbie minut. Wartość 0 oznacza, że nikt nigdy nie zostanie rozłączony z powodu bezczynności, i dokładnie to wykorzystuje atakujący, który blokuje twoje miejsca prawdziwymi kontami.

Także tutaj obowiązuje granica z poprzedniego rozdziału, i jest to punkt przeoczany najczęściej ze wszystkich: allowlist jest sprawdzana dopiero wtedy, gdy pakiet logowania zostanie przetworzony. Zapobiega dołączeniom, a nie pakietom.

7. Ogranicz liczbę pakietów na adres źródłowy

Przeciw małym atakom i niechlujnym botom pomaga górny limit na adres źródłowy. Przy UDP pracuje się z hashlimit, a nie z connlimit, bo UDP nie zna połączeń:

iptables -I INPUT -p udp --dport 19132 -m hashlimit --hashlimit-name bedrock_udp --hashlimit-mode srcip --hashlimit-above 400/sec --hashlimit-burst 600 -j DROP

Reguła odrzuca pakiety UDP, gdy ten sam adres źródłowy wysyła trwale więcej niż 400 pakietów na sekundę. Wartość jest wartością startową, a nie prawdą objawioną: pełny serwer z 60 graczami i dużym zasięgiem widzenia generuje wyraźnie więcej pakietów niż pusty, a kto ustawi zbyt ciasno, wyrzuci własnych graczy. Najpierw mierz przez tydzień w normalnej pracy.

Wyraźnie ostrzej wolno ci ustawić przy Unconnected Ping, bo prawdziwy klient pyta o stan serwera tylko wtedy, gdy lista serwerów jest otwarta, i wtedy w takcie sekundowym. Przez nftables da się trafić dokładnie w ten jeden pakiet, bo ID pakietu to pierwszy bajt za nagłówkiem UDP:

nft add table inet bedrock
nft add chain inet bedrock prerouting '{ type filter hook prerouting priority -150 ; policy accept ; }'
nft add rule inet bedrock prerouting udp dport 19132 @th,64,8 0x01 limit rate over 500/second drop

Wyrażenie @th,64,8 czyta osiem bitów od 64. bitu nagłówka transportowego, czyli pierwszy bajt ładunku UDP. Wartość 0x01 to ID pakietu Unconnected Ping. Tego samego miejsca możesz użyć do obserwacji, zanim cokolwiek odrzucisz:

tcpdump -ni eth0 'udp dst port 19132 and udp[8] = 0x01' -c 200 -q
tcpdump -ni eth0 'udp src port 19132 and udp[8] = 0x1c' -c 200 -q

Pierwszy wiersz liczy przychodzące zapytania o stan, drugi twoje własne odpowiedzi. Jeśli oba idą w takcie sekundowym w tysiące, podczas gdy prawie nikt nie gra, widzisz zalew pingów, a nie swoich graczy.

Dwie uwagi o trwałości. Same reguły iptables znikają po restarcie, na Debianie i Ubuntu zapisuje się je tak:

apt-get install -y iptables-persistent
netfilter-persistent save

A przy UFW takie reguły należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload.

8. Odciąż śledzenie połączeń w kernelu

Wąskie gardło, które przy grach po UDP uderza dużo wcześniej niż przy TCP: kernel zakłada dla każdej pary pakietów UDP wpis w śledzeniu połączeń. Przy zalewie z podrobionymi adresami nadawcy każdy pakiet to nowy adres źródłowy, a więc nowy wpis. Gdy tablica się zapełni, serwer odrzuca także legalne pakiety, a w logu stoi „nf_conntrack: table full, dropping packet”.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Jeśli licznik stoi trwale blisko górnej granicy, możesz wyjąć ruch gry ze śledzenia. To skuteczne, ale nie bez konsekwencji, dlatego w obu kierunkach i z następującym po tym testem połączenia:

iptables -t raw -I PREROUTING -p udp --dport 19132 -j NOTRACK
iptables -t raw -I OUTPUT -p udp --sport 19132 -j NOTRACK

Potem reguły oparte na stanie nie działają już dla tego ruchu. Twoje udostępnienie dla 19132 UDP musi więc być prawdziwym udostępnieniem portu i nie może polegać na stanie ESTABLISHED. Po ustawieniu sprawdź przez conntrack -L | grep 19132, że nie powstają już wpisy, i połącz się raz z grą, zanim zapiszesz reguły na stałe.

9. Prowadź Geyser i Floodgate porządnie

Geyser to most, który pozwala klientom Bedrock grać na serwerze Java Edition: przyjmuje na 19132 UDP połączenia Bedrock, tłumaczy protokół i rozmawia po drugiej stronie z serwerem Java na 25565 TCP. Floodgate to uzupełnienie, które pozwala tym graczom Bedrock dołączyć bez konta Java. Dla ochrony DDoS oznacza to trzy rzeczy.

Po pierwsze: trzymaj Geyser aktualny. Dokładnie ten most był dwa razy powodem udokumentowanych ataków. W marcu 2024 szeroko wykorzystano opisany wyżej błąd wzmocnienia w bibliotece RakNet, naprawiony od builda 478. W lipcu 2025 nastąpił drugi przypadek: wielokrotnie wysyłany pakiet potwierdzający paczki zasobów tworzył kilka sesji na gracza, a rozłączeni klienci mogli dalej wysyłać pakiety, bo kanał sieciowy nie został zamknięty. Naprawione od builda 897. Oba przypadki projekt opublikował sam wraz z osią czasu.

Po drugie: serwer Java nie należy do otwartej sieci. W konfiguracji Geysera remote.address wskazuje na auto względnie 127.0.0.1, a remote.port na 25565. Zwiąż serwer Java odpowiednio lokalnie i nie udostępniaj 25565 TCP na zewnątrz. Inaczej masz dwie powierzchnie ataku zamiast jednej, a druga to ta, dla której nigdy nie wymyśliłeś żadnych reguł.

Po trzecie: plik key.pem jest tajemnicą. To klucz, którym Floodgate pomija uwierzytelnianie Java dla kont Bedrock. Kto położy go w publicznym repozytorium, skopiuje do zgłoszenia wsparcia albo pokaże na zrzucie ekranu, oddał logowanie swojego serwera. Projekt wyraźnie przed tym ostrzega.

10. Zbieraj pomiary, zanim gruchnie

Najważniejszy krok to ten, którego prawie nikt nie robi wcześniej: przygotuj bazę porównawczą, dopóki wszystko działa normalnie. Bez wartości normalnej po incydencie nie powiesz, czy 40 000 pakietów na sekundę to dużo, czy po prostu sobotni wieczór. Po apt-get install -y vnstat sysstat conntrack pomiar chodzi na stałe w tle.

sar -n DEV 1 10
ip -s link show eth0
ss -lunp sport = :19132
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|UdpRcvbufErrors'
dmesg -T | tail -50

Trzy z tych wartości są przy serwerze Bedrock szczególnie wymowne. Trwale różne od zera Recv-Q na gnieździe UDP portu 19132 oznacza, że proces serwera nie odbiera już przychodzących pakietów dostatecznie szybko. UdpRcvbufErrors liczy dokładnie te pakiety, które zostały przez to odrzucone, i jest najtwardszym dowodem na to, że wąskim gardłem nie jest łącze, tylko proces. UdpNoPorts rośnie, gdy ktoś ostrzeliwuje porty, na których w ogóle nic nie nasłuchuje, a to typowy obraz przy szeroko zakrojonym skanie portów przed właściwym atakiem.

Przy tcpdump obowiązuje zasada: zawsze ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. Jak odczytać te wartości, opisuje wpis Jak rozpoznać atak DDoS.

Gdzie te działania się kończą: przepustowość i liczba pakietów

Teraz część, której nie rozwiąże żaden plik konfiguracyjny. Wszystkie dotychczasowe działania dzieją się na twoim serwerze, czyli na końcu łącza. Reguła firewalla decyduje o pakiecie, który już przeszedł przez kabel. Możesz go odrzucić, ale nie możesz sprawić, żeby nie został wysłany.

Policz to razem ze mną. Twoje łącze jest pełne, gdy tylko ktoś wyśle więcej niż 125 megabajtów na sekundę. Atak o wolumenie od 5 do 50 Gbit/s leży przy pięcio- do pięćdziesięciokrotności tego. To, czy twoja reguła hashlimit za tym łączem jest dobra, nie ma już wtedy znaczenia, bo pakiety twoich graczy nie przechodzą już wcześniej.

Druga wielkość to liczba pakietów i przy serwerze Bedrock uderza ona prawie zawsze pierwsza. Cały ruch gry składa się z wielu małych pakietów UDP, a właśnie w tej dyscyplinie atakujący porusza się najtaniej. Atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, może mimo to położyć twój serwer, bo cały czas procesora idzie na analizę i odrzucanie. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszyscy wypadli”. W grze objawia się to samo jako lag spikes, efekty gumki i zrywane połączenia w środku budowania.

Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem.

Co KernelHost przeciwstawia atakom DDoS na serwery Bedrock

Stała ochrona wliczona w każdy serwer

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i stale aktywna, bez konieczności włączania, zamawiania czy konfigurowania czegokolwiek:

• Warstwa 1: 17 Tbps pojemności mitygacji w globalnej sieci scrubbing. Ataki wolumetryczne są oczyszczane blisko źródła, zanim dotrą do centrum danych.
• Warstwa 2: filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps we Frankfurcie nad Menem. Bezpośrednio przed serwerem rozpoznawane i odrzucane są wzorce specyficzne dla protokołów, pakiet po pakiecie. Należą do nich także wzorce UDP na 19132, które nie wykazują zachowania RakNet.

Decydujące są dwie cechy. Ochrona działa nieprzerwanie i nie musi dopiero reagować na atak, nie ma więc kilku minut na starcie, w których serwer znika. I nie stosuje się null-routingu: twój adres IP zostaje w sieci, odrzucane są wyłącznie szkodliwe pakiety. Kto zdejmuje adres IP z sieci, osiąga dla ciebie ten sam efekt co atakujący. Lokalizacja to Frankfurt nad Menem. Które gry i protokoły są objęte ochroną, wylicza wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

Advanced DDoS Protection dla projektów pod stałym ostrzałem

Niektóre projekty są atakowane nie okazjonalnie, tylko celowo i przez wiele tygodni. Dla nich jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid i bez minimalnego okresu umowy. Różnica nie polega na większej pojemności, tylko na kontroli:

• Dedykowany chroniony adres IP z rdzenia sieci we Frankfurcie, na który twój serwer zostaje przełączony w naszej sieci. Po twojej stronie nie trzeba niczego przebudowywać.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta: sam ustawiasz, co jest dozwolone na 19132 UDP, co na 19133 UDP, a co na porcie odbiegającym od standardu, jeśli przeniosłeś swój serwer.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, zamiast czekać na okno serwisowe.
• Profil ochrony dopasowany do konkretnej gry. Dla Minecrafta istnieją gotowe profile, tak samo dla zmodyfikowanych i własnych aplikacji na dowolnych portach TCP albo UDP, a więc także dla Nukkit, PocketMine-MP albo instancji Geysera na samodzielnie wybranym porcie.

Porównanie obu wariantów

Dla większości projektów Bedrock wystarczy wliczona stała ochrona razem z czystą konfiguracją serwera. Advanced DDoS Protection jest odpowiedzią na sytuację, w której ktoś bierze to do siebie osobiście. Kto prowadzi obecnie swój serwer gdzie indziej, rozwiąże problem najpewniej przeprowadzką: filtrowanie działa w sieci przed serwerem, a ta sieć musi należeć do nas.

Typowe błędy i ich rozwiązania

„Zmieniłem port na 19140, a 19132 i tak jest otwarty”: to enable-lan-visibility=true. Bedrock Dedicated Server wiąże się wtedy dodatkowo z 19132 i 19133, niezależnie od tego, co stoi w server-port. Ustawić na false, zrestartować serwer, sprawdzić przez ss -lnup.

„Edytowałem allowlist.json i sam nie mogę już wejść”: częste są dwie przyczyny. W katalogu leży jeszcze stary plik whitelist.json, który serwer czyta zamiast nowego, albo brakuje wpisu XUID względnie jest on błędny. Sama nazwa przy aktywnym uwierzytelnianiu Xbox Live nie wystarcza niezawodnie.

„Mój hoster zablokował mój serwer, chociaż to ja byłem atakowany”: sprawdź, czy twój serwer sam wysyłał pakiety. Dokładnie to działo się przy błędzie wzmocnienia RakNet z 2024 roku: dotknięte serwery wysyłały tysiące pakietów na obce adresy, a w zgłoszeniach abuse stał port 19132 jako źródło. Przez tcpdump -ni eth0 'udp src port 19132' -c 200 -q zobaczysz, dokąd twój serwer odpowiada. Aktualny build usuwa przyczynę.

„Moje reguły iptables nie działają”: częste są trzy przyczyny. Reguły stoją za łańcuchami UFW i nigdy nie zostają osiągnięte, zniknęły po ostatnim restarcie (wtedy pomogą netfilter-persistent save albo wpis w /etc/ufw/before.rules) albo atak jest wolumetryczny, a reguła pracuje poprawnie na łączu, które jest już pełne. Sprawdź przez iptables -L INPUT -n -v, czy liczniki trafień rosną. Jeśli stoją na zerze, reguła nie jest osiągana.

„Serwer jest na liście, ale nikt nie wchodzi”: jeśli wpis pokazuje nazwę i liczbę graczy, to Unconnected Pong działa, czyli port jest zasadniczo osiągalny. Jeśli mimo to dołączenie się nie udaje, wisi to zwykle na logowaniu Xbox Live albo na allowliście. Jeśli odwrotnie nie wchodzą tylko gracze po IPv6, brakuje udostępnienia dla 19133 UDP.

„Serwer działa, ale wszyscy mają lag spikes”: to częściej wtyczka niż atak. Sprawdź najpierw, czy Recv-Q na gnieździe UDP rośnie i czy rośnie UdpRcvbufErrors. Jeśli oba są spokojne, a sar -n DEV 1 10 nie pokazuje nic nietypowego, to nie był atak DDoS, tylko sam proces serwera. Przy Bedrock Dedicated Server pomogą wtedy wachtarze skryptów, których progi stoją w server.properties pod script-watchdog-hang-threshold i script-watchdog-slow-threshold.

„Mój dotychczasowy dostawca zablokował mój adres IP”: to null-routing. Dostawca chroni w ten sposób własną sieć, a dla ciebie wynik jest identyczny z udanym atakiem, zwykle jeszcze przez wiele godzin po nim. W razie wątpliwości zapytaj, czy ruch jest filtrowany, czy null-routowany. Ta odpowiedź decyduje o twojej dostępności bardziej niż jakakolwiek specyfikacja sprzętu.

„W tcpdump nie widzę nic nietypowego”: jeśli ruch jest filtrowany już w sieci przed serwerem, to zgodnie z oczekiwaniem nic na serwer nie dociera. To normalny stan przy działającym filtrowaniu. Odwrotnie też jest prawdą: gdy łącze jest wysycone, może cię nie dosięgnąć nawet sesja SSH, którą chciałeś użyć do pomiaru. Skorzystaj wtedy z konsoli VNC w panelu klienta, która działa niezależnie od sieci systemu gościa.

Krótkie podsumowanie

• Serwer Minecraft Bedrock potrzebuje na zewnątrz dokładnie jednego otwartego portu: 19132 UDP, do tego 19133 UDP tylko dla graczy po IPv6. Query, RCON, debugger skryptów na 19144 TCP oraz serwer Java za Geyserem na 25565 TCP do otwartej sieci nie należą.
• Kto przenosi port, musi ustawić enable-lan-visibility=false, bo inaczej Bedrock Dedicated Server wiąże się dodatkowo dalej z 19132 i 19133.
• Uwierzytelnianie Xbox Live i allowlist działają dopiero w pakiecie logowania, czyli po pełnym nawiązaniu połączenia RakNet. Chronią twoją logikę gry i twoje miejsca, a nie twoje łącze.
• Unconnected Ping jest pytany 33 bajtami, a odpowiadany około 131 bajtami, czyli ze współczynnikiem wzmocnienia około czterech. Krótka nazwa serwera trzyma ten współczynnik nisko.
• Przy UDP pomaga hashlimit zamiast connlimit, a śledzenie połączeń w kernelu zapełnia się przy podrobionych adresach nadawcy jako pierwsze. Jedno i drugie powinieneś zmierzyć przed pierwszym atakiem.
• Od mniej więcej 1 Gbit/s twoje łącze jest pełne, a przy pakietach po 64 bajty mieści się w nim około 1,49 miliona pakietów na sekundę. Powyżej decyduje wyłącznie filtrowanie w sieci przed serwerem.
• W KernelHoście dwuwarstwowa stała ochrona jest zawarta w każdym pakiecie serwerowym, działa od momentu udostępnienia i obywa się bez null-routingu. Advanced DDoS Protection uzupełnia ją o dedykowany chroniony adres IP oraz samodzielnie zarządzane reguły na port.

Jeśli twój projekt działa już w KernelHoście, filtrowanie jest aktywne i nie musisz nic robić. Gdybyś mimo to zauważył coś nietypowego, załóż zgłoszenie wsparcia, żeby reguły filtrowania dla twojego adresu IP zostały skorygowane. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883.