Ochrona serwera Unturned przed atakami DDoS

Serwer Unturned, który wieczorem na kilka minut znika z listy serwerów i wyrzuca przy tym wszystkich graczy z przekroczeniem czasu, rzadko ma problem ze sprzętem. Zwykle trwa atak, i to dokładnie wtedy, gdy dzieje się najwięcej. Ten artykuł pokazuje najpierw, co możesz zabezpieczyć sam i bez dodatkowych kosztów, potem, gdzie te działania kończą się technicznie, a na koniec, co musi wydarzyć się w sieci przed serwerem.

Wszystkie informacje dotyczą serwera dedykowanego Unturned (U3DS, App-ID 1110390 w SteamCMD) 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 trwa właśnie teraz, nie zmieniaj niczego w konfiguracji i nie restartuj serwera: zabezpiecz pomiary (rozdział 10), po ataku już ich nie będzie.

Dlaczego akurat serwery Unturned są atakowane

Serwery Unturned są atakowane, bo ich adres jest publiczny, ruch gry idzie przez UDP, a atak nie kosztuje zlecającego ani umiejętności, ani liczących się pieniędzy. Wszystkie trzy punkty obowiązują tutaj mocniej niż przy większości innych gier.

Publiczny serwer Unturned sam publikuje swój adres IP. Musi to robić, bo inaczej nikt by go nie znalazł: przeglądarka serwerów Steam odpytuje go bezpośrednio, a listy zewnętrzne, jak unturned-servers.net albo BattleMetrics, podają adres IP i port otwartym tekstem. unturned-servers.net sprawdza w tym celu według własnej informacji co pięć minut, czy serwer przyjmuje połączenia UDP na porcie serwera. Dla atakującego to nie jest wysiłek, tylko formularz.

Dochodzi do tego sama społeczność. Unturned jest darmowe, próg wejścia wynosi zero, a między projektami roleplay i survival trwa realna konkurencja o tych samych graczy. Zbanowany gracz, urażony były administrator albo sąsiedni projekt nie potrzebuje dostępu do twojego serwera, żeby uczynić go bezużytecznym na godzinę. Czym technicznie jest atak DDoS i dlaczego podrobione adresy nadawcy tak utrudniają jego namierzenie, wyjaśnia wpis Czym jest atak DDoS?.

Porty, o które naprawdę chodzi

Serwer Unturned zajmuje dokładnie dwa następujące po sobie porty UDP: wartość ustawioną w Commands.dat oraz tę wartość plus jeden. Domyślnie są to 27015 i 27016. Oficjalna dokumentacja Smartly Dressed Games opisuje ten podział tak: pierwszy port niesie zapytania listy serwerów, drugi ruch gry. Ustawia się tylko pierwszy, drugi wynika automatycznie.

Name Moj Serwer Unturned
Port 27015
MaxPlayers 24
Map PEI
Mode Normal
Perspective Both
Owner 76561198000000000

Plik Commands.dat leży pod U3DS/Servers/<Instancja>/Server/Commands.dat. Jego format jest osobliwy i bywa częstym źródłem błędów: jedno polecenie na wiersz, bez znaku równości, wartość oddzielona spacją, a polecenia rozróżniają wielkość liter. Wiersze zaczynające się od // są komentarzami.

Najważniejszy punkt dla firewalla brzmi: port 27017 nie jest już potrzebny od wersji 3.21.30.0 z 21 listopada 2021. Wcześniej serwer Unturned wymagał trzech portów, bo zapytanie Steam leżało na porcie plus dwa. Wraz z tą aktualizacją zapytanie dzieli port z samym serwerem, a trzeci port odpadł. Instrukcje do routerów, wiki hostingów i wpisy na forach mimo to do dziś wymieniają 27017. Otwarty 27017 nie daje ci już żadnej korzyści, jest czystą powierzchnią ataku.

Równie ważne: Unturned nie ma wbudowanego portu RCON. Oficjalna dokumentacja zna tylko wejście i wyjście konsoli, które da się zastąpić przez interfejs ICommandInputOutput. Każde zdalne sterowanie, jakie zobaczysz na serwerze Unturned, pochodzi z pluginu i przynosi własny port TCP. Ten port musisz sam znaleźć i sam ograniczyć, bo nikt nie zabezpieczył go za ciebie.

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

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

