Ochrona serwera Hytale przed atakami DDoS

Serwer Hytale, który wieczorem w środku gry traci naraz wszystkie połączenia, przez kilka minut jest nieosiągalny, a potem sam z siebie znowu działa, rzadko ma problem ze sprzętem. Z reguły trwa atak. Ten wpis pokazuje, jak chronić serwer Hytale 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 od Hypixel Studios, czyli plików HytaleServer.jar razem z Assets.zip pod Javą 25, uruchamianych 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. Hytale jest w Early Access i zmienia się szybko: dlatego każde twierdzenie o grze nosi w tym wpisie datę, a wszystko, co nie jest oficjalnie udokumentowane, jest wyraźnie oznaczone jako oczekiwanie albo jako źródło społecznościowe. Jeśli atak trwa właśnie teraz, obowiązuje ponadto kolejność: najpierw mierzyć, potem zmieniać. Twardy restart pod obciążeniem odrzuca wszystko, co wydarzyło się w świecie od ostatniego punktu zapisu, a pomiary z incydentu są po nim również nie do odzyskania.

Dlaczego serwery Hytale są celowo kładzione atakami DDoS

Serwer Hytale to publiczność pod stałym adresem, a ta publiczność jest zastępowalna. Kto wieczorem trzy razy pod rząd nie wejdzie na swój stały serwer, szuka innego. Dokładnie w tym leży model biznesowy ataków na serwery społecznościowe: nie chodzi o dane ani o wymuszenie okupu, tylko o graczy, którzy odchodzą. Usługa booter, która ostrzeliwuje adres za kilka euro miesięcznie, nie wymaga od zlecającego ani umiejętności, ani nakładu pracy, a szkoda powstaje przy każdej awarii od nowa.

Do tego dochodzi przy Hytale pewna szczególność: kod serwera jest publiczny. Hypixel Studios ogłosiło w czerwcu 2026 roku program Hytale Shared Source i udostępnia w jego ramach przez GitHuba pełny kod serwera, protokół sieciowy oraz assety, dostępne dla każdego z ważną licencją na grę. Dla operatorów serwerów to zysk, bo wtyczki powstają wobec prawdziwych interfejsów. Dla strony atakującej oznacza to, że protokołu nikt już nie musi odgadywać. Kto chce wiedzieć, w którym miejscu nawiązywanie połączenia kosztuje czas procesora, może to odczytać. Co technicznie dzieje się przy takim ataku, wyjaśnia wpis Czym jest atak DDoS?.

Stan Hytale na 27 września 2026 roku

Hytale jest od 13 stycznia 2026 roku w Early Access, dostępne na Windowsa, macOS i Linuksa, a w dniach po starcie osiągnęło ponad milion graczy. Droga do tego była nietypowa i wyjaśnia, dlaczego starsze artykuły o Hytale często już się nie zgadzają.

Praktyczny wniosek z tej chronologii: serwer Hytale z dzisiaj nie jest serwerem ze stycznia. Z Update 6 protokół sieciowy zmienił się z hytale/2 na hytale/3, a według oficjalnych patch notes z 27 sierpnia 2026 roku serwer i wtyczki muszą zostać zbudowane na nowo, zanim się połączą. Kto planuje swoją dostępność, planuje więc nie tylko przeciwko atakom, ale i przeciwko zmianom protokołu.

Dlaczego 12 października 2026 roku to termin krytyczny

Duże aktualizacje treści działają jak drugi start sprzedaży. Sprowadzają starych graczy, przyciągają nowych, a na kilka dni to osiągalność decyduje o tym, który serwer społecznościowy wyrośnie z tej fali, a który ją przegapi. Ten wzorzec jest udokumentowany przy innych grach: Palworld osiągnął w styczniu 2024 roku w ciągu kilku dni miliony graczy, a serwery społecznościowe z tej fazy startowej były atakowane najmocniej dokładnie w chwili, w której miały najwięcej do stracenia. Mechanika za tym stojąca jest szczegółowo opisana we wpisie Ochrona serwerów Palworld przed atakami DDoS i daje się przenieść jeden do jednego na Hytale.

