Ochrona serwera RAGE MP i alt:V przed atakami DDoS

Serwer multiplayer do GTA to dla atakującego wdzięczny cel: wisi na jednym adresie IP, jego port stoi na publicznej liście serwerów, a każda przerwa jest od razu widoczna dla wszystkich graczy naraz. Ten artykuł pokazuje najpierw, co naprawdę da się osiągnąć na własnym serwerze, a potem równie wyraźnie, gdzie te możliwości się kończą.

Jeśli nie masz jeszcze pewności, czy w ogóle trwa atak, najpierw to zmierz: wpis Jak rozpoznać atak DDoS opisuje diagnozę krok po kroku. Podstawy techniczne znajdziesz w artykule Czym jest atak DDoS.

Dlaczego akurat RAGE MP i alt:V obrywają tak często

Scena roleplay wokół GTA V jest mała, jawna i mocno konkurencyjna. Serwer żyje ze swoich stałych graczy, a ci przy dłuższych przestojach szybko lądują na innym Discordzie. To właśnie czyni ataki atrakcyjnymi: nie trzeba wygrywać przez wiele godzin, wystarczy kilka minut w najlepszej porze grania, w wieczór otwarcia albo w trakcie zapowiedzianego wipe'u.

Do tego nikt nie musi długo szukać. Obie platformy na życzenie zgłaszają twój serwer na publiczną listę serwerów: RAGE MP przez announce w conf.json, a alt:V przez announce oraz token w server.toml. Kto tam trafi, ten publikuje razem z wpisem swój adres IP i port. Świeżo zgłoszony serwer dostaje więc pierwsze automatyczne próby połączenia często już w ciągu pierwszej godziny, na długo przed pojawieniem się pierwszego prawdziwego gracza.

Trzeci powód jest natury technicznej: ruch gry idzie przez UDP. UDP nie zna nawiązywania połączenia, na które nadawca musiałby poczekać, więc adres nadawcy da się bez trudu sfałszować. Kto zna twój port, może go ostrzeliwać, nigdy nie dostając odpowiedzi i nie pokazując własnego adresu.

Porty, o które chodzi

Zanim napiszesz pierwszą regułę, powinieneś wiedzieć, który port do czego służy. Obie platformy potrzebują więcej niż jednego.

Ważne są przy tym dwie właściwości. W RAGE MP port HTTP jest na sztywno powiązany z portem gry i zawsze jest o jeden wyższy: przesuniesz port gry na 22015, a port plików przejdzie razem z nim na 22016. W alt:V ruch gry i dostarczanie plików dzielą ten sam numer portu, raz przez UDP, raz przez TCP. Kto oddaje pliki klienta sieci dostarczania treści (opcje useCdn oraz cdnUrl w server.toml), ten zdejmuje część TCP z własnego łącza. Ruchu gry przez UDP to nie dotyczy.

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

Poniższe kroki nie zatrzymają ataku wolumetrycznego, bo nie potrafi tego żadne oprogramowanie na serwerze. Sprzątają jednak wszystko, co leży poniżej: skanowanie portów, zalewanie połączeniami z kilku źródeł, ataki na bazę danych zamiast na samą grę oraz nadużywanie twojego własnego portu plików. To większość tego, co na co dzień przeszkadza małemu serwerowi, a kosztuje tylko pół godziny.

Krok 1: inwentaryzacja, co nasłuchuje na zewnątrz

ss -tulnp

Interesująca jest kolumna z adresem lokalnym. Wszystko, co stoi tam na 0.0.0.0 albo [::], jest osiągalne z internetu, a wszystko na 127.0.0.1 tylko lokalnie. Na typowym serwerze roleplay obok samej gry szybko znajdzie się baza danych, cache, panel WWW, a czasem serwer głosowy. Każda z tych usług to osobna powierzchnia ataku i żadna z nich nie musi być otwarta tylko dlatego, że działa.

Krok 2: ograniczenie firewalla do faktycznie potrzebnych portów