1. Inwentaryzacja: co naprawdę nasłuchuje

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

ss -lnup
ss -lntp

Pierwsze polecenie pokazuje nasłuchujące gniazda UDP, drugie gniazda TCP. Interesuje cię kolumna z adresem lokalnym. 0.0.0.0:27015 oraz [::]:27015 oznaczają „osiągalny z całego internetu”, 127.0.0.1:3306 oznacza „tylko lokalnie” i nie potrzebuje żadnej reguły firewalla. Obok gry pojawiają się tam często plugin RCON, panel webowy, baza danych oraz stary serwer testowy na 27017, z którego nikt już nie korzysta. Spojrzenie oczami atakującego daje skan portów z zewnątrz, przy Unturned wyraźnie z UDP:

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

2. Zostaw otwarte tylko 27015 i 27016

Dla Unturned wystarczą dwa otwarcia UDP na zewnątrz. Dla samej gry nie jest potrzebny ani jeden port TCP: oficjalna dokumentacja wymaga dla obu portów wyraźnie UDP, a warstwa sieciowa gry (Steam Networking Sockets, od jednej z aktualizacji ustawienie domyślne) pracuje wyłącznie przez UDP. Kto dodatkowo otwiera TCP, idzie za przestarzałą instrukcją.

ufw allow 22/tcp comment 'SSH'
ufw allow 27015/udp comment 'Unturned zapytania'
ufw allow 27016/udp comment 'Unturned gra'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Kolejność jest ważna, inaczej zamkniesz dostęp samemu sobie. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu. Jeśli prowadzisz kilka instancji, zachowaj zalecany odstęp dwóch portów (27015, 27017, 27019) i otwórz dla każdej instancji dokładnie te dwa porty, które faktycznie zajmuje.

Panel webowy, baza danych albo plugin RCON nie należą do otwartej sieci. Ogranicz dany port do swojego własnego adresu przez ufw allow from 203.0.113.10 to any port 8080 proto tcp albo dostawaj się do interfejsu lokalnym przekierowaniem SSH przez ssh -N -L 8080:127.0.0.1:8080 root@TWOJ.ADRES.IP.SERWERA. Bazę danych wiąże się z 127.0.0.1.

3. Zabezpiecz port zapytań, nie wylatując z listy serwerów

Port zapytań jest najczulszym punktem serwera Unturned. Przez niego serwer odpowiada na zapytania Steam A2S_INFO, A2S_PLAYERS i A2S_RULES. Zablokuj go całkowicie, a serwer zniknie z każdej listy serwerów, nawet jeśli działa bez zarzutu.

Odpowiedź A2S jest wyraźnie większa od zapytania. US-CERT podaje protokół Steam w swoim zestawieniu wzmacniających ataków UDP (TA14-017A) ze współczynnikiem wzmocnienia pasma 5,5. Konkretnie znaczy to: atakujący wysyła zapytania z podrobionym adresem nadawcy do cudzych serwerów gier i kieruje około pięć i pół raza większe odpowiedzi na swój właściwy cel. Twój serwer nie jest wtedy ofiarą, tylko wzmacniaczem przeciw osobie trzeciej. W drugą stronę zalew zapytaniami wystarczy, żeby serwer zniknął z przeglądarki serwerów, choć nie wyleci ani jeden gracz. Operatorzy zgłaszają dokładnie to: serwer działa, gracze na nim niczego nie zauważają, ale nie da się go znaleźć.

Przeciw małym zalewom zapytaniami pomaga górny limit na adres źródłowy. Legalne zapytania przychodzą rzadko: przeglądarka Steam pyta raz na wyświetlenie, usługi statusowe co kilka minut.

iptables -I INPUT -p udp --dport 27015 -m hashlimit --hashlimit-name unturned_query --hashlimit-mode srcip --hashlimit-above 10/sec --hashlimit-burst 20 -j DROP
iptables -I INPUT -p udp --dport 27016 -m hashlimit --hashlimit-name unturned_game --hashlimit-mode srcip --hashlimit-above 300/sec --hashlimit-burst 500 -j DROP