Wynika z tego niewygodna prawda o harmonogramie: ochrona zamówiona 12 października jest spóźniona. Łącze, chroniony adres IP, zestaw reguł na port i wartość pomiarowa dla normalnej pracy potrzebują wyprzedzenia, bo bez danych porównawczych nie da się ich sensownie ustawić. Kto zaczyna dwa tygodnie przed dużą aktualizacją, ma dość czasu. Kto zaczyna w dniu aktualizacji, ustawia na oślep.

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

Serwer Hytale potrzebuje dokładnie jednego otwartego portu: 5520 UDP. Ruch gry idzie przez QUIC, czyli przez UDP, a TCP nie jest do ruchu gry potrzebne. Kto otworzy tylko TCP, widzi ten sam obraz co przy zamkniętym firewallu: gracze wpadają w przekroczenie czasu. Domyślne wiązanie to 0.0.0.0:5520, inny port ustawia się przy starcie przez --bind.

Ta tabela jest krótsza niż przy większości innych gier i to najważniejsza różnica. Serwer Counter-Strike odpowiada na zapytania o status w formacie Steam A2S, serwer Minecraft Bedrock odpowiada na Unconnected Ping, serwer Palworld trzyma otwarty własny port zapytań. Dla Hytale w publicznej dokumentacji nie jest opisany obok 5520 UDP żaden dalszy port: ani port zapytań, ani port RCON, ani interfejs REST w stanie fabrycznym. Wszystko, co serwer Hytale oferuje na zewnątrz, leży na jednym jedynym porcie UDP.

Serwer Hytale w liczbach

Poniższe wartości są podstawą każdej decyzji o regułach filtrowania i progach. Pochodzenie stoi przy każdej z nich, bo decyduje ono o jej wiarygodności.

Co QUIC zmienia w powierzchni ataku

QUIC to protokół transportowy, który nawiązuje zabezpieczone połączenia przez UDP i ma wbudowane na stałe szyfrowanie według TLS 1.3. Nieszyfrowanego QUIC nie ma. Dla operatora serwera oznacza to dwie rzeczy, które sobie przeczą, i obie są ważne.

Pierwsza to prawdziwa poprawa. Ponieważ UDP nie wymusza nawiązania połączenia, a adresy nadawcy da się podrobić, bezpołączeniowe usługi UDP są klasycznymi wzmacniaczami przy atakach na osoby trzecie. QUIC ogranicza to już w standardzie. RFC 9000 nakazuje w rozdziale 8.1, że serwer przed sprawdzeniem adresu nadawcy może wysłać najwyżej trzykrotność odebranej liczby bajtów, a rozdział 14.1 wymaga, żeby klient dopełnił swój pierwszy datagram do co najmniej 1200 bajtów. Razem te dwie reguły podnoszą współczynnik amplifikacji usługi QUIC najwyżej do trzech, podczas gdy port zapytań Steam albo Unconnected Ping w Bedrocku osiąga jego wielokrotność. Poprawnie działający serwer Hytale jest więc jako wzmacniacz odbijający praktycznie nieinteresujący. To strukturalna zaleta wobec niemal wszystkich innych gier z ruchem UDP, a przy porównaniu z serwerami Minecraft Bedrock widać ją wyraźnie.

Druga to cena za to. Nawiązanie połączenia QUIC kosztuje serwer czas procesora, bo obejmuje uzgodnienie TLS 1.3 z kryptografią asymetryczną. Jeden podrobiony pakiet nie wymusi nawiązania połączenia, ale zalew prawdziwych prób połączenia z botnetu już tak. Atakujący płaci przy tym również czasem procesora, i dokładnie ten stosunek decyduje: dopóki serwer wykonuje na jedną próbę połączenia więcej pracy niż atakujący, atak jest ekonomiczny. Zalew prób połączenia obciąża więc nie łącze, tylko procesor, i w statystyce przepustowości nie wygląda na nic. To ten sam mechanizm, który przy Minecrafcie jest znany jako Nullping i zalew handshake'ów, a szczegółowo opisuje go wpis Ochrona DDoS Minecraft i ochrona przed Nullpingiem.

Praktycznie użyteczna jest z tego przede wszystkim reguła 1200 bajtów. Nowa próba połączenia musi dotrzeć jako datagram o rozmiarze co najmniej 1200 bajtów, bo inaczej według standardu nie jest to prawidłowe nawiązanie połączenia. Bieżący ruch gry składa się natomiast w przewadze z małych pakietów. Ta różnica daje się zamienić w regułę filtrowania, a do tego dojdziemy za chwilę.

