Ochrona serwera Terraria przed atakami DDoS

Kto chce chronić swój serwer Terraria przed atakami DDoS, ma do czynienia z przypadkiem szczególnym: Terraria mówi wyłącznie przez TCP. Ruch gry idzie przez dokładnie jeden port, 7777 TCP, a portu UDP gra w ogóle nie otwiera. Prawie wszystkie porady krążące w sieci na temat ochrony serwerów gier są napisane dla gier opartych na UDP i albo trafiają tu w próżnię, albo działają w niewłaściwym miejscu.

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 wtedy wydarzyć się w sieci przed serwerem. Wszystkie informacje dotyczą serwera dedykowanego Terraria (vanilla, TShock albo tModLoader) 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 najpierw niczego w konfiguracji i nie restartuj serwera: zabezpiecz pomiary (patrz rozdział „Zapisuj logi”), po ataku już ich nie będzie.

Dlaczego akurat serwery Terraria obrywają atakami DDoS

Serwery Terraria są wygodnym celem, bo ich adres siłą rzeczy jest publiczny. Vanilla Terraria nie ma wbudowanej przeglądarki serwerów: gracze łączą się przez „Multiplayer” i „Join via IP”, czyli przez adres, który ktoś musiał wcześniej podać do wiadomości. Kto chce nowych graczy, wpisuje serwer na stronach z listami, takich jak terraria-servers.com, tserverweb.com albo topg.org, albo rozsyła adres przez Discorda. Każda z tych dróg daje atakującemu dokładnie to samo, co daje graczowi: adres IP i port otwartym tekstem.

Jeśli serwer Terraria ciągle przechodzi w offline, choć nic nie zmieniło się ani w sprzęcie, ani w świecie, ani na liście modów, atak jest najbardziej prawdopodobnym wyjaśnieniem. Do tego dochodzi typowa konstelacja projektu: stałe pory gry, konkurencyjne serwery, zbanowani gracze i konflikty w społeczności. Atak nie kosztuje zlecającego ani umiejętności, ani liczących się pieniędzy, a Terraria Server Booter sprzedaje się jako abonament za kilka euro miesięcznie. Czym atak DDoS jest technicznie i jak się go buduje, wyjaśnia wpis Czym jest atak DDoS?.

Terraria działa przez TCP, a nie przez UDP

To najważniejsza różnica wobec praktycznie każdego innego serwera gier. Serwer dedykowany Terraria przyjmuje połączenia listenerem TCP (w silniku gry jest to klasa Terraria.Net.Sockets.TcpSocket) i nie otwiera żadnego gniazda UDP. Ma to cztery następstwa, które określają całą twoją obronę:

• W pełni nawiązanego połączenia TCP nie da się podrobić. Atakujący musi odebrać pakiet SYN-ACK serwera, żeby zakończyć handshake. Kto jest więc naprawdę połączony, przychodzi z prawdziwego adresu. Blokady adresów IP i górne limity połączeń działają przy Terrarii dlatego wyraźnie lepiej niż przy grze opartej na UDP.
• Flood SYN da się natomiast jak najbardziej podrobić, bo nigdy nie kończy handshake'u. Przeciw tej odmianie nie pomoże żadna blokada adresu, tylko wyłącznie SYN cookies oraz filtrowanie przed serwerem.
• Każde przyjęte połączenie TCP do portu 7777 zajmuje zasoby w procesie gry, a nie tylko w kernelu. To czyni wyczerpanie slotów najskuteczniejszym atakiem przy najmniejszej przepustowości.
• Flood UDP i tak trafia w twój serwer. Pakiety nie muszą zostać przyjęte, żeby zapełnić twoje łącze. To, że Terraria nie mówi przez UDP, nie chroni łącza, zapobiega tylko temu, że sam proces gry te pakiety przetwarza.

Jest jeden wyjątek: jeśli uruchomisz serwer dedykowany z -steam oraz -lobby friends albo -lobby private, połączenie idzie przez sieć Steam, a tym samym przez porty UDP w zakresie od 27000 do 27100. To inny tryb pracy, a nie klasyczny serwer osiągalny przez adres IP.

Porty, o które naprawdę chodzi

Serwer Terraria potrzebuje w otwartej sieci dokładnie jednego portu: 7777 TCP. Wszystko inne z tej tabeli albo w ogóle nie należy do internetu, albo tylko do twojego własnego adresu.

