Ochrona serwera Palworld przed atakami DDoS

Serwer Palworld, który wieczorem w środku rozgrywki wyrzuca wszystkich graczy naraz, znika na kilka minut i potem sam wraca do życia, rzadko ma problem ze sprzętem. Z reguły trwa atak. Ten wpis pokazuje, jak chronić serwer Palworld przed atakami DDoS: najpierw to, co możesz skonfigurować sam i bez dodatkowych kosztów, potem miejsce, w którym te działania kończą się technicznie, a na koniec to, co musi wydarzyć się w sieci przed serwerem, żeby serwer pozostał osiągalny.

Wszystkie informacje dotyczą oficjalnego serwera dedykowanego firmy Pocketpair (Steam-App-ID 2394010) 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. Jeśli atak właśnie trwa, obowiązuje kolejność: najpierw mierz, potem zmieniaj. Twardy restart pod obciążeniem przekreśla wszystko, co wydarzyło się w świecie od ostatniego automatycznego punktu zapisu, a pomiary z przebiegu incydentu znikają razem z nim.

Dlaczego serwery Palworld są celowo unieruchamiane atakami DDoS

Serwer Palworld to mała, stała publiczność pod stałym adresem. Serwer dedykowany jest ograniczony do 32 graczy, sterowanych przez ServerPlayerMaxNum z dopuszczalnym zakresem od 1 do 32. Kto zamiast tego hostuje przez menu gry, dochodzi do czterech graczy i tylko na tak długo, jak długo sam gospodarz jest online. Z tych 32 miejsc wynika cała reszta: grupa gra o stałych wieczornych porach, zna się nawzajem, a awaria o 20:00 nie trafia w ułamek graczy, tylko we wszystkich.

Adres serwera nie jest przy tym żadną tajemnicą. Palworld nie zna pośrednictwa przez usługę producenta: gracze wpisują adres IP i port w polu połączenia bezpośredniego, a kto chce dodatkowo umieścić serwer na społecznościowej liście serwerów, uruchamia go z parametrem -publiclobby i pozwala odpowiadać portowi zapytań. Każdy, kto choć raz był połączony, zna więc cel. Usługa typu booter, która ostrzeliwuje ten adres za kilka euro miesięcznie, nie wymaga od zlecającego ani umiejętności, ani nakładu pracy.

Technicznie dochodzi do tego fakt, że cały ruch gry idzie przez UDP. UDP nie zna nawiązywania połączenia, którego można by wymagać, a adres nadawcy pakietu UDP da się podrobić. Atakujący nie musi więc ani wchodzić na serwer, ani poprawnie się z nim komunikować, żeby wygenerować obciążenie. Co przy takim ataku dzieje się technicznie, wyjaśnia wpis Czym jest atak DDoS?.

Porty, o które przy serwerze Palworld naprawdę chodzi

Serwer Palworld potrzebuje dokładnie jednego otwartego portu: 8211 UDP. Cała reszta jest opcjonalna, a zależnie od zadania wręcz szkodliwa, gdy stoi w internecie. Wynika z tego użyteczne rozróżnienie: atak DDoS na port 8211 zawsze trafia w sam ruch gry, a atak na port 27015 UDP tylko we wpis na liście serwerów.

Wszystkie przełączniki do tego stoją w jednym jedynym pliku: Pal/Saved/Config/LinuxServer/PalWorldSettings.ini, pod Windowsem odpowiednio Pal\Saved\Config\WindowsServer\PalWorldSettings.ini. Zaczyna się on wierszem sekcji [/Script/Pal.PalGameWorldSettings], po którym następuje jeden jedyny wiersz OptionSettings=(...) zawierający wszystkie ustawienia jako listę. Złamanie wiersza wewnątrz nawiasu unieważnia całą konfigurację, a serwer bez słowa komentarza wraca do wartości domyślnych. Wzorca DefaultPalWorldSettings.ini w katalogu serwera nie edytujesz, bo przy każdej aktualizacji zostaje nadpisany.

Serwer Palworld w liczbach

Poniższe wartości są podstawą każdej decyzji o regułach filtrowania i wartościach granicznych.

Dlaczego port zapytań 27015 jest najwrażliwszym punktem

Port zapytań odpowiada na pytania o status w formacie Steam A2S, czyli na to samo zapytanie, które obsługują też serwery Counter-Strike i ARK. Zapytanie A2S_INFO to bezpołączeniowy pakiet UDP o wielkości kilkudziesięciu bajtów, a odpowiedź z nazwą serwera, światem, liczbą graczy i stanem rozgrywki jest jego wielokrotnością. Ponieważ w UDP adres nadawcy da się podrobić, atakujący może odpytywać cudze porty zapytań i kierować większe odpowiedzi na swój właściwy cel. Twój serwer nie jest w takim przypadku ofiarą, tylko wzmacniaczem, a rachunek płaci jego łącze.