Czego o Hytale nie ma w publicznej dokumentacji

Ta lista należy do uczciwego artykułu, bo ustala, gdzie nie wolno ci polegać na liczbach. Wszystko poniższe nie jest na stan 27 września 2026 roku oficjalnie udokumentowane:

• Czy serwer stosuje QUIC Retry do sprawdzenia adresu. RFC 9000 dopuszcza w rozdziale 8.1.2 pakiet Retry z tokenem, którym serwer sprawdza adres nadawcy, zanim zajmie zasoby. Czy i od jakiego obciążenia Hytale to robi, nie jest udokumentowane. Przyjmij, że nie możesz na tym polegać.
• Wartości domyślne bloków RateLimit i ConnectionTimeouts w config.json. To, że oba bloki istnieją, jest zgodne w kilku źródłach. Podawane liczby przeczą sobie jednak wzajemnie: jedno źródło podaje konkretne progi, inne opisuje bloki jako obecne, ale bez skutku. Dlatego w tym wpisie nie stoi żadna z tych liczb i dlatego nie powinieneś planować tych bloków jako swojej obrony.
• Nazwy i wartości domyślne trybów uwierzytelniania. Dokumentacja społeczności do opublikowanego kodu serwera opisuje trzy tryby, ustawiane przez --auth-mode, z authenticated jako domyślnym oraz offline i insecure dla środowisk prywatnych i pracy rozwojowej. Oficjalnie nie jest to potwierdzone. Wyprowadzona z tego reguła jest i tak jednoznaczna: nie zmieniaj trybu na serwerze publicznym.
• Szczegóły budowy TLS. Społecznościowa dokumentacja protokołu, oparta na opublikowanym kodzie serwera, opisuje certyfikat obustronny, generowany przy starcie certyfikat serwera wystawiony samodzielnie, którego odcisk SHA-256 dociera do klientów przez usługę sesji, oraz wyłączone 0-RTT. To jest wiarygodne i pasuje do TLS 1.3, ale nie jest oficjalnie potwierdzone i nie zmienia niczego w działaniach opisanych niżej.
• Skala ataków specjalnie przeciwko serwerom Hytale. Nie ma na to publicznych liczb. Podane w tabeli 5 do 50 Gbit/s to wartość doświadczalna z projektów serwerów gier i wyraźnie nie statystyka Hytale.
• Liczba pakietów na gracza w normalnej pracy. Także na to nie ma wiarygodnej publikacji. Dlatego w tym wpisie nie stoi próg, który mógłbyś przejąć bez sprawdzenia, tylko instrukcja, jak zmierzyć go samemu.

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

Poniższe kroki nie zatrzymają ataku wolumetrycznego, tego nie zrobi żadne oprogramowanie na serwerze. Sprzątają natomiast wszystko, co leży poniżej: skanowanie portów, zalewy prób połączenia z niewielu źródeł, próby przejęcia przez doinstalowane interfejsy administracyjne oraz zajęcie wszystkich miejsc przez obcych. To większość tego, co na co dzień zakłóca serwer Hytale, i kosztuje dobrą godzinę.

1. Inwentaryzacja: co nasłuchuje na serwerze?

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

ss -lntup

Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:5520 oznacza „osiągalny z całego internetu”, 127.0.0.1:8080 oznacza „tylko lokalnie” i nie potrzebuje żadnej przepustki. Obok procesu Javy samego serwera na rozrośniętej maszynie pojawiają się często panel administracyjny, serwer WWW dla podglądu mapy oraz baza danych. Spojrzenie oczami atakującego daje skan portów z zewnątrz:

nmap -Pn -sU -p 5520 TWOJ.ADRES.IP.SERWERA
nmap -Pn -p- --min-rate 1000 TWOJ.ADRES.IP.SERWERA

Drugie polecenie jest ważniejsze. Pokazuje, co stoi jeszcze otworem, a w praktyce jest tego prawie zawsze więcej, niż się spodziewasz.

2. Zostaw otwarte tylko 5520 UDP, całą resztę zamknij

Dwie przepustki wystarczą. 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 5520/udp comment 'Hytale QUIC'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Przepustki TCP na 5520 nie potrzebujesz. Jeśli prowadzisz serwer na innym porcie, przepustka musi pasować do wartości z --bind, bo inaczej start przejdzie, a gracze i tak nie dotrą. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