To, że Terraria nie zna ani portu zapytań, ani RCON, jest dla zabezpieczenia dobrą wiadomością: dwa punkty końcowe, które przy Counter-Strike, Rust albo ARK regularnie bywają nadużywane do ataków typu reflection, tutaj po prostu nie istnieją. Za to powierzchnia ataku jest tym mocniej skupiona na porcie 7777, a kto używa TShocka, dokłada sobie z portem 7878 drugą powierzchnię.

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

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer Terraria 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?

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:7777 oznacza „osiągalny z całego internetu”, 127.0.0.1:7878 oznacza „tylko lokalnie” i nie potrzebuje żadnej reguły firewalla. Jeśli na tej liście pojawia się wpis UDP dla twojego procesu Terrarii, serwer działa w trybie Steam. Spojrzenie oczami atakującego daje skan portów z zewnątrz:

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

2. Zostaw otwarte tylko 7777 TCP, resztę zamknij

Dla Terrarii wystarczy jedno otwarcie na zewnątrz. Reguła UDP nie jest ci potrzebna, a reguła UDP dla 7777 byłaby po prostu błędna: przepuszcza ruch na port, na którym nic nie nasłuchuje. 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 7777/tcp comment 'Terraria'
ufw allow from 203.0.113.10 to any port 7878 proto tcp comment 'TShock REST'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Zamień 203.0.113.10 na swój własny adres. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu. Kto prowadzi panel, ogranicza do własnego adresu także 8080 i 2022.

3. serverconfig.txt: właściwie ustaw hasło, maxplayers i secure

Centralny plik konfiguracyjny serwera Terraria nazywa się serverconfig.txt i przy starcie przekazuje się go przez -config serverconfig.txt. Cztery dyrektywy są decydujące dla zabezpieczenia:

port=7777
maxplayers=16
password=DlugieLosoweHaslo
secure=1
upnp=0
banlist=banlist.txt

password= to najskuteczniejszy darmowy środek przeciw floodom dołączania, które idą zwykłą drogą. Powód leży w protokole: klient wysyła najpierw wiadomość 1 ze swoim oznaczeniem wersji (na przykład Terraria279), serwer przy ustawionym haśle odpowiada wiadomością 37, klient musi poprawnie odpowiedzieć wiadomością 38, i dopiero potem serwer wysyła wiadomością 3 dopuszczenie razem ze slotem gracza. Bez prawidłowego hasła atakujący nigdy nie dojdzie więc do transmisji świata, która jest kosztowną częścią dołączania.

maxplayers przyjmuje wartości od 1 do 255, domyślnie jest to 16 (przed wersją 1.4.0.1 było 8). Górna granica 255 nie jest liczbą przypadkową: Terraria adresuje graczy pojedynczym bajtem. Nie ustawiaj maxplayers wyżej, niż naprawdę potrzebujesz, bo każdy slot jest zasobem, który atakujący może zająć. secure=1 włącza wbudowaną kontrolę cheatów (w wierszu poleceń -secure), a upnp=0 zapobiega temu, żeby serwer na własną rękę otwierał porty na routerze.

4. Zabezpiecz TShock: REST-API na 7878 i flood logowania

TShock to najbardziej rozpowszechnione rozszerzenie serwerowe do Terrarii i razem z REST-API przynosi drugą, pełnoprawną powierzchnię ataku. Leży ona domyślnie na porcie 7878 TCP i jest konfigurowana w tshock/config.json, a więc nie w serverconfig.txt. W stanie fabrycznym jest wyłączona ("RestApiEnabled": false) i dokładnie tak powinna zostać, dopóki nie jest ci potrzebna.

Jeśli jej potrzebujesz, istotne są te wartości:

"RestApiEnabled": true,
"RestApiPort": 7878,
"EnableTokenEndpointAuthentication": true,
"LogRest": true,
"RESTMaximumRequestsPerInterval": 5,
"RESTRequestBucketDecreaseIntervalMinutes": 1

Dwie rzeczy są przy tym ważne. Po pierwsze punkt końcowy /status wydaje bez tokena nazwę serwera, port, liczbę graczy i nazwy graczy, dopóki EnableTokenEndpointAuthentication stoi na false. To wygodne dla stron ze statusem i botów Discord, a zarazem darmowy rekonesans dla każdego atakującego, który chce wiedzieć, kiedy atak się opłaca. Po drugie punkt końcowy /v2/token/create tworzy z nazwy użytkownika i hasła token dostępu, a jest osiągalny z zewnątrz, gdy tylko port 7878 stoi otworem: to atak na odgadnięcie hasła do twojego konta administratora, który przy okazji kosztuje czas procesora. Kubełek z RESTMaximumRequestsPerInterval oraz RESTRequestBucketDecreaseIntervalMinutes to hamuje, ale nie zastępuje reguły firewalla.