Valve dołożyło dlatego do A2S_INFO 8 grudnia 2020 poprzedzające wyzwanie: serwer odpowiada najpierw pakietem S2C_CHALLENGE, pytający musi odesłać token i dowodzi tym samym, że nie podrabia swojego adresu nadawcy. To łagodzi wzmocnienie, ale go nie kończy, a przeciw zwykłej powodzi jednakowych zapytań z prawdziwych adresów nie działa w ogóle.

Dla Palworlda wynika z tego ważna przewaga nad silnikiem Source: ruch gry i zapytania o serwer leżą na osobnych portach. W Counter-Strike 2 oba dzielą port 27015, więc zgrubny limit wyrzuca tam własnych graczy razem z atakiem. W Palworldzie możesz ostro ograniczyć 27015 UDP albo zamknąć go całkiem, nie dotykając ani jednego trwającego połączenia na 8211 UDP. Kto nie potrzebuje wpisu na liście, wykreśla -publiclobby oraz port zapytań bez zastępstwa i zdejmuje tym samym z sieci całą powierzchnię ataku.

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

Poniższe kroki nie zatrzymają ataku wolumetrycznego, tego nie potrafi żadne oprogramowanie na serwerze. Sprzątają za to wszystko, co leży poniżej: skany portów, powodzie zapytań, próby przejęcia przez porty administracyjne oraz zajęcie wszystkich 32 miejsc przez obcych. To większość tego, co na co dzień przeszkadza serwerowi Palworld, a kosztuje pół godziny.

1. Inwentaryzacja: co nasłuchuje na serwerze?

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

ss -lntup

Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:8211 oznacza „osiągalny z całego internetu”, 127.0.0.1:8212 oznacza „tylko lokalnie” i nie potrzebuje żadnej reguły firewalla. Obok procesu gry pojawiają się na rozbudowanym serwerze często jeszcze panel zarządzania, serwer WWW do podglądu mapy oraz baza danych. Spojrzenie oczami atakującego daje skan portów z zewnątrz:

nmap -Pn -sU -p 8211,27015 TWOJ.ADRES.IP.SERWERA
nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

2. Otwieraj tylko to, czego Palworld naprawdę potrzebuje

Wystarczą dwie reguły zezwalające, a druga z nich jest opcjonalna. 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 8211/udp comment 'Palworld ruch gry'
ufw allow 27015/udp comment 'Palworld zapytania Steam'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Trzeci wiersz pomijasz, jeśli twój serwer nie ma stać na społecznościowej liście serwerów. Twoi gracze łączą się wtedy nadal przez adres IP i port 8211, serwer znika jedynie z publicznej listy. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

3. Zdejmij RCON na 25575 i REST-API na 8212 z internetu

Oba porty to dostępy administracyjne z pełną kontrolą nad serwerem i oba są fabrycznie wyłączone: RCONEnabled=False oraz RESTAPIEnabled=False. Kto je włącza, powinien wiedzieć, co przez to publikuje.

REST-API na 8212 TCP uwierzytelnia przez HTTP Basic Auth ze stałą nazwą użytkownika admin i wartością z AdminPassword, a do tego przez nieszyfrowany HTTP. Hasło administratora idzie tym samym przy każdym pojedynczym zapytaniu przez łącze w odwracalnej postaci. RCON na 25575 TCP to równie nieszyfrowany protokół tekstowy, a Pocketpair oznaczył go jako przestarzały na rzecz REST-API. Dla nowych instalacji właściwym wyborem jest REST-API, a dla obu obowiązuje ta sama zasada: nie do otwartej sieci.

RESTAPIEnabled=True
RESTAPIPort=8212
AdminPassword="długa losowa wartość"

Osiągalny interfejs robisz sobie przez przekierowanie portu po SSH, a potem pracujesz lokalnie z 127.0.0.1:8212:

ssh -N -L 8212:127.0.0.1:8212 root@TWOJ.ADRES.IP.SERWERA

Nigdy nie zostawiaj AdminPassword pustego, bo puste jest ustawieniem fabrycznym. Wystarczy wartość z openssl rand -base64 32. To samo dotyczy ServerPassword, o czym zaraz więcej.

4. Ogranicz port zapytań 27015, nie tracąc wpisu na liście