Dla wszystkiego, co doinstalowałeś do administracji, obowiązuje ta sama reguła co przy każdej innej grze: nie do otwartej sieci, tylko osiągalne przez przekierowanie portu po SSH, a potem praca lokalnie wobec 127.0.0.1:

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

3. Uruchom serwer tak, jak został pomyślany

Start składa się z jednego jedynego polecenia. Pliki serwera bierzesz z oficjalnego downloadera Hytale albo z własnej instalacji gry:

java -Xms2G -Xmx4G -jar HytaleServer.jar --assets Assets.zip --bind 0.0.0.0:5520

Przy pierwszym starcie serwer zakłada config.json, katalog logs/ oraz katalog świata universe/. Potem logujesz go jednorazowo na jego konto, żeby uwierzytelnianie graczy działało. Idzie to przez kod urządzenia w konsoli serwera:

/auth login device
/auth status

Nie ustawiaj -Xmx na całą pamięć operacyjną maszyny. System operacyjny, cache systemu plików oraz narzut środowiska Javy poza stertą też potrzebują miejsca, a serwer, który pod obciążeniem wchodzi w pamięć wymiany, wygląda dla twoich graczy dokładnie jak atak.

4. Whitelista, hasło serwera i górna granica liczby graczy przeciw wyczerpaniu slotów

Wyczerpanie slotów to najtańszy atak na serwer społecznościowy i nie potrzebuje żadnej przepustowości. Kto zbuduje dość równoczesnych połączeń, zajmie wszystkie miejsca i zamknie tym samym dostęp właściwej społeczności, nie kupując ani jednego gigabita. Hytale ma na to, w odróżnieniu od niektórych innych gier, odpowiednie narzędzia już w stanie fabrycznym: whitelistę w whitelist.json, listę blokad w bans.json, uprawnienia w permissions.json oraz w config.json klucze Password i MaxPlayers.

{
  "ServerName": "Mój serwer Hytale",
  "MOTD": "",
  "Password": "wartość, którą zna tylko twoja grupa",
  "MaxPlayers": 40,
  "MaxViewRadius": 12
}

Password jest fabrycznie puste, każdy z adresem i portem wchodzi więc do środka. Dla serwera zamkniętego ustawione hasło jest najskuteczniejszym pojedynczym działaniem przeciw wyczerpaniu slotów, a dla serwera publicznego jest nim whitelista w czasie fali ataków. Jedno musi być przy tym jasne: hasło serwera chroni twoje miejsca, a nie twoje łącze. Atakujący, który zalewa twój serwer, wcale nie chce dołączyć.

Edytuj te pliki tylko przy zatrzymanym serwerze. Działający proces serwera trzyma swój własny stan w pamięci i może przy zamykaniu bez słowa nadpisać zmiany, które w tym czasie wpiszesz do pliku. Do zmian w czasie pracy używaj poleceń konsoli, a nie edytora.

5. Zostaw uwierzytelnianie na wartości domyślnej

Tryb domyślny wymaga od każdego gracza ważnego konta Hytale. To więcej niż sprawdzenie licencji: to filtr dostępu, który czyni konta masowe drogimi. Atakujący, który chce zajmować miejsca, potrzebuje do tego ważnych kont, a te kosztują pieniądze. Nie wyjmuj tego filtra.

Dokumentacja społeczności opisuje obok domyślnego dwa dalsze tryby, dla środowisk prywatnych i do pracy rozwojowej, z którymi można dołączyć bez sprawdzenia konta. Dla serwera publicznego są one najgorszym osiągalnym ustawieniem, bo zamieniają wyczerpanie slotów z kwestii pieniędzy na kwestię skryptu. Jeśli przełączasz do testów, to na maszynie, która nie stoi w internecie, a potem przełączasz z powrotem.

6. Ogranicz nowe próby połączenia, i to regułą 1200 bajtów

Teraz strukturalna zaleta QUIC staje się praktyczna. Prawidłowe nawiązanie połączenia dochodzi według RFC 9000 jako datagram o rozmiarze co najmniej 1200 bajtów. Bieżący ruch gry jest wyraźnie mniejszy. Przy pomocy śledzenia połączeń możesz więc odróżnić nowe strumienie danych od istniejących i odrzucać wszystko, co jest nowe i za małe. Przez nftables, wczytane poleceniem nft -f:

table inet hytale {
    chain input {
        type filter hook input priority -10; policy accept;

        ct state new udp dport 5520 udp length < 1208 drop

        ct state new udp dport 5520 \
            meter hyconn { ip saddr limit rate over 5/second burst 10 packets } drop
    }
}

Pierwsza reguła pracuje na długości UDP, czyli 8 bajtów nagłówka plus 1200 bajtów ładunku, razem 1208. Trafia wyłącznie w pakiety, które chcą otworzyć nowy strumień danych i są na to za małe, a połączonych graczy trafić nie może. Druga reguła ogranicza, ile nowych połączeń jeden adres źródłowy może otworzyć na sekundę. Pięć na sekundę to hojnie: prawdziwy gracz nawiązuje jedno połączenie i je zatrzymuje. Priorytet -10 sprawia, że obie reguły działają przed łańcuchem filtrującym UFW.

Trzecią sensowną regułą jest górny limit liczby pakietów na adres źródłowy na samym porcie gry, i tutaj obowiązuje wyraźnie: wartość liczbowa jest wartością startową, a nie prawdą objawioną.

iptables -I INPUT -p udp --dport 5520 \
  -m hashlimit --hashlimit-name hytale_udp --hashlimit-mode srcip \
  --hashlimit-above 800/sec --hashlimit-burst 1200 -j DROP

Mierz najpierw tydzień w normalnej pracy, potem ustaw granicę na podwójną wartość zmierzonego szczytu. Dla Hytale nie ma na to opublikowanej liczby odniesienia, a wartości silnie zależą od liczby graczy i zasięgu widzenia. Kto ustawi zbyt ciasno, wyrzuci własnych graczy, i to najpierw tych z najgorszym łączem.

Same reguły iptables znikają po restarcie. Na Debianie i Ubuntu zapisuje się 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.

7. Ustaw poprawnie śledzenie połączeń w kernelu

Ten punkt wyjaśnia awarie, które wyglądają jak atak wolumetryczny, ale nim nie są. Kernel zakłada dla ruchu UDP wpisy w śledzeniu połączeń, a przy podrobionych adresach nadawcy każdy adres oznacza nowy wpis. Gdy tablica jest pełna, 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

Przy większości gier najlepszą odpowiedzią na to jest całkowite wyłączenie śledzenia ruchu gry. Przy Hytale to prawdziwe wyważenie, bo reguła 1200 bajtów z kroku 6 potrzebuje śledzenia połączeń. Bez niego filtr nie wie, który pakiet otwiera nowy strumień danych. Zalecenie brzmi zatem: śledzenie zachować, tablicę powiększyć, przekroczenie czasu dla UDP trzymać krótko. Dodatek pod /etc/sysctl.d/, aktywowany przez sysctl --system:

net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 120
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Kto chce jednak śledzenie wyłączyć, na przykład na maszynie z bardzo wieloma równoczesnymi graczami, ustawia udp dport 5520 notrack w tablicy raw i rezygnuje tym samym z reguły 1200 bajtów. Jedno i drugie razem nie zadziała. Dla pojedynczego serwera Hytale reguła jest warta więcej niż zaoszczędzone wpisy w tablicy.

Jeśli pakiety przychodzą szybciej, niż proces Javy je odbiera, przelewa się dodatkowo bufor odbioru. Dla graczy wygląda to jak utrata pakietów, choć łącze jest wolne. Czy ustawienia buforów powyżej są potrzebne, powie ci sam kernel: jeśli UdpRcvbufErrors w nstat -az rośnie, to działają. Jeśli licznik zostaje na zerze, dostosowanie nic nie zmienia.

8. Dobierz zasięg widzenia i liczbę graczy do łącza

Ten krok nie jest działaniem bezpieczeństwa, ale decyduje o tym, ile ataku w ogóle zniesiesz. Hypixel Studios sformułowało to jasno w oficjalnych wymaganiach sprzętowych z 1 grudnia 2025 roku: jeśli podwoisz zasięg widzenia, czterokrotnie zwiększysz ilość świata wokół gracza. Oficjalne zalecenie leży przy najwyżej 12 chunkach, czyli 384 blokach, ustawianych przez MaxViewRadius. Po stronie klienta te same wymagania podają 2 Mbit/s jako minimum i 8 Mbit/s jako zalecenie na gracza przy grze wieloosobowej.