Dla samego dostępu do gry działają dalsze wartości TShocka. MaximumLoginAttempts stoi na 3 i wyrzuca gracza po trzech nieudanych próbach. RequireLogin (domyślnie false) wymaga konta od każdego gracza. EnableIPBans (domyślnie true) oraz KickProxyUsers (domyślnie true) są przy grze opartej na TCP szczególnie skuteczne, bo adresu źródłowego nawiązanego połączenia właśnie nie da się podrobić. Przeciw griefingowi, który często bywa zgłaszany jako atak, działają progi TileKillThreshold (60), TilePlaceThreshold (20), TileLiquidThreshold (15) oraz ProjectileThreshold (50), każdy jako liczba akcji na sekundę.

5. Ogranicz połączenia na adres źródłowy i sprawdź SYN cookies

Ponieważ Terraria działa na TCP, najskuteczniejszą lokalną regułą jest górny limit jednoczesnych połączeń na adres źródłowy. Prawdziwy gracz potrzebuje dokładnie jednego:

iptables -I INPUT -p tcp --dport 7777 --syn -m connlimit --connlimit-above 3 --connlimit-mask 32 -j DROP
iptables -I INPUT -p tcp --dport 7777 --syn -m hashlimit --hashlimit-name terraria_syn --hashlimit-mode srcip --hashlimit-above 10/min --hashlimit-burst 20 -j DROP

Pierwsza reguła odrzuca nowe połączenia, gdy jeden adres ma ich otwartych jednocześnie więcej niż trzy. Druga ogranicza tempo prób połączenia z tego samego źródła do dziesięciu na minutę z zapasem 20. Obie liczby to wartości startowe, a nie prawdy objawione: serwer, do którego gracze wchodzą ze wspólnego łącza (mieszkanie współdzielone, sieć szkolna, operator komórkowy), widzi kilku legalnych graczy pod tym samym adresem. Najpierw mierz przez tydzień w normalnej pracy.

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żą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload. Przeciw podrobionym pakietom SYN, które nigdy nie kończą handshake'u, nie pomoże żadna z tych reguł, tylko sam kernel. Sprawdź trzy wartości:

sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.core.somaxconn

net.ipv4.tcp_syncookies musi stać na 1, na Debianie i Ubuntu z reguły już tak jest. SYN cookies rezygnują z kolejki półotwartych połączeń i odtwarzają stan z odpowiedzi klienta, flood SYN trafia więc w próżnię, dopóki łącze nie jest pełne. net.core.somaxconn od Linuksa 5.4 stoi na 4096, a wcześniej na 128: jeśli wartość jest mała, kernel odrzuca gotowe, nawiązane połączenia, zanim proces gry zdąży je w ogóle przyjąć.

6. Zapobiegaj wyczerpaniu slotów: dlaczego skan portów zapełnia twój serwer

Wyczerpanie slotów to najtańszy skuteczny atak na serwer Terraria: atakujący otwiera do portu 7777 tyle połączeń TCP, ile serwer ma slotów dla graczy, i trzyma je otwarte. Nie kosztuje go to prawie żadnej przepustowości, ale zapełnia serwer. Prawdziwi gracze widzą „Server is full” i już nie wchodzą, choć na twoim łączu nie dzieje się nic nietypowego. Dokładnie dlatego operatorzy przy Terrarii często nie zauważają, że są atakowani.

Przyczyna leży w sposobie liczenia: połączenie zostaje przyjęte, zanim klient w ogóle wyśle swoje oznaczenie wersji. Historycznie takie połączenia widma pozostawały zajęte, dopóki nie wygasła sesja TCP. Seria 1.4.5 to złagodziła, tam dla klientów, którzy od razu się rozłączają, nie są już rezerwowane sloty. W pierwszych wydaniach 1.4.5.7 oraz 1.4.5.8 serwer dedykowany wywracał się jednak z nieobsłużonym wyjątkiem ObjectDisposedException, gdy tylko połączenie TCP zostało otwarte, a handshake nie został zakończony. Wystarczyło nc -z albo sprawdzenie dostępności przez monitoring. Błąd został po cichu naprawiony w ciągu kilku tygodni, w starszych obrazach kontenerów częściowo jeszcze siedzi. Trzymaj więc wersję swojego serwera aktualną, to nie jest tu frazes, tylko konkretna kwestia dostępności.