Bezpołączeniowe pakiety Steam zaczynają się od czterech ustawionych bajtów (0xffffffff), a zwykły ruch gry takiego nagłówka nie ma. Na tym da się oprzeć limit na adres źródłowy, który hamuje zapytania i zachowuje wpis na liście. W nftables, ładowane przez nft -f:

table inet palworld {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 27015 @th,64,32 0xffffffff \
            meter a2sflood { ip saddr limit rate over 10/second burst 20 packets } drop
    }
}

Priorytet -10 sprawia, że reguła zadziała przed łańcuchem filtrującym UFW, a @th,64,32 odczytuje pierwsze cztery bajty za nagłówkiem UDP. W klasycznym iptables to samo rozdzielenie osiąga dopasowanie do sygnatury A2S_INFO:

iptables -A INPUT -p udp --dport 27015 \
  -m string --algo bm --hex-string "|ffffffff54536f7572636520456e67696e6520517565727900|" \
  -m hashlimit --hashlimit-name a2sflood --hashlimit-mode srcip \
  --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP

Dziesięć zapytań na sekundę i adres to miara hojna: usługa listująca pyta zwykle co kilka minut, a nie kilka razy na sekundę. Ważne jest tylko, żeby ta reguła stała na 27015, a nie na 8211, bo inaczej trafisz własnych graczy.

5. Ogranicz liczbę pakietów na 8211 UDP

Na samym porcie gry przeciw małym powodziom z niewielu źródeł pomaga górny limit na adres źródłowy. W Palworldzie ta granica jest stosunkowo bezpieczna do ustawienia, bo jednocześnie połączonych jest najwyżej 32 graczy, a każdy z nich zajmuje dokładnie jeden adres źródłowy:

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

Ta liczba to wartość startowa, a nie prawda objawiona. Pełny serwer z 32 graczami i wieloma bazami generuje wyraźnie więcej pakietów niż rozgrywka we czwórkę, a kto ustawi limit zbyt ciasno, wyrzuci własnych graczy. Najpierw mierz przez tydzień w normalnej pracy, a potem ustaw granicę na dwukrotność zmierzonej wartości szczytowej.

Same reguły iptables znikają po restarcie. Na Debianie i Ubuntu zabezpieczasz je tak:

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

Przy UFW takie reguły należą dodatkowo do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload. Czy reguła jest w ogóle osiągana, pokazuje iptables -L INPUT -n -v: jeśli liczniki trafień stoją na zerze, reguła nie działa.

6. Hasło serwera, lista banów i 32 miejsca przeciw wyczerpaniu slotów

Wyczerpanie slotów to najtańszy atak na serwer Palworld i nie potrzebuje żadnej przepustowości. Serwer dedykowany ma najwyżej 32 miejsca, więc wystarczą 32 jednoczesne połączenia, żeby zamknąć drzwi całej społeczności. Atak wolumetryczny kosztuje zlecającego pieniądze, 32 sesje nie kosztują go nic. To czyni tę drogę atrakcyjniejszą dla małych serwerów niż jakakolwiek powódź pakietów.

Palworld nie ma wbudowanej whitelisty. Narzędzia moderacyjne to kick, ban i hasło serwera, i właśnie hasło serwera jest przeciw wyczerpaniu slotów najskuteczniejszym pojedynczym środkiem:

ServerPassword="wartość, którą zna tylko twoja grupa"
ServerPlayerMaxNum=32
bShowPlayerList=True
BanListURL="https://api.palworldgame.com/api/banlist.txt"

ServerPassword jest fabrycznie puste, więc każdy z adresem IP i portem wchodzi do środka. BanListURL wskazuje standardowo na listę utrzymywaną przez Pocketpair i da się ją przestawić na własny plik tekstowy, jeśli chcesz prowadzić blokady projektu. ServerPlayerMaxNum nie ustawiaj powyżej 32: wyższe wartości nie są wspierane i zemszczą się najpóźniej przy następnej aktualizacji. I jedno musi być jasne: hasło serwera chroni twoje miejsca, a nie twoje łącze. Atakujący, który zalewa twój serwer, wcale nie chce dołączyć.

7. Odciąż śledzenie połączeń i powiększ bufory

Ten punkt tłumaczy awarie, które wyglądają jak atak wolumetryczny, choć nim nie są. Kernel zakłada dla ruchu UDP wpisy w śledzeniu połączeń (conntrack), a przy podrobionych adresach nadawcy każdy adres oznacza nowy wpis. Gdy tablica się zapełni, kernel odrzuca pakiety bez różnicy, atak i twoi gracze wylatują razem, a w logu stoi „nf_conntrack: table full”. Stan i górny limit pokazuje:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max