Dla serwera RAGE MP są to trzy reguły wpuszczające: SSH, port gry i port plików. W każdym przypadku dopuść najpierw swój port SSH, inaczej ostatnia linia zamknie dostęp tobie samemu:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 22005/udp
ufw allow 22006/tcp
ufw enable

Dla alt:V obie reguły dotyczące gry wyglądają zamiast tego tak:

ufw allow 7788/udp
ufw allow 7788/tcp

Sprawdź potem poleceniem ufw status verbose, czy naprawdę otwarte są tylko te porty, i powtórz ss -tulnp. Pełną konfigurację razem z IPv6 oraz typowymi pułapkami odcięcia sobie dostępu opisuje wpis Konfiguracja firewalla UFW.

Krok 3: odcięcie bazy danych i cache'u od sieci

W większości gamemodów MariaDB i Redis działają na tej samej maszynie co serwer gry i nie potrzebują wtedy żadnego adresu w internecie. Do konfiguracji MariaDB (na Debianie i Ubuntu /etc/mysql/mariadb.conf.d/50-server.cnf) należy dopisać linię:

bind-address = 127.0.0.1

A do /etc/redis/redis.conf:

bind 127.0.0.1 ::1
protected-mode yes

Potem zrestartuj obie usługi i sprawdź wynik poleceniem ss -tulnp. Otwarty cache bez hasła to nie problem DDoS, tylko droga włamania, a skanowany jest przez całą dobę.

Krok 4: ograniczenie tempa połączeń na porcie plików

Port TCP dla plików klienta to miejsce, w którym ograniczenie tempa na serwerze rzeczywiście ma sens, bo tutaj połączenie jest naprawdę nawiązywane, a więc istnieje adres nadawcy, któremu można w miarę ufać. Wystarczą dwie reguły, tutaj dla RAGE MP na porcie 22006:

iptables -A INPUT -p tcp --dport 22006 --syn -m connlimit --connlimit-above 20 --connlimit-mask 32 -j DROP
iptables -A INPUT -p tcp --dport 22006 --syn -m hashlimit --hashlimit-name gtahttp --hashlimit-mode srcip --hashlimit-above 30/sec --hashlimit-burst 60 -j DROP

Pierwsza reguła ogranicza liczbę jednocześnie otwartych połączeń na jeden adres źródłowy, druga liczbę prób połączenia na sekundę. Dla alt:V w obu miejscach wpisujesz 7788. Trzy uwagi do tego: ufw limit jest tutaj zbyt zgrubny i zna wyłącznie TCP, wartości liczbowe dopasuj do rozmiaru swoich plików klienta, a same reguły przeżyją restart tylko z iptables-persistent albo jako wpis w /etc/ufw/before.rules.

Na porcie gry po UDP ta sama technika daje za to niewiele, bo nadawcy są tam podrobieni: blokada po adresie źródłowym nie trafia wtedy w nikogo poza przypadkowym prawdziwym graczem. Zamiast tego warto mieć na oku śledzenie połączeń w kernelu:

cat /proc/sys/net/netfilter/nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max

Kiedy pierwsza wartość zbliża się do drugiej, kernel odrzuca pakiety niezależnie od tego, czy należą do ataku, czy do gracza. W logu systemowym stoi wtedy nf_conntrack: table full, dropping packet.

Krok 5: wykorzystanie wbudowanych możliwości obu platform

Oba rdzenie serwerowe mają ustawienia pomyślane właśnie przeciwko nadużywaniu połączeń, a fabrycznie stoją na najluźniejszej wartości. W RAGE MP dotyczy to trzech kluczy w conf.json:

{
    "bind": "0.0.0.0",
    "port": 22005,
    "announce": true,
    "maxplayers": 200,
    "disallow-multiple-connections-per-ip": true,
    "limit-time-of-connections-per-ip": 1000,
    "enable-http-security": true
}

