Ochrona serwera FiveM przed atakami DDoS

Serwer roleplay FiveM, który wieczorami raz po raz znika na kilka minut, rzadko ma problem ze sprzętem. Zwykle trwa atak, i to dokładnie wtedy, gdy online jest najwięcej graczy. 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ą FXServera 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 najpierw pomiary (patrz rozdział „Zapisuj logi”), po ataku już ich nie będzie.

Dlaczego akurat serwery FiveM są tak często atakowane

Projekty FiveM łączą kilka cech, które czynią z nich wygodny cel. Po pierwsze serwer RP sam publikuje swój adres: wpis na liście serwerów Cfx.re zawiera adres IP i port otwartym tekstem, bo inaczej gracze w ogóle by go nie znaleźli. Po drugie społeczność gra o stałych porach, więc awaria o 20:00 jest widoczna maksymalnie. Po trzecie istnieje konkurencja między projektami, zbanowani gracze i wewnętrzne konflikty, a atak nie kosztuje zlecającego ani umiejętności, ani liczących się pieniędzy.

Technicznie dochodzi do tego fakt, że ruch gry idzie przez UDP. UDP nie zna nawiązywania połączenia, którego można by wymagać, a adresy nadawcy da się podrobić. Atakujący nie musi więc ani wchodzić na twój serwer, ani poprawnie się z nim komunikować, żeby wygenerować obciążenie. Czym dokładnie jest atak DDoS, wyjaśnia wpis Czym jest atak DDoS?.

Porty, o które naprawdę chodzi

FXServer domyślnie nasłuchuje na jednym porcie, i to na obu protokołach. W pliku server.cfg:

endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"

Te dwa wiersze to cała powierzchnia ataku samej gry:

• 30120 UDP niesie bieżący ruch gry: dane o pozycji, synchronizację, transmisję głosu.
• 30120 TCP niesie nawiązywanie połączenia oraz wbudowane punkty końcowe HTTP FXServera: /info.json, /players.json i /dynamic.json.
• 40120 TCP to domyślny port interfejsu webowego txAdmin.
• 3306 TCP należy do bazy danych, której potrzebuje każdy framework ESX albo QBCore.
• 22 TCP to twój dostęp SSH.

Z tych pięciu portów do otwartej sieci należą dokładnie dwa. Pozostałe trzy to najczęstszy możliwy do uniknięcia błąd na serwerach FiveM.

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

Ten rozdział jest najdłuższy i to celowo. Czysto skonfigurowany serwer 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:30120 oraz [::]:30120 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 jeszcze txAdmin, MariaDB, serwer WWW oraz dawno zapomniana usługa głosowa. 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 to, czego gra naprawdę potrzebuje

Dla FiveM wystarczą dwa otwarte porty na zewnątrz, cała reszta zostaje ograniczona albo w ogóle nie trafia do sieci. 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 30120/tcp comment 'FiveM'
ufw allow 30120/udp comment 'FiveM'
ufw allow from 203.0.113.10 to any port 40120 proto tcp comment 'txAdmin'
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. Przy łączu ze zmiennym adresem to niepraktyczne, lepszy sposób opisujemy niżej. Pełną instrukcję razem z drogą ratunkową znajdziesz we wpisie Konfiguracja firewalla UFW bez zamykania sobie dostępu.

Baza danych w żadnym wypadku nie należy do otwartej sieci. Sprawdź w pliku /etc/mysql/mariadb.conf.d/50-server.cnf, czy stoi tam:

bind-address = 127.0.0.1

3. Zabezpiecz port query i punkty końcowe HTTP

FXServer odpowiada na zapytania HTTP na części TCP portu 30120 i nikt nie musi w tym celu uruchamiać gry. Zobacz, co tam wydaje:

curl -s http://127.0.0.1:30120/info.json | head -c 600
curl -s http://127.0.0.1:30120/players.json | head -c 600