Najskuteczniejszy krok to w ogóle nie pozwolić na śledzenie ruchu gry, bo Palworld zarządza swoimi sesjami sam:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport { 8211, 27015 } notrack
    }
    chain output {
        type filter hook output priority raw; policy accept;
        udp sport { 8211, 27015 } notrack
    }
}

W iptables odpowiednik brzmi iptables -t raw -A PREROUTING -p udp --dport 8211 -j NOTRACK oraz ten sam wiersz dla OUTPUT z --sport. Porty potrzebują potem wyraźnego zezwolenia, bo bez śledzenia nie zadziała żadna reguła sprawdzająca istniejący stan. Jeśli pakiety przychodzą szybciej, niż proces serwera zdąży je odebrać, przepełnia się dodatkowo bufor odbiorczy. Dla graczy wygląda to jak utrata pakietów, mimo że łącze jest wolne. Wpis w /etc/sysctl.d/, uaktywniany przez sysctl -p:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Czy te wartości są potrzebne, zdradzi ci sam kernel: jeśli UdpRcvbufErrors w nstat -az rośnie, to znaczy, że działają. Jeśli licznik zostaje na zerze, zmiana niczego nie da.

8. Zbieraj pomiary, zanim zrobi się poważnie

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 pomiar chodzi na stałe w tle. W trakcie incydentu wystarczą cztery polecenia:

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 -c 200 "udp port 8211 or udp port 27015"

Przy tcpdump obowiązuje zasada: zawsze ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. Palworld dostarcza w dodatku wielkość pomiarową, której nie ma żadne inne narzędzie. Jeśli REST-API jest aktywne, punkt końcowy z metrykami zwraca między innymi liczbę klatek serwera, aktualną liczbę graczy i czas pracy:

curl -s -u admin:TWOJE_HASLO_ADMINA http://127.0.0.1:8212/v1/api/metrics

Ta jedna liczba czysto rozdziela dwie najczęstsze przyczyny. Jeśli liczba klatek serwera spada, a liczba pakietów pozostaje niepodejrzana, to nie jest atak, tylko obciążenie albo znany przyrost zużycia pamięci przez proces serwera. Jeśli liczba klatek jest stabilna, a pakiety przychodzące rosną daleko powyżej wartości normalnej, to jest atak. Jak oceniać wartości sieciowe w szczegółach, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

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ą. Typowy serwer gier wisi na 1 Gbit/s, co odpowiada 125 megabajtom na sekundę, a łącze jest pełne, gdy tylko ktoś wyśle więcej. Ataki na projekty serwerów gier mieszczą się zwykle między 5 a 50 Gbit/s, czyli od pięciu do pięćdziesięciu razy powyżej twojego łącza. To, czy twoja reguła iptables 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 na sekundę i uderza ona często wcześniej niż przepustowość. Przy małych pakietach po 64 bajty w łącze 1 Gbit/s mieści się około 1,49 miliona pakietów na sekundę. Zwykły kernel serwera przetworzy z tego, zależnie od procesora i karty sieciowej, kilkaset tysięcy, zanim zacznie odrzucać. Atak, który nie zapełnia twojego łącza nawet w jednej trzeciej, może więc mimo wszystko położyć twój serwer, bo cały czas procesora idzie na odrzucanie. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszystko padło”, a w Palworldzie objawia się to najpierw skokami lagów i dopiero potem zerwaniem połączenia.

Przy serwerze Palworld dochodzi do tego niekorzystna proporcja. W pełni obsadzony serwer z 32 graczami obciąża tylko ułamek łącza 1 Gbit/s. Atak nie musi więc być duży, żeby osiągnąć wielokrotność normalnej pracy, i właśnie dlatego wystarczą tu ataki, które na dużej platformie w ogóle nie zwróciłyby uwagi.

Dla porządku wielkości, które zdarzają się naprawdę: na serwerach KernelHost odfiltrowano między innymi atak o wolumenie ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę wymierzony w serwer głosowy oraz flood UDP o wolumenie ponad 112,2 Gbit/s w serwer gier. Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem.

Co przeciwstawia temu KernelHost

Stała ochrona zawarta w każdym pakiecie serwerowym

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.

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. Palworld należy do gier z własnym profilem ochrony, a które kolejne tytuły i protokoły są objęte, wylicza wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

