Jak zabezpieczyć serwer ARK przed atakami DDoS

Klaster ARK rzadko pada w przypadkowym momencie. Kto prowadzi serwer PvP, zna ten schemat: tuż przed upadkiem cudzej bazy serwer robi się nieosiągalny, wszyscy gracze wylatują, a kiedy wraca, jest już po raidzie. Ten artykuł pokazuje najpierw, co możesz ustawić na samym serwerze, potem, gdzie te środki kończą się technicznie, a na końcu, co KernelHost stawia przed serwerem.

Dlaczego akurat ARK jest atakowany tak celowo

W większości gier awaria serwera jest po prostu irytująca. W ARK: Survival Evolved i ARK: Survival Ascended jest posunięciem taktycznym. Straty w grze są trwałe, okno raidu trwa kilka minut, a każda ochrona przed raidem offline działa tylko tak długo, jak długo serwer jest osiągalny. Kto wyłączy obrońców z gry na dziesięć minut, zgarnia surowce i stworzenia. Atak ma więc konkretny zysk i zaplanowany moment, a kiedy raz zadziała, powtarza się.

Do tego dochodzi budowa klastra. Kilka map działa zwykle na tej samej maszynie, za tym samym adresem IP. Atak nie trafia więc w jeden serwer, tylko jednocześnie w The Island, Ragnarok, Aberration i w transfer między nimi. Gracze, którzy zawisną dokładnie w trakcie transferu, w najgorszym razie tracą postać i przedmioty. Co dzieje się technicznie podczas ataku DDoS, opisuje artykuł Czym jest atak DDoS?.

Porty, o które chodzi

ARK przesyła cały ruch gry przez UDP. To właśnie dlatego wiele poradników o firewallu tutaj nie pomaga: otwierają TCP.

Survival Evolved zajmuje dodatkowo port leżący bezpośrednio nad portem gry, bo silnik otwiera tam drugi socket UDP. Survival Ascended tego drugiego portu już nie potrzebuje. Port zapytań odpowiada na pytania o status w formacie Steam (nazwa serwera, mapa, liczba graczy, czas gry) i jest dla atakujących portem najciekawszym.

W klastrze porty przydziela się co dwa, żeby drugi socket nie zderzył się z kolejną instancją: 7777 i 7778 dla pierwszej mapy, 7779 i 7780 dla drugiej, do tego 27015 i 27016 jako porty zapytań.

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

Poniższe kroki nic nie kosztują i działają przeciwko najczęstszym przypadkom: niewielkim ukierunkowanym floodom z kilku źródeł, nadużywanym portom zapytań i próbom przejęcia kontroli przez RCON. Warto je wykonać także wtedy, gdy z przodu pracuje już filtr sieciowy.

1. Otwieraj tylko to, czego klaster naprawdę potrzebuje

Host z ARK ma szybko więcej otwartych portów, niż się wydaje: panel, baza danych, serwer WWW z mapą, do tego instancje gry. Każdy z nich jest celem dla pakietów. Poniższy zestaw reguł nftables dla /etc/nftables.conf przepuszcza to, czego potrzebuje klaster z dwiema mapami, a resztę odrzuca.

#!/usr/sbin/nft -f

flush ruleset