Druga liczba wynika wprost z gry: Unturned ogranicza gracza fabrycznie do 50 pakietów na sekundę (Max_Packets_Per_Second). 300 pakietów na sekundę i adres źródłowy zostawia więc pojedynczemu łączu sporo zapasu, nawet gdy za tym samym adresem siedzi kilku graczy. Obie wartości to wartości startowe, a nie prawdy objawione. Najpierw mierz przez tydzień normalną pracę, inaczej wyrzucisz własnych graczy.

Same reguły iptables znikają po restarcie. Na Debianie i Ubuntu zapisuje się je przez apt-get install -y iptables-persistent oraz netfilter-persistent save. Przy UFW takie reguły należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload.

Dochodzi do tego nawyk, który nic nie kosztuje: jeśli twoja strona albo twój bot na Discordzie pokazuje liczbę graczy, nie odpytuj serwera z przeglądarki odwiedzającego, tylko buforuj wynik w stałych odstępach. Inaczej popularna strona ze statusem generuje jedno zapytanie na odwiedzającego zamiast jednego na interwał.

4. Ustaw wbudowane granice w pliku Config.json

Unturned przynosi w pliku Config.json, w tym samym folderze Server co Commands.dat, sekcję ważniejszą dla obrony, niż sugeruje jej nazwa. Ustawienia domyślne wyglądają tak:

"Server": {
    "VAC_Secure": true,
    "BattlEye_Secure": true,
    "Max_Ping_Milliseconds": 750,
    "Timeout_Queue_Seconds": 15.0,
    "Timeout_Game_Seconds": 30.0,
    "Max_Packets_Per_Second": 50.0,
    "Join_Rate_Limit_Window_Seconds": 40.0,
    "Rate_Limit_Kick_Threshold": 10,
    "Use_FakeIP": false
}

Max_Packets_Per_Second ogranicza połączonego gracza do 50 pakietów na sekundę. Join_Rate_Limit_Window_Seconds oraz Rate_Limit_Kick_Threshold wyrzucają połączenie, które w ciągu 40 sekund przekroczy granicę więcej niż dziesięć razy. VAC_Secure i BattlEye_Secure wymagają obu systemów anti-cheat po stronie gracza i trzymają tym samym z daleka większość klientów jednorazowych.

Jedno musi być przy tym jasne: te granice działają przeciw klientom, którzy faktycznie dołączają albo próbują dołączyć. Przeciw zalewowi z podrobionymi adresami nadawcy nie działają, bo tam nigdy nie powstaje sesja. Mimo to są ważne, bo wyłapują najczęstszy pojedynczy przypadek: jednego zmanipulowanego klienta, który sam przeciąża serwer. Zostawienie Max_Ping_Milliseconds na 750 jest sensowne; ustawiony niżej serwer wyrzuca po każdym krótkim zacięciu sieci pół rundy graczy.

5. Odciąż śledzenie połączeń

Ten punkt bywa pomijany prawie zawsze i wyjaśnia awarie, które wyglądają jak atak wolumetryczny, choć nim nie są. Kernel zakłada wpisy w śledzeniu połączeń (conntrack) także dla ruchu UDP, a przy podrobionych adresach nadawcy każdy nowy adres oznacza nowy wpis. Gdy tablica jest pełna, kernel odrzuca pakiety bez różnicy: atak i twoi gracze wylatują razem. W logu systemowym stoi wtedy nf_conntrack: table full, dropping packet.

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack

Najskuteczniejszym krokiem jest w ogóle nie pozwolić śledzić ruchu Unturned. Gra zarządza swoimi sesjami sama i nie potrzebuje śledzenia stanu w kernelu:

iptables -t raw -A PREROUTING -p udp --dport 27015 -j NOTRACK
iptables -t raw -A PREROUTING -p udp --dport 27016 -j NOTRACK

Zwróć uwagę, że twoje otwarcia dla tych dwóch portów nie mogą wtedy iść już przez ESTABLISHED,RELATED, tylko muszą stać jako własne reguły przyjmujące. Dopiero potem opłaca się podnosić nf_conntrack_max. Kto najpierw powiększa tablicę, przesuwa problem tylko o minuty i zużywa na to pamięć operacyjną.