Przelicz to raz dla swojego serwera. Serwer z 40 graczami przy hojnym zasięgu widzenia przenosi w normalnej pracy niski trzycyfrowy zakres megabitów. To wartość, którą musi udźwignąć twoje łącze, i jednocześnie wartość, którą atak musi przekroczyć, żeby zwrócić uwagę. Kto zapełnia łącze 1 Gbit/s w jednej trzeciej już w normalnej pracy, ma mniej rezerwy niż ktoś, kto leży na pięciu procentach. Mniejszy zasięg widzenia to więc nie tylko kwestia wydajności, ale i kwestia odporności.

9. Trzymaj mody, wtyczki i zmiany protokołu pod obserwacją

Hytale jest moddowalne po stronie serwera: mody leżą jako .zip albo .jar w katalogu mods/, a wtyczki zwracają się wprost do interfejsu serwera. To wygodne, bo gracze nie muszą nic instalować, i jednocześnie jest to ryzyko dostępności, które nie ma nic wspólnego z atakami. Wtyczka, która na każde zdarzenie sieciowe pracuje kosztownie, jest wzmacniaczem w twoim własnym domu.

Do tego dochodzi zmiana protokołu. Z Update 6 protokół sieciowy zmienił się według oficjalnych patch notes z 27 sierpnia 2026 roku z hytale/2 na hytale/3, a serwer i wtyczki muszą zostać zbudowane na nowo, zanim się połączą. Dla dostępności oznacza to: prowadź listę swoich modów razem z wersjami, sprawdzaj je przed każdą aktualizacją na drugiej instancji i zaplanuj przed 12 października 2026 roku okno serwisowe. Serwer, który po aktualizacji nie startuje, jest dla twoich graczy nie do odróżnienia od ataku.

10. 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 nie powiesz po incydencie, czy 40 000 pakietów na sekundę to było dużo, czy po prostu sobotni wieczór. Po apt-get install -y vnstat sysstat conntrack pomiar chodzi na stałe w tle. W trakcie incydentu wystarczy pięć poleceń:

sar -n DEV 1 10
ip -s link show eth0
conntrack -C
nstat -az | grep -i -E 'udp|drop'
tcpdump -ni eth0 -c 200 "udp port 5520"

Przy tcpdump obowiązuje zasada: zawsze ograniczaj przez -c, bo zrzut przy pełnym obciążeniu dodatkowo obciąża i tak przeciążony serwer. Ponieważ serwer Hytale działa na Javie, potrzebujesz drugiej próby, która wyklucza najczęstszy fałszywy alarm. Przerwa na sprzątanie pamięci wygląda dla graczy dokładnie tak samo jak atak: wszyscy stają jednocześnie, potem gra się dalej. Różnica stoi w liczbach.

jcmd $(pgrep -f HytaleServer.jar) GC.heap_info
tail -n 200 logs/latest.log

Odczyt jest prosty. Jeśli pakiety wejściowe rosną daleko powyżej wartości normalnej, a proces Javy prawie nie pracuje, to atak. Jeśli liczba pakietów pozostaje niepozorna, a sterta się zapełnia albo log pokazuje długie przerwy, to obciążenie. Jak odczytywać wartości sieciowe szczegółowo, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

11. Backup, plan awaryjny i próbny przebieg przed dużym terminem

Koncepcja ochrony, która nigdy nie była testowana, jest przypuszczeniem. Przed terminem takim jak 12 października 2026 roku należy mieć zrobione cztery rzeczy: backup katalogu universe/ razem z config.json, leżący poza maszyną, sprawdzony powrót do poprzedniej wersji serwera, drugą instancję, na której wpuszczasz aktualizację jako pierwszą, oraz jednorazowy test obciążeniowy, który wyzwala twoje własne reguły filtrowania.

Test obciążeniowy to punkt, na którym większość operatorów się zatrzymuje, i jest najważniejszy. Sprawdzaj nie to, czy twoje reguły odpierają ataki, tylko to, czy przepuszczają twoich własnych graczy. Wystarczy do tego obserwować liczniki trafień, podczas gdy dwudziestu prawdziwych graczy dołącza jednocześnie. Jeśli liczniki reguł odrzucających przy tym rosną, twoja granica jest ustawiona za ciasno, a dowiedziałbyś się o tym w dniu aktualizacji, w najgorszych możliwych warunkach.

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 leżą zwyczajowo między 5 a 50 Gbit/s, czyli na pięcio- do pięćdziesięciokrotności twojego łącza. Czy twoja reguła nftables za nim jest dobra, nie ma wtedy już znaczenia, bo pakiety twoich graczy nie przechodzą już wcześniej.