Dodatkowo pomagają dwa ustawienia. Kto używa TShocka, ustawia MaxSlots na pożądaną liczbę graczy, a maxplayers w serverconfig.txt o dwa miejsca wyżej: wtedy TShock odrzuca nadmiarowe połączenia czytelnym komunikatem, zamiast żeby proces gry wpuszczał je w ostatnią wolną lukę. A górny limit połączeń z poprzedniego rozdziału to dokładnie ta reguła, która przeszkadza pojedynczemu adresowi zająć wszystkie sloty naraz.

7. Wyłącz UPnP i nie publikuj adresu samodzielnie

Serwer Terraria domyślnie próbuje otworzyć swój port na routerze przez UPnP. Na wynajętym serwerze jest to bez efektu, w sieci domowej otwiera porty, o których później już nic nie wiesz. Wyłącz to przez upnp=0 w serverconfig.txt albo przez -noupnp w wierszu poleceń.

Poza tym opłaca się tu szczerość zamiast myślenia życzeniowego: twojego adresu IP nie da się utrzymać w tajemnicy. Zna go każdy gracz, który choć raz się połączył, a wpis na stronie z listą serwerów i tak go publikuje. Skuteczne są dwa nawyki. Nigdzie nie publikuj surowego adresu IP samodzielnie, tylko podłączaj graczy przez nazwę hosta: klient Terrarii rozwiązuje nazwę hosta, możesz więc w razie potrzeby zmienić adres bez łamania wszystkich odnośników. I usuwaj stare wpisy DNS, bo zapomniany rekord A wskazujący na poprzedni adres unieważnia każdą zmianę.

8. Buforuj zapytania o status zamiast przepuszczać je dalej

Ponieważ Terraria nie ma protokołu zapytań, strony ze statusem, boty Discord i strony z listami serwerów ustalają stan twojego serwera na jeden z dwóch sposobów: albo budują prawdziwe połączenie TCP do 7777 i podają się za klienta, albo odpytują REST-API TShocka. Jedno i drugie kosztuje twój serwer pracę, i jedno, i drugie skaluje się z liczbą odpytujących.

Środek zaradczy nic nie kosztuje: nigdy nie odpytuj z przeglądarki odwiedzającego. Niech jedna usługa pobiera status w stałych odstępach (30 albo 60 sekund wystarczy), buforuj wynik i wydawaj wszystkim odwiedzającym stan z bufora. Dzięki temu popularna strona ze statusem generuje jedno zapytanie na interwał zamiast jednego na odwiedzającego. Kto używa do tego REST-API, ogranicza port 7878 do adresu tej jednej usługi.

9. Zapisuj logi, żeby w razie ataku mieć dane

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 wystarczy pięć poleceń:

sar -n DEV 1 10
ss -s
ss -tn state syn-recv | wc -l
ip -s link show eth0
tcpdump -ni eth0 tcp port 7777 -c 200 -q

Trzecie polecenie jest tym specyficznym dla Terrarii: liczy półotwarte połączenia. Wartość dwucyfrowa jest normalna, cztero- albo pięciocyfrowa to flood SYN. ss -s pokazuje obok tego łączną liczbę połączeń TCP, a jeśli ta liczba odpowiada mniej więcej twojemu maxplayers, podczas gdy w grze nie ma nikogo, widzisz wyczerpanie slotów. 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ą

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, czyli 125 megabajtach na sekundę, a łącze jest pełne, gdy tylko ktoś wyśle więcej. Ataki na projekty serwerowe tej wielkości mieszczą się zwykle między 5 a 50 Gbit/s, czyli od pięciu do pięćdziesięciu razy powyżej pojemności twojego łącza. To, czy twoja reguła connlimit za tym łączem jest dobra, nie ma już wtedy znaczenia, bo pakiety twoich graczy nie przechodzą już wcześniej. Dokładnie tak powstają skoki lagów na serwerze Terraria, przy których obciążenie CPU wygląda normalnie.

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 CPU i karty sieciowej, kilkaset tysięcy, zanim zacznie odrzucać. Przy floodzie SYN granica leży jeszcze niżej, bo każdy pakiet SYN wyzwala decyzję o stanie: już kilkadziesiąt tysięcy pakietów SYN na sekundę wystarczy, żeby położyć przyjmowanie połączeń w standardowym Linuksie, na długo zanim łącze będzie pełne. Operatorzy przeżywają to jako „przecież obciążenie wcale nie było wysokie, a i tak wszystko padło”.