Jeśli pakiety przychodzą szybciej, niż proces serwera je odbiera, przepełnia się dodatkowo bufor odbiorczy gniazda. Dla graczy wygląda to jak utrata pakietów, choć łącze jest wolne:

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

Zapisz te wartości pod /etc/sysctl.d/ i aktywuj je przez sysctl --system. Czy są potrzebne, zdradzi kernel: jeśli UdpRcvbufErrors w nstat -az rośnie albo w ss -lunp stale coś stoi w kolejce odbiorczej, to działają. Jeśli oba zostają na zerze, ta zmiana niczego nie zmienia. To rezerwa, a nie ochrona.

6. Zalew dołączeń, kolejka i whitelista

Zalew dołączeń to atak, w którym atakujący wykorzystuje zwykłą drogę dołączania, żeby zużyć miejsca i czas procesora, zamiast zapełniać łącze. Unturned przynosi przeciw temu cztery narzędzia, wszystkie stojące w Commands.dat:

• Queue_Size 32 ustawia kolejkę. Domyślnie jest to 8 miejsc, maksimum to 64. Za duża kolejka pomaga atakującemu, za mała odrzuca prawdziwych graczy przy każdym restarcie.
• Whitelisted przełącza serwer na listę dostępu. Wpisuje się przez konsolę poleceniem permit <SteamID64>, usuwa przez unpermit <SteamID64>.
• Password TwojeHaslo wyklucza wszystko, co ma adres wyłącznie z listy.
• Filter odrzuca graczy z niedozwolonymi znakami w nazwie, a MaxPlayers 24 trzyma liczbę miejsc na poziomie, który sprzęt faktycznie uniesie.

Whitelista chroni twoją logikę gry, a nie twoje łącze. 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.

7. RocketMod, OpenMod i strona pluginów

Unturned ma dwie rozpowszechnione platformy pluginów i obie działają w tym samym procesie co serwer. RocketMod jest starszą: pierwotni opiekunowie zakończyli jego utrzymanie 20 grudnia 2019 i udostępnili kod źródłowy na licencji MIT. Smartly Dressed Games utrzymuje od tego czasu odgałęzienie Legally Distinct Missile (LDM), które jest już dołączane do serwera dedykowanego: kopiuje się Rocket.Unturned z folderu Extras do folderu Modules. Twórcy wyraźnie zalecają to odgałęzienie, bo naprawia stare problemy Rocketa, takie jak błędy wątkowania i exploity teleportacji.

OpenMod jest nowszym następcą, rozwijanym przez jednego z pierwotnych opiekunów Rocketa. Nie zastępuje RocketModa, tylko działa obok niego i może przez integrację korzystać z istniejących pluginów Rocketa. Dla obrony znaczy to dwie rzeczy.

Po pierwsze: każdy plugin jest powierzchnią ataku w głównym procesie. Plugin, który przy każdej wiadomości na czacie albo przy każdym zdarzeniu w grze wywołuje zapytanie do bazy danych, jest samodzielnie zbudowanym odmówieniem usługi. Pojedynczy gracz, który wyzwala zdarzenie w pętli, kładzie wtedy serwer bez jakiejkolwiek przepustowości. Trzymaj listę pluginów krótką, wybieraj pluginy z otwartym kodem i mierz liczbę klatek serwera po każdym rozszerzeniu.

Po drugie: ponieważ Unturned nie ma własnego portu RCON, każde zdalne sterowanie pochodzi z pluginu. Sprawdź po instalacji przez ss -lntp, jaki port TCP został otwarty, i ogranicz go do swojego własnego adresu. Otwarty port zdalnego sterowania ze słabym hasłem to nie problem DDoS, tylko problem przejęcia serwera.

8. Zawartość z Warsztatu i proces dołączania

Zawartość z Warsztatu Steam czyni dołączanie kosztownym, a to wpływa wprost na podatność na atak. Steruje się tym przez WorkshopDownloadConfig.json w tym samym folderze Server:

{
    "File_IDs": [],
    "Ignore_Children_File_IDs": [],
    "Query_Cache_Max_Age_Seconds": 600,
    "Max_Query_Retries": 2,
    "Use_Cached_Downloads": true,
    "Should_Monitor_Updates": true,
    "Shutdown_Update_Detected_Timer": 600
}