Druga wielkość to liczba pakietów i często uderza 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 to położyć twój serwer, bo czas procesora idzie na odrzucanie. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszystko padło”.

Przy Hytale dochodzi trzecia wielkość, której przy większości gier nie ma: czas procesora na nawiązanie połączenia. Zalew prawidłowych prób połączenia z botnetu nie zapełnia łącza i nie wytwarza rzucającej się w oczy liczby pakietów, tylko zajmuje procesor kryptografią. Takie ataki są w statystyce przepustowości niewidoczne, a w obciążeniu procesora przez proces Javy wyraźne, i nie pomoże na nie ani ograniczenie liczby na adres źródłowy, ani większy bufor odbioru, jeśli źródeł jest dość wiele.

Dla uporządkowania, jakie rzędy wielkości realnie występują: na serwerach KernelHost odfiltrowano między innymi atak o wolumenie ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę na serwer głosowy oraz flood UDP o wolumenie ponad 112,2 Gbit/s na serwer gry. Na to nie ma żadnego ustawienia lokalnego. Ataki wolumetryczne muszą kończyć się w sieci przed serwerem.

Co KernelHost przeciwstawia atakom DDoS na serwery Hytale

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. Które tytuły i protokoły są objęte własnymi profilami ochrony, wylicza wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

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

Niektóre projekty są atakowane nie okazjonalnie, tylko celowo i przez wiele tygodni, a przy grze w Early Access dotyka to szczególnie serwerów, które właśnie rosną. 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: ustalasz, co jest dozwolone na 5520 UDP, osobno od wszystkiego innego, i nie potrzebujesz do tego zgłoszenia.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, na przykład na krótko ostrzej ograniczyć nowe połączenia, a bieżący ruch gry zostawić nietknięty.
• Zestaw reguł dopasowany do protokołu, tak dla QUIC przez UDP, jak i dla własnych aplikacji na dowolnych portach TCP albo UDP.

Advanced DDoS Protection jest skierowana do serwerów, które stoją w KernelHoście. Kto prowadzi swój projekt Hytale obecnie 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 warstw

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

Co da się przenieść z innych gier na Hytale

Ponieważ Hytale jest jeszcze młode, a o atakach na serwery Hytale nie ma publicznych liczb, najszybszą drogą do wiarygodnej wiedzy jest spojrzenie na gry porównywalne. Przenosi się przy tym nie numer portu, tylko wzorzec.

• Wybuchowy start i to, co wywołuje: Palworld pokazuje, jak fala nowych graczy i fala ataków nakładają się w czasie i dlaczego celem stają się właśnie rosnące serwery.
• Różnica między zapytaniem a ruchem gry: Minecraft Bedrock wyjaśnia na przykładzie Unconnected Ping, jak działa amplifikacja przez UDP. Dokładnie tej drogi ataku Hytale przez QUIC nie ma, i na tym najlepiej zrozumieć różnicę.
• Nawiązywanie połączenia jako cel ataku: Ochrona DDoS Minecraft i ochrona przed Nullpingiem opisuje zalewy handshake'ów, które obywają się prawie bez przepustowości. To najbliższy krewny zalewu połączeń QUIC.
• Małe liczby graczy i wyczerpanie slotów: Project Zomboid i Conan Exiles pokazują, jak niewiele nakładu trzeba, żeby zamknąć dostęp stałej grupie, i jaką rolę odgrywają przy tym whitelista i hasło.
• Praca pod stałym obciążeniem: Terraria pokazuje, jak pojedynczy proces serwera z obciążeniem jednordzeniowym reaguje na ataki. Serwer Hytale jest procesem Javy, problem podstawowy jest porównywalny.

Typowe błędy przy serwerach Hytale i ich rozwiązanie

„Otworzyłem port 5520 TCP, a gracze i tak nie wchodzą”: ruch gry idzie przez QUIC, czyli przez UDP. Przepustka TCP nie daje dla ruchu gry nic. Otwórz 5520 UDP i sprawdź to z zewnątrz przez nmap -Pn -sU -p 5520. Jeśli przełożyłeś serwer przez --bind na inny port, przepustka musi wskazywać ten port.