A trzeci punkt jest tym, który przy Terrarii najczęściej bywa przeoczony: atakujący nie kieruje się twoim protokołem. Wysyła floody UDP i ruch typu reflection na twój adres, choć na żadnym porcie UDP nic nie nasłuchuje. Twój serwer poprawnie odrzuca te pakiety, ale one zajęły już twoje łącze, a twój serwer Terraria przechodzi w offline, bez tego, żeby choć jeden pakiet dotarł do procesu gry. 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ę 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. Dla Terrarii znaczy to konkretnie: floody SYN i floody połączeń wymierzone w 7777 TCP kończą się tutaj, a nie na twojej karcie sieciowej.

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. Lokalizacją jest 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 frankfurckiego rdzenia sieci, 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: ustawiasz, co jest dozwolone na 7777 TCP, i możesz zamknąć całą resztę, 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ć dozwolone tempo połączeń na adres źródłowy.
• Profil ochrony dopasowany do aplikacji. Dla gier opartych na TCP, takich jak Terraria, oraz dla własnych i zmodyfikowanych aplikacji na dowolnych portach TCP albo UDP istnieją odpowiednie profile.

Porównanie obu stopni

Dla większości projektów Terraria 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 swój serwer obecnie gdzie indziej, nie dostanie ochrony doposażonej z zewnątrz, tylko przez przeprowadzkę do KernelHosta: filtrowanie jest częścią sieci, a nie dodatkiem na serwerze.

Typowe błędy i ich rozwiązania

„Serwer jest pełny, ale nikogo w nim nie ma”: to wyczerpanie slotów. Sprawdź przez ss -tn dst :7777 | wc -l, ile połączeń jest faktycznie otwartych, i porównaj to z listą graczy (konsola serwera: playing). Jeśli liczby się nie zgadzają, sloty zajmują obce połączenia. Środkami zaradczymi są górny limit połączeń na adres źródłowy, hasło serwera oraz aktualna wersja serwera.

„Otworzyłem 7777 UDP i nic to nie zmienia”: zgadza się, bo na 7777 UDP nic nie nasłuchuje. Terraria używa wyłącznie TCP. Otwarcie UDP nie szkodzi bezpośrednio, ale jest niepotrzebnym otwarciem i pewnym znakiem, że skopiowano instrukcję do innej gry.

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

„Gracze wylatują, choć żaden atak nie trwa”: jeśli ustawisz swoją granicę connlimit zbyt ciasno, obrywają gracze siedzący za wspólnymi łączami. Przy TCP dzieje się to szybciej niż przy grach opartych na UDP, bo ponowne połączenie po przerwie od razu tworzy nowe połączenie, podczas gdy stare wisi jeszcze w TIME_WAIT. Zwiększaj wartość stopniowo i obserwuj liczniki trafień.

„Serwer się tnie, a łącze jest spokojne”: to częściej mod albo plugin niż atak. Pod tModLoaderem każdy dodatkowy mod kosztuje czas procesora w tym samym procesie, a świat z wieloma bytami obciąża jeden rdzeń do pełna, bez tego, żeby dotarł choć jeden pakiet za dużo. Jeśli sar -n DEV 1 10 nie pokazuje nic nietypowego, to nie był atak DDoS.

„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 Terraria potrzebuje dokładnie jednego otwartego portu: 7777 TCP. Gra nie otwiera gniazda UDP, nie ma protokołu zapytań ani RCON.
• REST-API TShocka na porcie 7878 TCP jest drugą powierzchnią ataku. Zostaw RestApiEnabled na false albo ogranicz ten port do swojego własnego adresu.
• Hasło serwera w serverconfig.txt to najskuteczniejszy darmowy środek, bo bez poprawnej odpowiedzi na wiadomość 37 atakujący nigdy nie dojdzie do transmisji świata.
• Wyczerpanie slotów jest przy Terrarii najtańszym atakiem: każde przyjęte połączenie TCP do 7777 zajmuje miejsce, całkiem bez znaczącej przepustowości. Działają przeciw temu górny limit na adres źródłowy, hasło oraz aktualna wersja serwera.
• Ponieważ Terraria używa TCP, adresu źródłowego nawiązanego połączenia nie da się podrobić: blokady adresów IP działają tu lepiej niż przy grach opartych na UDP. Przeciw podrobionym floodom SYN pomagają tylko SYN cookies i filtrowanie przed serwerem.
• Flood UDP kładzie twój serwer Terraria, choć nie mówi on przez UDP, bo zapełnia łącze, zanim proces gry cokolwiek zobaczy.
• Mniej więcej od wielkości twojego pasma uplinku decyduje już wyłącznie sieć przed serwerem. W KernelHoście to filtrowanie jest dwuwarstwowe, stale aktywne i zawarte bez dopłat w każdym pakiecie serwerowym.

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.