W File_IDs stoją identyfikatory map i modów z Warsztatu. Przy starcie serwer pobiera je razem z zależnościami, a każdy gracz dociąga je automatycznie przy łączeniu. Powinieneś znać trzy tego skutki. Po pierwsze przy dużych listach modów dołączanie trwa długo, a po ataku wszyscy gracze wracają jednocześnie, co obciąża serwer po raz drugi. Po drugie Should_Monitor_Updates zatrzymuje serwer, gdy tylko plik z Warsztatu zostanie zaktualizowany: domyślny Shutdown_Update_Detected_Timer wynoszący 600 sekund prowadzi wtedy do restartu, który operatorzy w trakcie ataku regularnie biorą za sukces atakującego. Po trzecie każdy mod jest obcym kodem na twoim serwerze.

Praktycznie znaczy to: trzymaj listę tak krótką, jak to możliwe, po każdym nieoczekiwanym restarcie sprawdzaj najpierw log serwera pod kątem komunikatu o aktualizacji z Warsztatu i wyłączaj Should_Monitor_Updates tylko wtedy, gdy planujesz aktualizacje samodzielnie.

9. Lista serwerów, kod serwera i funkcja Fake IP

Twojego adresu IP nie da się utrzymać w tajemnicy, dopóki serwer jest publicznie wylistowany. Zna go każdy gracz, który choć raz się połączył, a listy zewnętrzne i tak go publikują. Dwa nawyki mimo to pomagają: nigdzie nie publikuj surowego adresu samodzielnie i podłączaj graczy przez nazwę hosta, żeby zmiana adresu nie łamała każdego odnośnika. Klasykiem jest zapomniany rekord A wskazujący na stary adres, który unieważnia każdą zmianę.

Do pracy w internecie i tak potrzebujesz Game Server Login Token (GSLT) z zarządzania serwerami Steam dla App-ID 304930. Sprawia on dodatkowo, że kod twojego serwera pozostaje taki sam mimo restartów, zamiast być generowany na nowo przy każdym starcie.

Unturned oferuje poza tym funkcję Fake IP. Włącza się ją przez "Use_FakeIP": true w Config.json, a polecenie konsolowe CopyFakeIP podaje adres, który potem publikujesz. Ruch idzie następnie przez sieć przekaźnikową Steam Datagram Relay, przydzielane adresy leżą w zakresie od 169.254.0.0 do 169.254.255.255, a prawdziwy adres serwera nie jest już graczom pokazywany. Valve opisuje ten ruch jako uwierzytelniony, zaszyfrowany i ograniczony co do tempa.

Cena jest wysoka i rzadko bywa dopowiadana: adres i port zmieniają się przy każdym restarcie, nazwy domeny nie da się na nie skierować bez własnych skryptów, a listy Steam „Ulubione” i „Historia” z tym nie działają, działa tylko funkcja zakładek. Przede wszystkim jednak funkcja chroni wyłącznie drogę gry. Twój serwer zachowuje swój prawdziwy adres, a SSH, panel webowy, baza danych i strona pozostają przez niego osiągalne. Kto zna adres ze starego wpisu DNS, ze strony ze statusem albo z wcześniejszego połączenia, atakuje go nadal bezpośrednio. Funkcja Fake IP nie zastępuje więc filtrowania w sieci przed serwerem, tylko zmniejsza liczbę ludzi, którzy twój adres w ogóle znają.

10. Zapisuj logi, żebyś w trakcie ataku nie musiał zgadywać

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 piątkowy 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 udp portrange 27015-27016 -c 200 -q

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 i odróżnić atak od błędu oprogramowania, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

Gdzie te działania się kończą

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, czyli 125 megabajtów na sekundę, a łącze jest pełne, gdy tylko ktoś wyśle więcej. Normalna praca zostaje daleko poniżej: przy 24 graczach i fabrycznie dozwolonych 50 pakietach na gracza i sekundę przychodzi około 1200 pakietów na sekundę. Usługa typu booter generuje bez żadnego przygotowania wielokrotność tej liczby.