table inet ark {
    set adminips {
        type ipv4_addr
        flags interval
        elements = { 203.0.113.10 }
    }

    set queryflood {
        type ipv4_addr
        size 65535
        flags dynamic,timeout
        timeout 1m
    }

    chain input {
        type filter hook input priority 0; policy drop;

        iif lo accept
        ct state established,related accept
        ct state invalid drop

        ip saddr @adminips tcp dport { 22, 27020 } accept

        udp dport { 7777-7780 } accept

        udp dport { 27015-27016 } add @queryflood { ip saddr limit rate over 10/second burst 20 packets } drop
        udp dport { 27015-27016 } accept

        icmp type echo-request limit rate 5/second accept
        icmpv6 type { echo-request, nd-neighbor-solicit, nd-neighbor-advert, nd-router-solicit, nd-router-advert } accept

        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

Wpisz w adminips swój stały adres IP, zanim załadujesz reguły, inaczej zablokujesz samemu sobie dostęp przez SSH.

nft -c -f /etc/nftables.conf
systemctl enable --now nftables
nft list ruleset

nft -c sprawdza tylko składnię i niczego nie zmienia. Dopiero drugie polecenie ładuje zestaw reguł i sprawia, że przetrwa restart. Kto woli pracować z UFW, znajdzie drogę w artykule Konfiguracja firewalla UFW. Uwaga: flush ruleset kasuje także reguły UFW i Dockera. Jeśli działa u ciebie któreś z tych dwóch, pomiń ten wiersz.

2. Ogranicz port zapytań, zamiast go zamykać

Port zapytań to jedyny port, na którym twój serwer odsyła każdemu obcemu wyraźnie większą odpowiedź, niż było samo zapytanie. Wynikają z tego dwa problemy. Po pierwsze, twój serwer da się wykorzystać jako wzmacniacz: atakujący podszywa się pod adres nadawcy, twój serwer odpowiada obcej ofierze, a twoje łącze niesie ruch wychodzący. Po drugie, każda odpowiedź kosztuje czas procesora w dokładnie tym samym procesie, który liczy grę. Flood na 27015 objawia się dlatego często przycinaniem, a nie zerwaniem połączenia.

Zamknięcie portu nie jest rozwiązaniem, bo wtedy serwer znika z listy serwerów. Reguła powyżej ogranicza zamiast tego ruch osobno dla każdego adresu źródłowego: dziesięć zapytań na sekundę z buforem dwudziestu pakietów wystarcza graczom i monitoringowi, a źródło z tysiącami zapytań na sekundę zostaje odrzucone. Które adresy są właśnie ograniczane, pokaże:

nft list set inet ark queryflood

3. Wyjmij RCON z internetu

RCON daje pełną kontrolę: kto zna hasło, wyrzuca graczy, zatrzymuje serwer i ingeruje w świat gry. Port działa po TCP, hasło stoi w konfiguracji otwartym tekstem, a logowanie można próbować dowolną liczbę razy. Dlatego w zestawie reguł powyżej jest otwarty wyłącznie dla adresu administratora.

[ServerSettings]
RCONEnabled=True
RCONPort=27020
ServerAdminPassword=<długie losowe hasło>

Plik GameUserSettings.ini leży w katalogu serwera pod ShooterGame/Saved/Config/. Porządne hasło wygeneruje:

openssl rand -base64 24

Jeśli RCON wykorzystuje panel WWW na tej samej maszynie, wystarczy dostęp przez 127.0.0.1, a port pozostaje zamknięty z zewnątrz. Jeśli panel działa gdzie indziej, jego adres wpisujesz do adminips i nigdzie indziej.

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

Flood UDP zabija serwer z Linuksem często nie przepustowością, tylko śledzeniem połączeń. Kernel zakłada wpis dla każdego przychodzącego pakietu UDP, tablica zapełnia się, a potem odrzucane są także pakiety prawdziwych graczy, co poznasz po nf_conntrack: table full, dropping packet w logu systemowym. Ruchowi gry to śledzenie nie daje nic, więc wyjmij porty gry:

table inet arkraw {
    chain prerouting {
        type filter hook prerouting priority -300; policy accept;
        udp dport { 7777-7780, 27015-27016 } notrack
    }

    chain output {
        type filter hook output priority -300; policy accept;
        udp sport { 7777-7780, 27015-27016 } notrack
    }
}

Potrzebne są oba kierunki, inaczej powstaną połowiczne wpisy dla ruchu wychodzącego. Do tego kilka parametrów kernela w /etc/sysctl.d/90-ark.conf:

net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_udp_timeout = 15
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.ipv4.tcp_syncookies = 1

sysctl --system
cat /proc/sys/net/netfilter/nf_conntrack_count

Jeśli druga wartość pnie się podczas ataku ku maksimum, wąskim gardłem było śledzenie połączeń, a nie łącze.

5. Biała lista i hasło serwera

Jeśli twój klaster i tak obsługuje zamkniętą grupę, lista dostępu jest najskuteczniejszym środkiem przeciwko intruzom. ARK ma ją wbudowaną, serwer uruchamiasz w tym celu z -exclusivejoin:

./ShooterGameServer "TheIsland?listen?SessionName=MojKlaster?Port=7777?QueryPort=27015?RCONEnabled=True?RCONPort=27020" -server -log -exclusivejoin

Dozwoleni gracze trafiają wtedy, po jednym identyfikatorze na wiersz, do PlayersExclusiveJoinList.txt w katalogu pliku wykonywalnego serwera. W trakcie pracy listę utrzymujesz przez konsolę serwera albo RCON:

AllowPlayerToJoinNoCheck <identyfikator gracza>
DisallowPlayerToJoinNoCheck <identyfikator gracza>

Hasło serwera ustawione przez ServerPassword działa podobnie, ale z doświadczenia szybko wędruje dalej. Oba rozwiązania mają tę samą twardą granicę: sprawdzenie odbywa się w procesie gry, czyli dopiero po tym, jak pakiet już dotarł. Przeciwko powodzi pakietów biała lista nie pomoże, przeciwko graczowi, który dopiero rozpoznaje twój klaster, jak najbardziej.

6. Co potrafi anti-cheat i pluginy, a czego nie

W obu tytułach fabrycznie działa system anti-cheat, a do tego dochodzą pluginy serwerowe dostępne przez odpowiednie API serwera. Jedno i drugie ma sens, ale rozwiązuje inny problem. Anti-cheat sprawdza, czy podłączony klient jest zmanipulowany, a plugin potrafi liczyć próby połączenia albo rozłączać graczy przy podejrzanym zachowaniu. Wszystkie te kontrole działają w tym samym procesie co gra i wchodzą do akcji dopiero wtedy, gdy pakiet jest przetwarzany. Kiedy proces jest przeciążony, logika ochronna pada razem z nim. Z tego powodu plugin odpierający ataki DDoS po prostu nie może istnieć. Co mimo wszystko pomaga: trzymaj pliki serwera i mody aktualne oraz ogranicz ich liczbę, bo spora część awarii w klastrach ARK to wadliwe mody, a nie ataki.

7. Twój adres stoi na liście serwerów

Publicznie wylistowany serwer ARK ujawnia adres IP i port zapytań, bo inaczej nikt by go nie znalazł, a te listy są bez przerwy automatycznie odpytywane i archiwizowane. Twój adres jest więc znany od chwili, w której serwer raz się na liście pojawił. Ukrywanie się nie wchodzi w grę, bo kto nie listuje, ten nie rośnie. Zostają boczne drogi, którymi adres wycieka dodatkowo:

• Stare wpisy DNS. Rekord A, który wciąż wskazuje na poprzedni serwer, zdradza stary adres. Takie wpisy trzeba usunąć.
• Inne usługi na tym samym adresie. Strona WWW, podgląd mapy, panel, serwer głosowy i baza danych to za każdym razem druga droga, żeby trafić w klaster.
• Własny Discord. Boty statusowe, zrzuty ekranu z konsoli i instrukcje połączenia zawierają adres często otwartym tekstem.

8. Mierz, zamiast zgadywać

Najczęstszym błędem w środku awarii jest zła diagnoza. Mod, który się wysypał, pełny system plików i prawdziwy atak wyglądają dla graczy tak samo. Rozróżnić da się je w minutę. Najpierw liczba pakietów na karcie sieciowej:

r1=$(cat /sys/class/net/eth0/statistics/rx_packets)
sleep 1
r2=$(cat /sys/class/net/eth0/statistics/rx_packets)
echo "$((r2-r1)) pakietów na sekundę"

Klaster z pięćdziesięcioma graczami mieści się normalnie w niskich wartościach pięciocyfrowych, a wartości sześcio- lub siedmiocyfrowe to atak. Potem liczniki stosu sieciowego:

nstat -az UdpInDatagrams UdpNoPorts UdpRcvbufErrors
ss -ulnp | grep -E '7777|27015'

UdpNoPorts rośnie, gdy pakiety trafiają na porty, na których nic nie nasłuchuje, co jest typowym znakiem floodu rozsiewanego na ślepo. UdpRcvbufErrors rośnie, gdy proces serwera nie odbiera pakietów już wystarczająco szybko. Na koniec log gry:

tail -n 200 ShooterGame/Saved/Logs/ShooterGame.log

Jeśli stoi tam raport awarii, a liczniki pakietów niczego nie pokazują, to nie był atak. W trakcie awarii odpuść sobie tcpdump, bo zrzut kosztuje czas procesora na systemie, który akurat go nie ma. Kolejne oznaki wymienia artykuł Jak rozpoznać atak DDoS na serwerze.

Gdzie te środki się kończą

Wszystko opisane dotąd działa na serwerze i dokładnie tam leży granica. Reguła firewalla może odrzucić tylko to, co już dotarło. Wąskie gardło jest jednak przed nim, na łączu.

Liczby są jednoznaczne. Łącze 1 Gbit/s przy najmniejszych możliwych pakietach jest wysycone po około 1,49 miliona pakietów na sekundę, niezależnie od tego, co serwer zamierza z nimi zrobić. Rzeczywisty flood UDP na serwer gry ARK w KernelHoście, port 7777, osiągnął ponad 112,2 Gbit/s i ponad 8,7 miliona pakietów na sekundę, czyli średnio około 1,6 kilobajta na pakiet. To 112-krotność łącza 1 Gbit/s i wciąż ponad jedenastokrotność łącza 10 Gbit/s.

Drugie wąskie gardło również pojawia się szybko: jeden rdzeń CPU odrzuca zwykłym zestawem reguł, zależnie od sprzętu, kilkaset tysięcy pakietów na sekundę. Przy 8,7 miliona ten rachunek nie wychodzi nawet przy wielu rdzeniach. Reguła działa poprawnie, a serwer i tak jest offline.

Ataki wolumetryczne muszą być dlatego filtrowane w sieci przed serwerem. Na samym serwerze tego się nie rozwiąże, ani dokładaniem sprzętu, ani lepszym zestawem reguł.

Co KernelHost stawia przed serwerem

Stała ochrona wliczona w każdy serwer

Na każdym serwerze KernelHost działa dwustopniowa stała ochrona DDoS, bez zamawiania i bez konfiguracji. Pierwszy stopień to globalna sieć scrubbingowa o pojemności mitygacji 17 Tbps: ataki wolumetryczne są przechwytywane blisko źródła, na długo zanim dotrą do centrum danych. Drugi stopień to filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps, bezpośrednio na miejscu w centrum danych maincubes we Frankfurcie nad Menem (Niemcy). Odpowiada za precyzyjne filtrowanie na warstwach 3, 4 i 7 oraz zna wzorce protokołów popularnych serwerów gier.

Decydujące są trzy cechy. Ochrona jest stale aktywna, nie ma więc czasu reakcji, w którym atak trzeba by dopiero wykryć. Nie stosuje się null-routingu, atakowany adres IP zostaje w sieci, a odpadają wyłącznie szkodliwe pakiety. I nie kosztuje nic dodatkowo. Jak to wygląda przy serwerach gier, opisuje artykuł Ochrona DDoS dla serwerów gier w czasie rzeczywistym.

Advanced DDoS Protection dla projektów atakowanych bez przerwy

Niektóre klastry nie obrywają raz, tylko przez całe tygodnie, każdego wieczoru o tej samej porze i za każdym razem innym wzorcem. Dla nich jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid, czyli bez minimalnego okresu umowy, bez okresu wypowiedzenia, bez umowy i bez opłaty aktywacyjnej.

Otrzymujesz dedykowany adres IP z ochroną, pochodzący z frankfurckiego rdzenia sieci. Twój serwer zostaje na niego przełączony w sieci KernelHost, po twojej stronie nic nie trzeba przebudowywać. Różnica leży w tym, co dalej: regułami ochrony zarządzasz sam w panelu klienta, osobno dla portu i protokołu, a zmiany działają w czasie rzeczywistym, bez zgłoszenia. Jako profil ochrony wybierasz tytuł, który obsługuje dany port, a do wyboru jest ponad 40 gier, usług i protokołów, w tym ARK: Survival Evolved. Dla klastra znaczy to tyle: profil gry na porty gry, ciaśniejszy limit na port zapytań, własna reguła dla panelu WWW, zamiast wszędzie tego samego kompromisu.

Porównanie obu stopni

Typowe błędy i ich rozwiązania

Otwarte tylko TCP, serwer działa, ale nikt nie może wejść: ruch gry w ARK idzie po UDP, a reguła dla tcp dport 7777 nic tu nie zmieni. Sprawdź poleceniem ss -ulnp i otwórz porty jako udp dport.

Serwer jest osiągalny, ale nie pojawia się na liście serwerów: najczęściej port zapytań jest zamknięty albo limit jest zbyt ciasny. Otwórz 27015 UDP i podnieś limit. Do kontroli nft list set inet ark queryflood pokaże, które adresy są ograniczane.

Własny bot statusowy zgłasza serwer jako offline, choć są na nim gracze: bot Discorda odpytuje z jednego adresu źródłowego, często wielokrotnie na sekundę i osobno dla każdej mapy, przez co wpada w ten sam limit co atakujący. Umieść wyjątek dla tego adresu przed regułą z limitem.

Po załadowaniu zestawu reguł SSH przestaje działać: w adminips stał zły adres albo SSH słucha na innym porcie. Na serwer wracasz przez konsolę VNC w panelu klienta, bo IPMI ani iDRAC przy serwerach dedykowanych i serwerach root KVM nie ma. Tam uruchom nft flush ruleset jako hamulec bezpieczeństwa, a potem popraw plik.

sysctl nie potrafi ustawić wartości conntrack: parametry pod net.netfilter pojawiają się dopiero wtedy, gdy moduł jest załadowany. Załaduj go poleceniem modprobe nf_conntrack i wywołaj sysctl --system jeszcze raz.

Rzekomy atak okazuje się modem: jeśli liczniki pakietów są normalne, a w ShooterGame.log stoi raport awarii, przyczyną nie była sieć. Po aktualizacji w Workshopie to najbardziej prawdopodobne wyjaśnienie, zwłaszcza gdy dotyczy zawsze tej samej mapy.

Cały klaster przechodzi w offline naraz: wszystkie instancje wiszą na tym samym adresie IP, więc atak trafia we wszystko za jednym razem, łącznie z transferem. Dedykowany adres IP z ochroną rozwiązuje dokładnie ten wzorzec, bo filtrowanie stoi wtedy przed adresem, a nie na serwerze za nim.

Krótkie podsumowanie

Otwórz tylko porty gry, port zapytań i dostęp dla własnego adresu, ogranicz port zapytań osobno dla każdego źródła, trzymaj RCON z dala od internetu i mierz liczbę pakietów, zanim przyjmiesz jakąkolwiek przyczynę. To nic nie kosztuje i pokrywa codzienność. Wszystko, co wykracza poza to, nie rozstrzyga się już na serwerze: wliczona stała ochrona z pojemnością mitygacji 17 Tbps w globalnej sieci scrubbingowej i 3,2 Tbps filtrowania Arbor w czasie rzeczywistym we Frankfurcie nad Menem przechwytuje to bez dopłaty i bez null-routingu. Przy ostrzale trwającym całymi tygodniami Advanced DDoS Protection dokłada dedykowany adres IP z ochroną i reguły ustawiane samodzielnie. Operatorem jest KernelHost GmbH z siedzibą w Wiedniu w Austrii.