To tylko wycinek, pozostałe klucze zostają bez zmian. disallow-multiple-connections-per-ip blokuje kilka równoczesnych połączeń z tego samego adresu, limit-time-of-connections-per-ip wymusza minimalny odstęp między dwiema próbami połączenia (0 wyłącza to ograniczenie), a enable-http-security włącza dodatkowe kontrole wbudowanego serwera HTTP. Jednostkę czasu środkowej wartości porównaj z dokumentacją swojej wersji serwera, zanim ją podniesiesz. I licz się z tym, że pierwsza opcja wyklucza współgraczy siedzących za tym samym łączem, czyli mieszkania współdzielone, rodziny oraz sieci firmowe.

W alt:V odpowiednie opcje stoją w server.toml:

host = '0.0.0.0'
port = 7788
players = 200
announce = true
duplicatePlayers = 4
connectionQueue = true
useEarlyAuth = true

duplicatePlayers ogranicza, ilu graczy z tego samego adresu IP może być połączonych jednocześnie. Wartość domyślna wynosi 4096, więc praktycznie nie jest żadną granicą. connectionQueue ustawia próby połączenia w kolejkę, zamiast obsługiwać je wszystkie naraz. useEarlyAuth stawia przed serwerem gry logowanie: klient musi się zalogować, zanim wejdzie do twojego świata gry, co od razu odsiewa proste zalewanie połączeniami. Adres strony logowania stoi w earlyAuthUrl.

Krok 6: lista dozwolonych, dopóki się pali

Jeśli atak idzie przez mechanikę gry, czyli przez masowe próby połączenia zamiast przez samą przepustowość, lista dozwolonych jest najskuteczniejszym środkiem doraźnym. W alt:V do pracy w trybie zamkniętym wystarczy już password w server.toml. Programowo najprostsza postać wygląda tak, tutaj dla RAGE MP:

const whitelist = new Set(['GraczJeden', 'GraczDwa']);

mp.events.add('playerJoin', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Serwer jest obecnie zamknięty.');
    }
});

I ta sama logika dla alt:V:

import * as alt from 'alt-server';

const whitelist = new Set(['GraczJeden', 'GraczDwa']);

alt.on('playerConnect', (player) => {
    if (!whitelist.has(player.name)) {
        player.kick('Serwer jest obecnie zamknięty.');
    }
});

Oba warianty są celowo proste i mają wyraźną granicę: nazwa wyświetlana nie jest mocnym wyróżnikiem. Kto prowadzi listę dozwolonych na stałe, powinien sprawdzać identyfikator z wcześniejszego logowania albo własną kartotekę kont. Przede wszystkim jednak obowiązuje jedno: wyrzucenie gracza następuje dopiero po tym, jak połączenie dotarło do serwera. Przeciwko pakietom, które już zapychają łącze, nic ono nie da.

Krok 7: wpis na liście serwerów i higiena adresu IP

Wyłączenie wpisu na liście serwerów (announce na false) brzmi jak szybkie rozwiązanie i najczęściej nim nie jest. Kto ma już twój adres IP, dociera do ciebie dalej, a twoi gracze przestają cię znajdować. Ten krok ma sens tylko razem ze zmianą adresu IP, bo dopiero wtedy atakujący traci swój cel.

Na dłuższą metę więcej daje porządek w tych miejscach, w których adres wychodzi na jaw mimochodem: stronę WWW i forum trzymaj na innej maszynie, skasuj stare wpisy DNS (także mail, ftp oraz nazwy testowe z pierwszych dni), botów Discorda i wskaźniki statusu nie uruchamiaj na serwerze gry, serwer głosowy odseparuj. Adresu serwera gry nie da się jednak ukryć całkowicie: ruch gry po UDP musi trafiać bezpośrednio do ciebie, a postawiona z przodu sieć dostarczania treści dla stron WWW nic tu nie zmienia. Pomaga nie zacieranie śladów, tylko adres, za którym stoi filtrowanie.

Krok 8: zbieranie danych pomiarowych, zanim zrobi się poważnie