„Serwer działa, ale nikt nie może dołączyć, a w logu nie ma nic o atakach”: sprawdź logowanie serwera na jego konto przez /auth status. Serwer, którego logowanie wygasło, działa dalej, a graczy mimo to odrzuca. To nie problem sieciowy i nie reguła filtrowania.

„Po aktualizacji nic już nie startuje”: to nie atak, tylko zmiana protokołu. Z Update 6 protokół sieciowy zmienił się z hytale/2 na hytale/3, a serwer oraz wtyczki potrzebują nowego zbudowania. Wpuszczaj aktualizacje najpierw na drugą instancję, zanim dopuścisz je na serwer produkcyjny.

„Wszyscy gracze stają jednocześnie na dwie sekundy, potem gra się dalej”: to z dużym prawdopodobieństwem sprzątanie pamięci przez środowisko Javy, a nie atak. Sprawdź jcmd ... GC.heap_info oraz log serwera. Jeśli sar -n DEV 1 10 pozostaje przy tym niepozorny, ataku w grze nie było, tylko za skromnie odmierzona sterta albo za duży zasięg widzenia.

„Moja reguła przeciw małym pakietom zamknęła dostęp graczom”: wtedy warunek 1200 bajtów stoi w łańcuchu bez ct state new. Bieżący ruch gry składa się w przewadze z małych pakietów, a warunek długości bez sprawdzenia stanu trafia dokładnie w nie. Warunek dotyczy wyłącznie nowo otwieranych strumieni danych.

„Zmieniłem adres IP i dwie godziny później znowu byłem offline”: atakujący ma nowy adres z tego samego źródła co stary. Przy Hytale to zwykle stary rekord A w DNS, bot Discorda ze statusem albo wpis na jednej z wielu list serwerów od podmiotów trzecich. Od Update 6 adresy serwerów na oficjalnej liście serwerów są fabrycznie ukryte, co zamyka najwygodniejszą drogę, ale nie wszystkie. Zmiana adresu to zysk czasu, a nie rozwiązanie.

„Moje reguły filtrowania 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órej 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 Hytale potrzebuje dokładnie jednego otwartego portu: 5520 UDP dla QUIC. TCP do ruchu gry nie jest potrzebne, a w publicznej dokumentacji nie jest opisany żaden dalszy port do zapytań, RCON czy zdalnego sterowania.
• Ponieważ QUIC według RFC 9000 może przed sprawdzeniem adresu wysłać najwyżej trzykrotność odebranej liczby bajtów, a pierwsza próba połączenia musi mieć co najmniej 1200 bajtów, serwer Hytale jest jako wzmacniacz odbijający praktycznie nieinteresujący. To odróżnia go od serwerów z zapytaniem Steam albo z Unconnected Ping w Bedrocku.
• Ta sama reguła 1200 bajtów jest najlepszą lokalną regułą filtrowania: to, co chce otworzyć nowy strumień danych na 5520 UDP i jest mniejsze, nie może być prawidłowym nawiązaniem połączenia i daje się odrzucić bez trafiania połączonych graczy.
• Kosztowną częścią nawiązania QUIC jest kryptografia, a nie przepustowość. Zalew prawidłowych prób połączenia jest w statystyce przepustowości niewidoczny i widać go tylko w obciążeniu procesora oraz w licznikach nowych połączeń.
• Tryb domyślny z obowiązkiem konta jest filtrem dostępu, który czyni konta masowe drogimi. Dla serwera publicznego zostaje nietknięty, a do tego dochodzą whitelist.json, bans.json i ustawiona wartość w Password przeciw wyczerpaniu slotów.
• 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.
• Hytale jest od 13 stycznia 2026 roku w Early Access, a Chapter 1 zapowiedziano na 12 października 2026 roku. Duże terminy są terminami ataków, a ochrona zamówiona w dniu terminu przychodzi za późno.
• 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 Hytale 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.

Ten wpis ma stan z 27 września 2026 roku. Hytale jest w Early Access, a protokół sieciowy zmienił się w tym roku już raz. Wpis będzie uzupełniany po Chapter 1 oraz po każdej aktualizacji, która dotyczy nawiązywania połączenia, portów albo listy serwerów.