/players.json wypisuje podłączonych graczy razem z ich identyfikatorami. To wygodne dla stron ze statusem i botów Discord, ale też zaproszenie: punkt końcowy można odpytywać dowolnie często, każde zapytanie kosztuje twój serwer pracę, a treść zdradza atakującemu, kiedy atak się opłaca. Dwa środki zaradcze nic nie kosztują. Po pierwsze adresy graczy nie mają czego szukać w odpowiedzi, wystarczy do tego jeden wiersz w server.cfg:

sv_endpointPrivacy true

Po drugie: jeśli twój bot na Discordzie albo twoja strona pokazuje liczbę graczy, nie odpytuj punktu końcowego z przeglądarki odwiedzającego, tylko buforuj wynik w stałych odstępach. Dzięki temu popularna strona ze statusem generuje jedno zapytanie na interwał zamiast jednego na odwiedzającego.

4. Nie wystawiaj txAdmin do otwartej sieci

Port 40120 to interfejs webowy z pełnym dostępem do twojego serwera. Bez stałego adresu IP, który mógłbyś wpisać do reguły, zostaw ten port zamknięty z zewnątrz i dostawaj się do niego przez tunel SSH, a potem otwórz lokalnie http://127.0.0.1:40120:

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

5. Ogranicz liczbę połączeń i pakietów

Przeciw małym atakom i niechlujnym botom pomaga górny limit na adres źródłowy:

iptables -I INPUT -p tcp --dport 30120 --syn -m connlimit --connlimit-above 12 --connlimit-mask 32 -j DROP
iptables -I INPUT -p udp --dport 30120 -m hashlimit --hashlimit-name fivem_udp --hashlimit-mode srcip --hashlimit-above 600/sec --hashlimit-burst 900 -j DROP

Pierwsza reguła odrzuca nowe połączenia TCP, gdy jeden adres ma ich otwartych jednocześnie więcej niż dwanaście, druga odrzuca pakiety UDP powyżej trwałych 600 pakietów na sekundę z tego samego źródła. Obie liczby to wartości startowe, a nie prawdy objawione: pełny serwer RP generuje wyraźnie więcej pakietów niż pusty, a kto ustawi limit zbyt ciasno, wyrzuci własnych graczy. Najpierw mierz przez tydzień w normalnej pracy.

Dwie uwagi. Same reguły iptables znikają po restarcie, na Debianie i Ubuntu zapisuje się je tak:

apt-get install -y iptables-persistent
netfilter-persistent save

A przy UFW takie reguły należą do /etc/ufw/before.rules, bo inaczej znikną przy następnym ufw reload. Często przeoczonym wąskim gardłem jest ponadto śledzenie połączeń w kernelu: gdy się zapełni, serwer odrzuca także legalne pakiety, 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

6. Wpis na liście serwerów

Tutaj opłaca się 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 liście i tak go publikuje. Kto publicznego wpisu nie potrzebuje, bo projekt działa wyłącznie przez Discorda i połączenie bezpośrednie, może go wyłączyć przez sv_master1 "". Kosztuje to jednak całą widoczność dla nowych graczy i pomaga tylko na najwygodniejszego z atakujących.

Skuteczniejsze są dwa nawyki. Nigdzie nie publikuj surowego adresu IP samodzielnie, czyli ani na kanale Discord, ani na stronie projektu. I podłączaj graczy przez nazwę hosta, żeby w razie potrzeby móc zmienić adres bez łamania wszystkich odnośników. Klasykiem są przy tym stare wpisy DNS: zapomniany rekord A wskazujący na poprzedni adres unieważnia każdą zmianę.

7. Whitelist i weryfikacja przy dołączaniu

Whitelist działa przeciw wszystkiemu, co korzysta ze zwykłej drogi dołączania: trollom, klientom z cheatami, botnetom z kont jednorazowych. Wdraża się ją po stronie serwera w zdarzeniu playerConnecting, gdzie zatrzymujesz połączenie funkcjami deferrals, sprawdzasz identyfikator i dopiero potem przepuszczasz gracza. Do tego dochodzi ostra weryfikacja konta, realistyczny limit graczy oraz wyłączony ScriptHook:

sv_authMaxVariance 1
sv_authMinTrust 5
sv_maxclients 48
sv_scriptHookAllowed 0

Hasło RCON ustawiaj tylko wtedy, gdy RCON jest ci naprawdę potrzebny, bo ten dostęp leży na tym samym otwartym porcie. I jedno musi być jasne: whitelist chroni logikę twojej 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.

8. Sprawdzaj zdarzenia sieciowe po stronie serwera

Wiele awarii zgłaszanych jako atak DDoS bierze się z jednego skryptu. Zasoby FiveM komunikują się przez zdarzenia sieciowe, a zdarzenie, które serwer wykonuje bez sprawdzenia, jest otwartymi drzwiami: kto wyśle z klienta TriggerServerEvent z dowolnymi wartościami, może wygenerować pieniądze, spawnować pojazdy albo w pętli wywoływać zapytania do bazy, aż serwer stanie.

Trzy zasady wyłapują większość takich przypadków. Rejestruj przez RegisterNetEvent wyłącznie te zdarzenia, które naprawdę mają przychodzić od klienta. Nigdy nie polegaj na wartościach przysyłanych przez klienta, tylko ustalaj gracza po stronie serwera z source. I ogranicz, jak często gracz może wywołać to samo zdarzenie, zwłaszcza przy wszystkim, co odpytuje bazę. Jeśli serwer się tnie, a łącze jest spokojne, resmon 1 w konsoli klienta pokaże czas procesora na każdy zasób, a winowajca stoi zwykle na samej górze.

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 wtorkowy wieczór. Po apt-get install -y vnstat sysstat pomiar chodzi na stałe w tle. W trakcie incydentu wystarczą cztery polecenia: liczba pakietów na sekundę, liczba odrzuconych pakietów na interfejsie, komunikaty kernela oraz krótka próbka ruchu.

sar -n DEV 1 10
ip -s link show eth0
dmesg -T | tail -50
tcpdump -ni eth0 port 30120 -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, 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 megabajtów na sekundę, a łącze jest pełne, gdy tylko ktoś wyśle więcej. Ataki na projekty FiveM 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 iptables za tym łączem jest dobra, nie ma już wtedy znaczenia, bo pakiety twoich graczy nie przechodzą już wcześniej.

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ć. 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. Centrum danych to maincubes we Frankfurcie nad Menem (Niemcy). 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 EUR miesięcznie, w modelu PrePaid i bez minimalnego okresu umowy. 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: sam ustawiasz, co jest dozwolone na 30120 UDP, a co na 30120 TCP, bez pisania zgłoszenia.
• Zmiany działają w czasie rzeczywistym, możesz więc korygować ustawienia w trakcie trwającego ataku.
• Profil ochrony dopasowany do konkretnej gry. Dla FiveM istnieje gotowy profil, tak samo dla zmodyfikowanych i własnych aplikacji na dowolnych portach TCP albo UDP.

Porównanie obu wariantów

Dla większości projektów FiveM 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

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

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

„Serwer działa, ale wszyscy gracze mają efekt gumki”: to częściej skrypt niż atak. Sprawdź najpierw przez resmon 1, czy jakiś zasób nie zjada czasu procesora. Jeśli sar -n DEV 1 10 nie pokazuje nic nietypowego, to nie był atak DDoS.

„txAdmin pokazuje setki nieudanych prób połączenia”: to flood prób dołączenia i uderza w logikę gry, a nie w łącze. Pomagają na to whitelist, weryfikacja konta oraz limit połączeń na adres źródłowy.

„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

Zamknij wszystko poza 30120 TCP i UDP, trzymaj txAdmin oraz bazę danych z dala od otwartej sieci, ogranicz połączenia i liczbę pakietów na adres źródłowy, prowadź whitelistę i sprawdzaj zdarzenia sieciowe po stronie serwera. Tym samym jesteś przygotowany na wszystko, co obywa się bez znaczącej przepustowości. Powyżej tej granicy decyduje już wyłącznie sieć przed serwerem.

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.