W sytuacji awaryjnej liczy się to, co potrafisz udokumentować. Przygotuj sobie wcześniej polecenia, którymi w kilka sekund zbierzesz przychodzącą liczbę pakietów oraz stan połączeń:

IF=$(ip -o route get 1.1.1.1 | awk '{print $5}')
A=$(cat /sys/class/net/$IF/statistics/rx_packets) || exit 1; sleep 1; B=$(cat /sys/class/net/$IF/statistics/rx_packets); echo "$((B-A)) pakietów/s przychodzących na $IF"
ss -s

Zanotuj te wartości raz podczas normalnej pracy w szczycie grania, bo bez wartości porównawczej każda liczba w trakcie ataku jest bezwartościowa. Jeśli twój serwer gry działa jako usługa systemd, do kompletu należy journalctl -u <nazwa-usługi> -n 200: zalewanie połączeniami zostawia tam zwykle wyraźny ślad. Jedno ograniczenie trzeba przy tym znać: na serwerze mierzysz tylko to, co przez niego przeszło. Jeśli z przodu stoi filtrowanie, wiarygodna liczba jest na wykresie ruchu w panelu klienta, a nie w /proc.

Gdzie te działania się kończą

Każda reguła na serwerze działa dopiero wtedy, gdy pakiet już przyszedł. To zdanie jest rozstrzygające. Firewall decyduje o pakietach, które przeszły już przez twoje łącze, a właśnie to łącze jest celem ataku wolumetrycznego.

Rzędy wielkości wyglądają tak: pojedynczy serwer wisi zwykle na łączu 1 Gbit/s. Przy najmniejszych pakietach odpowiada to mniej więcej 1,5 miliona pakietów na sekundę, więcej fizycznie się nie zmieści. Żeby zapchać takie łącze, nikomu nie jest potrzebny rekordowy atak, wystarczy 2 do 5 Gbit/s. Dla porównania rzeczywiście zmierzony atak z frankfurckiej sieci KernelHost: ponad 473,4 Gbit/s i ponad 41,5 miliona pakietów na sekundę na jedną usługę. To około 470-krotność łącza gigabitowego, a nawet od łącza 10 Gbit/s dzieli to współczynnik 47.

Kiedy łącze jest pełne, odrzuca już router stojący przed nim, i to bez oglądania się na pojedynczy pakiet. Twoi gracze stoją wtedy w tej samej kolejce co atak. Nic tu nie zmieni ani iptables, ani plugin, ani mocniejszy CPU, bo wąskie gardło leży przed serwerem. Do tego przy zalewaniu po UDP adresy nadawców są podrobione: po prostu nie ma nikogo, kogo dałoby się sensownie zablokować.

Skuteczne jest więc wyłącznie filtrowanie, które siedzi w sieci przed twoim łączem i ma tam na tyle dużą pojemność, że atak jej nie wysyci.

Co przeciwstawia temu KernelHost

Stała ochrona, która działa już na każdym serwerze

W KernelHoście (KernelHost GmbH, siedziba w Wiedniu, Austria) na każdym serwerze stale działa dwustopniowa ochrona DDoS, bez zamawiania, bez konfiguracji i bez dopłaty:

• Warstwa 1: globalna sieć scrubbingowa o pojemności mitygacji 17 Tbps. Ataki wolumetryczne są przechwytywane blisko swojego źródła, zanim w ogóle dotrą do centrum danych.
• Warstwa 2: filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps. Stoi ono na miejscu w centrum danych maincubes we Frankfurcie nad Menem (Niemcy) i wykonuje bezpośrednio przed twoim serwerem robotę precyzyjną, pakiet po pakiecie.

Równie ważne jest to, czego nie ma: nie stosujemy null-routingu. Twój adres IP pozostaje podczas ataku w sieci, odpadają wyłącznie szkodliwe pakiety. Dla serwera roleplay ta różnica jest zasadnicza, bo adres wycięty null-routingiem jest dla twoich graczy nie do odróżnienia od udanego ataku. Gdyby w trakcie zdarzenia przestało przechodzić SSH, do systemu dostaniesz się dalej przez konsolę VNC w panelu klienta, która działa niezależnie od podłączenia serwera do sieci.