Advanced DDoS Protection dla projektów Palworld 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, bez minimalnego okresu umowy i bez opłaty aktywacyjnej. 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: osobno ustalasz, co jest dozwolone na 8211 UDP, a co na 27015 UDP, bez pisania zgłoszenia.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, na przykład przejściowo ostrzej ograniczyć port zapytań i zostawić port gry nietknięty.
• Profil ochrony dopasowany do gry, dla Palworlda tak samo jak dla własnych aplikacji na dowolnych portach TCP albo UDP.

Advanced DDoS Protection jest skierowana do serwerów stojących w KernelHoście. Kto prowadzi swój projekt Palworld na razie gdzie indziej i jest stale atakowany, przenosi go w tym celu do KernelHostu, a wtedy obie warstwy działają od momentu udostępnienia.

Porównanie obu stopni

Dla większości serwerów Palworld 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.

Typowe błędy na serwerach Palworld i ich rozwiązania

„Zablokowałem 27015 i teraz serwer zniknął ze społecznościowej listy”: to zachowanie oczekiwane, bo wpis na liście niesie właśnie port zapytań. Nie blokuj go ryczałtem, tylko ogranicz bezpołączeniowe pakiety na adres źródłowy jak w kroku 4. Jeśli wpisu na liście i tak nie potrzebujesz, zostaw port zamknięty, wykreśl -publiclobby i podaj swoim graczom adres IP oraz port 8211 do połączenia bezpośredniego.

„Zmieniłem adres IP i dwie godziny później znowu byłem offline”: atakujący zdobył nowy adres z tego samego źródła co stary. W Palworldzie jest to prawie zawsze jedna z trzech dróg: gracz, który i tak ma adres wpisany w polu połączenia bezpośredniego, bot Discord ze statusem, który publikuje go na nowo, albo stary rekord A w DNS wskazujący na poprzedni adres. Zmiana adresu to zysk na czasie, a nie rozwiązanie.

„Serwer ma skoki lagów, ale łącze jest spokojne”: w Palworldzie to częściej obciążenie niż atak. Proces serwera z upływem czasu zajmuje coraz więcej pamięci operacyjnej, dlatego zaplanowany restart należy do normalnej pracy, a nie do doraźnych prowizorek. Sprawdź liczbę klatek serwera przez punkt końcowy z metrykami oraz zużycie pamięci przez proces. Jeśli sar -n DEV 1 10 pozostaje przy tym niepodejrzany, to nie był atak DDoS.

„Wszystkie 32 miejsca są zajęte, ale w grze nikogo nie widać”: to wyczerpanie slotów i trafia w logikę gry, a nie w łącze. Ustaw ServerPassword, zablokuj podejrzane konta przez listę banów i ogranicz liczbę pakietów na adres źródłowy na 8211 UDP.

„REST-API było przez kilka dni osiągalne z zewnątrz”: w takim razie twoje hasło administratora jest skompromitowane, bo HTTP Basic Auth przez nieszyfrowany HTTP przesyła je przy każdym zapytaniu w odwracalnej postaci. Zmień AdminPassword, zamknij 8212 TCP na zewnątrz i dostawaj się do interfejsu już tylko przez przekierowanie portu po SSH.

„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ą.

„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 Palworld potrzebuje dokładnie jednego otwartego portu: 8211 UDP. Port zapytań 27015 UDP jest potrzebny wyłącznie do wpisu na społecznościowej liście serwerów.
• RCON na 25575 TCP i REST-API na 8212 TCP nigdy nie należą do otwartej sieci, bo oba przesyłają dane dostępowe bez szyfrowania. RCON jest dodatkowo oznaczony przez Pocketpair jako przestarzały.
• Ponieważ ruch gry i zapytania o serwer leżą w Palworldzie na osobnych portach, 27015 UDP da się ostro ograniczyć, nie dotykając trwającego ruchu gry na 8211 UDP.
• Serwer dedykowany jest ograniczony do 32 miejsc, dlatego wyczerpanie slotów jest najtańszym atakiem. Ustawione ServerPassword jest przeciw temu najskuteczniejszym pojedynczym środkiem, bo Palworld nie ma wbudowanej whitelisty.
• Działania lokalne kończą się na łączu: 1 Gbit/s to 125 megabajtów na sekundę, a przy pakietach po 64 bajty mieści się tam około 1,49 miliona pakietów na sekundę. Wszystko powyżej musi kończyć się w sieci przed serwerem.
• W KernelHoście dwuwarstwowa stała ochrona jest zawarta w każdym pakiecie serwerowym bez dopłat i działa od momentu udostępnienia, bez null-routingu. Advanced DDoS Protection z dedykowanym chronionym adresem IP i samodzielnie zarządzanymi regułami na port zaczyna się od 50,00 € miesięcznie.

Jeśli twój serwer Palworld 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.