Druga wielkość to liczba pakietów i uderza ona prawie zawsze 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 CPU 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”.

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

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, 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 we własnej sieci. Po twojej stronie nie trzeba niczego przebudowywać.
• Samodzielnie zarządzane reguły ochrony na port i protokół w panelu klienta: osobno ustawiasz, co jest dozwolone na 27015 UDP (zapytania), a co na 27016 UDP (ruch gry), bez pisania zgłoszenia.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku, na przykład zacieśnić zapytania i zostawić ruch gry nietknięty.
• Profil ochrony dopasowany do gry, tak samo dla zmodyfikowanych i własnych aplikacji na dowolnych portach TCP albo UDP, czyli także dla pluginu z własnym portem.

Porównanie obu wariantów

Dla większości projektów Unturned 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 i ich rozwiązania

„Moja instrukcja mówi, że muszę otworzyć porty od 27015 do 27017”: ta instrukcja jest starsza niż listopad 2021. Od wersji 3.21.30.0 serwer Unturned potrzebuje już tylko dwóch portów, bo zapytanie Steam nie leży dłużej na porcie plus dwa. Zamknij 27017, chyba że działa tam druga instancja.

„Serwer działa, ale nie ma go na żadnej liście serwerów”: to typowy obraz zalewu zapytaniami albo zbyt ostrej własnej reguły na 27015 UDP. Sprawdź przez iptables -L INPUT -n -v, czy twoja własna reguła liczy trafienia. Jeśli liczniki rosną mocno, właśnie odfiltrowujesz własne wpisy na listach. Nigdy nie blokuj 27015 całkowicie.

„Wszyscy gracze wylatują naraz z przekroczeniem czasu”: sprawdź najpierw, czy nie przepełniło się śledzenie połączeń (dmesg -T | grep -i conntrack). Gdy tablica jest pełna, kernel odrzuca bez różnicy. Timeout_Game_Seconds stoi fabrycznie na 30 sekundach: kto wróci w tym czasie, zachowa swoje miejsce.

„Serwer restartuje się w środku pracy”: to rzadko atak. Sprawdź w logu komunikat o wykrytej aktualizacji z Warsztatu. Should_Monitor_Updates wyłącza serwer po domyślnym czasie 600 sekund.

„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, zwykle z listy serwerów, z bota Discord albo ze starego wpisu DNS. Zmiana adresu to zysk na czasie, a nie rozwiązanie.

„Włączyłem funkcję Fake IP i mimo to jestem atakowany”: ukrywa ona adres przed nowymi graczami, ale nie odbiera go serwerowi. Kto zna go ze starego wpisu na liście, ze strony ze statusem albo z wcześniejszego połączenia, dociera do twojego serwera nadal bezpośrednio, tak samo do SSH i każdego panelu webowego na nim.

„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 Unturned potrzebuje dokładnie dwóch otwartych portów UDP: wartości Port ustawionej w Commands.dat (domyślnie 27015) i tej wartości plus jeden (27016). TCP sama gra nie potrzebuje.
• Port 27017 jest zbędny od wersji 3.21.30.0 z 21 listopada 2021, bo zapytanie Steam nie leży już na porcie plus dwa. Kto ma go wciąż otwarty, idzie za przestarzałą instrukcją.
• Unturned nie ma wbudowanego portu RCON. Każde zdalne sterowanie pochodzi z pluginu, przynosi własny port TCP i musi zostać ograniczone przez ciebie samego.
• Port zapytań 27015 jest najczulszym punktem: zalew zapytaniami czyni serwer niewidocznym na liście serwerów, nie trafiając w ani jednego gracza, a protokół Steam ma według US-CERT TA14-017A współczynnik wzmocnienia 5,5.
• Granice w Config.json (Max_Packets_Per_Second 50,0, Rate_Limit_Kick_Threshold 10 na 40 sekund) działają tylko przeciw klientom, którzy naprawdę dołączają, a nie przeciw podrobionym adresom nadawcy.
• Łącze 1 Gbit/s jest pełne przy 125 megabajtach na sekundę, a przy pakietach wielkości 64 bajtów już przy około 1,49 miliona pakietów na sekundę. Normalna praca z 24 graczami leży przy około 1200 pakietach na sekundę. O wszystkim powyżej decyduje sieć przed serwerem, a nie twój firewall.
• 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. Kto chce sam sterować regułami filtrowania, dobiera Advanced DDoS Protection od 50,00 € miesięcznie.

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.