Advanced DDoS Protection dla projektów atakowanych bez przerwy

Niektóre projekty obrywają nie raz, tylko całymi tygodniami. Na taki przypadek jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid i bez minimalnego okresu, bez okresu wypowiedzenia, bez umowy oraz bez opłaty aktywacyjnej. W pakiecie są:

• dedykowany chroniony adres IP z frankfurckiego rdzenia sieci, na który przełączany jest twój serwer, bez przebudowy po twojej stronie,
• reguły ochrony, którymi zarządzasz samodzielnie, dla każdego portu i protokołu, bezpośrednio w panelu klienta,
• zmiany działające w czasie rzeczywistym, bez zgłoszenia i bez czekania,
• profil ochrony dopasowany do konkretnej gry, z ponad 40 profili dla gier, usług i protokołów, w tym RageMP oraz alt:V, a do tego profile ogólne dla własnych aplikacji TCP i UDP.

Praktyczna różnica leży w kontroli: sam decydujesz, który profil działa na 22005 UDP i która reguła obowiązuje dla 22006 TCP, także w środku trwającego ataku.

Porównanie obu poziomów

Typowe błędy i ich rozwiązania

Wszystkie porty otwarte, bo inaczej coś tam nie działa: to prawie zawsze błędna diagnoza. Wypisz sobie poleceniem ss -tulnp, która usługa jakiego portu potrzebuje, i otwórz dokładnie te. Jeśli potem czegoś brakuje, przyczyną jest zwykle usługa, która i tak jest przypisana tylko lokalnie.

Blokowanie adresów IP atakujących: przy zalewaniu po UDP nadawcy są podrobieni. Blokujesz w ten sposób adresy postronne, a w najgorszym razie własnych graczy. Ma to sens tylko przy połączeniach TCP z pełnym nawiązaniem połączenia, czyli na porcie plików.

Ustawione tylko announce na false: serwer znika z listy, ale adres IP zostaje ten sam. Trwający atak leci dalej bez zmian, tyle że twoi gracze przestają serwer znajdować. Bez zmiany adresu ten krok nic nie daje.

Ograniczenie tempa na porcie gry po UDP: sieci komórkowe i łącza firmowe skupiają wielu graczy za jednym adresem. Ograniczenie na adres źródłowy wyrzuca tam prawdziwych graczy, podczas gdy podrobieni nadawcy zalewu pozostają nietknięci.

Więcej CPU i więcej pamięci RAM jako odpowiedź na DDoS: jedno i drugie pomaga na przeciążony gamemode, a nie na zapchane łącze. Wąskie gardło leży przed serwerem, a tam mocniejszy sprzęt nic nie zmienia.

Restart w środku ataku: kasuje wszystkie liczniki, które byłyby potrzebne do wiarygodnego zgłoszenia, a atak leci potem dalej bez zmian. Najpierw zbierz dane pomiarowe, dopiero potem działaj.

Baza danych otwarta w internecie, bo panel WWW działa na innej maszynie: poprowadź to połączenie przez tunel SSH albo przez sieć prywatną. Jeśli się nie da, ogranicz dostęp przynajmniej do tego jednego adresu źródłowego, który naprawdę go potrzebuje.

Kiedy atak trwa właśnie teraz

Zbierz najpierw dane pomiarowe z kroku 8, żeby twoje zgłoszenie było wiarygodne: moment zdarzenia ze strefą czasową, adres IP oraz port, których sprawa dotyczy, zmierzoną liczbę pakietów z podaniem kierunku. Potem załóż zgłoszenie wsparcia. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883. Niezależny od dostawcy przegląd dalszych kroków daje wpis Jak chronić serwer przed atakami DDoS.