Ochrona serwera SA-MP i open.mp przed atakami DDoS

Projekt SA-MP albo open.mp rozwija się zwykle według tego samego schematu: liczba graczy rośnie, serwer pnie się w górę listy, a kilka dni później połączenia zaczynają się masowo urywać. Najdłuższa część tego poradnika opisuje to, co możesz sam zmienić na swoim serwerze bez żadnych dodatkowych kosztów. Dalej znajdziesz granicę, na której te działania technicznie się kończą, i dopiero potem to, co przeciwstawia im KernelHost.

Dlaczego akurat SA-MP i open.mp obrywają tak często

Scena jest ciasna i mocno konkurencyjna. Wiele serwerów roleplay i freeroam zabiega o tych samych graczy, a próg zahamowania przed wystrzeleniem konkurenta z listy na kilka godzin jest bardzo niski. Do tego dochodzą zbanowani gracze oraz próby szantażu wymierzone w projekty z własnym sklepem.

Od strony technicznej gra bardzo ułatwia zadanie atakującym. Cały ruch rozgrywki idzie przez UDP, a UDP nie zna żadnego nawiązywania połączenia, które kosztowałoby atakującego cokolwiek; adresy nadawcy dodatkowo da się fałszować. Wpis na liście serwerów publikuje adres i port, więc wcześniejszy rekonesans jest zbędny. A ponieważ większość projektów działa na jednej maszynie, serwer gry, baza danych, panel użytkownika i często serwer głosowy siedzą pod tym samym adresem: jedno trafienie unieruchamia wszystko naraz.

Porty i protokoły, o które chodzi

• Serwer SA-MP: UDP 7777 w ustawieniu domyślnym, do zmiany przez port w pliku server.cfg.
• Serwer open.mp: również UDP 7777 w ustawieniu domyślnym, do zmiany przez network.port w pliku config.json.
• Query: ten sam port UDP. Osobnego portu zapytań nie ma. Przeglądarki serwerów, strony statusu i boty Discorda odpytują dokładnie ten port, przez który toczy się rozgrywka.
• RCON: także ten sam port UDP, jako osobny opcode wewnątrz protokołu query, jawnym tekstem.
• Wpis na liście serwerów idzie na zewnątrz do odpowiedniej listy, więc przychodząco nie trzeba dla niego niczego otwierać.
• Cała reszta na tej samej maszynie: SSH na TCP 22, MariaDB albo MySQL na TCP 3306, panel użytkownika na TCP 80 i 443.

Wniosek: dostępu query nie oddzielisz od rozgrywki za pomocą firewalla, bo jedno i drugie leży na tym samym porcie. Kto zablokuje UDP 7777, zablokuje własnych graczy.

Zapytanie query zaczyna się od jedenastu bajtów: cztery bajty sygnatury, cztery bajty adresu serwera, dwa bajty portu, jeden bajt opcode. Opcode decyduje o odpowiedzi: i zwraca informacje o serwerze, r reguły, c krótką listę graczy, d szczegółową listę graczy z nazwą, punktacją i pingiem każdego z nich, p odsyła z powrotem cztery bajty do pomiaru pingu, x to RCON. Na dobrze obłożonym serwerze jedenaście bajtów zapytania wytwarza kilka kilobajtów odpowiedzi. To czyni otwarty dostęp query interesującym podwójnie: jako cel i jako wzmacniacz do ataku na osoby trzecie. Co stoi za takim wzorcem ataku, wyjaśnia wpis Czym jest atak DDoS?.

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

Poniższe kroki nic nie kosztują i działają przeciw atakom, które składają się na codzienność: floodom prób połączenia, floodom query oraz pojedynczym źródłom o wysokiej liczbie pakietów. Wszystkie polecenia zakładają konto root, w przeciwnym razie poprzedź je poleceniem sudo.

1. Inwentaryzacja: co w ogóle nasłuchuje?

ss -lnup
ss -lntp

To, co nasłuchuje na 127.0.0.1 albo ::1, nie potrzebuje żadnej reguły firewalla. To, co stoi na 0.0.0.0 albo [::], jest osiągalne z zewnątrz i musi mieć uzasadnienie.

2. Zamknięcie wszystkiego, czego rozgrywka nie potrzebuje

Filtr pakietów nie usunie ataku wolumetrycznego, ale zmniejsza powierzchnię ataku. Nośna konfiguracja wyjściowa z UFW:

ufw allow 22/tcp comment 'SSH'
ufw allow 7777/udp comment 'SA-MP / open.mp'
ufw default deny incoming
ufw default allow outgoing
ufw --force enable
ufw status verbose

Kolejność nie jest przypadkowa: reguły zezwalające stoją przed włączeniem firewalla, inaczej zamkniesz dostęp sam sobie. Szczegóły razem z drogą powrotną znajdziesz we wpisie Konfiguracja firewalla UFW. Przy serwerach root KVM oraz serwerach dedykowanych od KernelHost w sytuacji awaryjnej wejdziesz na system przez konsolę VNC w panelu klienta.

Baza danych nie ma czego szukać w otwartej sieci. Jeśli ss -lntp | grep 3306 pokazuje 0.0.0.0:3306, ustaw bind-address = 127.0.0.1 i zrestartuj usługę. Serwer gry również przypnij do stałego adresu, w SA-MP przez bind, w open.mp przez network.bind.

3. Rozbrojenie dostępu query bez odcinania graczy

SA-MP ma w pliku server.cfg przełącznik query 0, po którym serwer przestaje odpowiadać na jakiekolwiek zapytania. To działa, ale kosztuje sporo: serwer znika z przeglądarki serwerów, liczby graczy ani reguł nie da się już odczytać, a strony statusu oraz boty Discorda pokazują go jako offline. Dla zamkniętego grona jest to opcja, dla rosnącego projektu nie. W open.mp to przełączenie siedzi w sekcji network pliku config.json; sprawdź dokładną nazwę klucza w swojej wersji, zamiast jej zgadywać.

Realna droga to więc ograniczanie zamiast wyłączania. Ta reguła filtrująca pokazuje na żywo wyłącznie pakiety z sygnaturą query:

tcpdump -ni any -c 100 'udp port 7777 and udp[8:4] = 0x53414d50'

Które adresy nadawcy wysyłają najwięcej ruchu na port gry:

tcpdump -nn -q -c 2000 'udp dst port 7777' 2>/dev/null \
  | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

4. Ustawienie limitów pakietów w stosie sieciowym

Za pomocą nftables ograniczysz liczbę pakietów na adres nadawcy. Poniższy zestaw zakłada własną tabelę, żeby nie wchodzić w drogę UFW:

nft add table inet gameguard
nft add chain inet gameguard input '{ type filter hook input priority -150 ; policy accept ; }'
nft add rule inet gameguard input udp dport 7777 meter perip '{ ip saddr limit rate over 60/second burst 120 packets }' drop
nft list table inet gameguard

Warto dołożyć jeszcze górny limit dla całego portu, żeby szeroko rozproszony flood nie przecisnął się przez lukę między wieloma pojedynczymi źródłami:

nft add rule inet gameguard input udp dport 7777 limit rate over 20000/second burst 5000 packets drop

W iptables to samo osiąga moduł hashlimit:

iptables -N SAMPGUARD
iptables -A INPUT -p udp --dport 7777 -j SAMPGUARD
iptables -A SAMPGUARD -m hashlimit --hashlimit-name samp --hashlimit-mode srcip \
  --hashlimit-above 60/sec --hashlimit-burst 120 --hashlimit-htable-expire 30000 -j DROP

Te liczby to wartości startowe, a nie zalecenie dla twojego serwera. Pojedynczy gracz generuje samą tylko synchronizacją pozycji kilkadziesiąt pakietów na sekundę; częstotliwość sterujesz w SA-MP przez onfoot_rate, incar_rate i weapon_rate. Krytycznie robi się wtedy, gdy kilku graczy siedzi za tym samym adresem, na przykład w jednym mieszkaniu albo za carrier NAT operatora komórkowego. Zbyt ciasny limit wyrzuci dokładnie tych graczy, a wygląda to jak atak. Najpierw zmierz, potem ustaw, potem obserwuj rozłączenia.

5. Wartości graniczne w server.cfg i config.json

Obie implementacje mają własne limity ochronne, które zwykle zostają na ustawieniach domyślnych. Dla SA-MP w pliku server.cfg:

lanmode 0
query 1
announce 1
rcon 0
conncookies 1
connseedtime 300000
minconnectiontime 1000
messageslimit 500
messageholelimit 3000
ackslimit 3000
playertimeout 10000

Dla open.mp te same wielkości stoją w pliku config.json:

{
  "network": {
    "port": 7777,
    "bind": "",
    "use_lan_mode": false,
    "cookie_reseed_time": 300000,
    "minimum_connection_time": 1000,
    "messages_limit": 500,
    "message_hole_limit": 3000,
    "acks_limit": 3000,
    "player_timeout": 10000,
    "limits_ban_time": 60000
  },
  "rcon": {
    "enable": false
  }
}

Co robią te wartości:

• Ciasteczka połączeniowe (conncookies względnie cookie_reseed_time) wymagają od klienta odpowiedzi na pytanie zwrotne, zanim zajęty zostanie slot. Sfałszowany adres nadawcy nigdy tego pytania nie zobaczy, więc nie jest w stanie na nie odpowiedzieć. To najskuteczniejszy wbudowany hamulec przeciw floodom połączeń, zostaw go włączonym.
• Minimalny odstęp między próbami połączenia (minconnectiontime względnie minimum_connection_time, w milisekundach) nie pozwala, żeby ten sam adres nawiązywał nowe połączenia co sekundę. Przeciw wejściom botów to druga ważna śruba regulacyjna.
• Limity wiadomości, luk i potwierdzeń (messageslimit, messageholelimit, ackslimit) ograniczają, ile wolno wysłać już istniejącemu połączeniu. Chronią przed zmanipulowanymi klientami, nie przed wolumenem.
• Przekroczenie czasu (playertimeout, player_timeout) określa, jak długo ciche połączenie blokuje slot. Niska wartość szybciej zwalnia miejsca przy floodzie połączeń, ale wcześniej wyrzuca graczy ze słabym łączem. Czas blokady (limits_ban_time w open.mp) ustala, jak długo podejrzany adres pozostaje odcięty.

Dwie uwagi: config.json musi pozostać poprawnym JSON-em, jeden przecinek za dużo uniemożliwi start. A open.mp sam uzupełnia brakujące wartości przy starcie, dlatego edytuj ten plik przy zatrzymanym serwerze.

Jeszcze słowo o RCON: hasło leci jawnym tekstem przez UDP i na całej drodze da się je podsłuchać. Jeśli RCON nie jest ci potrzebny, wyłącz go przez rcon 0 względnie "enable": false, a w przeciwnym razie obowiązuje zasada: długie losowe hasło i dostęp wyłącznie przez VPN.

6. Obrona w gamemode i w pluginach

SA-MP wywołuje OnIncomingConnection, zanim zajęty zostanie slot gracza. W tym miejscu możesz zliczać próby i czasowo blokować podejrzane adresy:

public OnIncomingConnection(playerid, ip_address[], port)
{
    if (ConnectAttemptsTooHigh(ip_address))
    {
        BlockIpAddress(ip_address, 60000);
    }
    return 1;
}

ConnectAttemptsTooHigh jest celowo twoją własną funkcją zliczającą: sensowne progi zależą od liczby twoich graczy. BlockIpAddress oczekuje czasu blokady w milisekundach, UnBlockIpAddress zdejmuje ją przed czasem. Lista blokad leży w pamięci RAM i po restarcie jest pusta.

Uzupełniająco w każdym projekcie powinny znaleźć się dwa narzędzia. Plugin crashdetect pokazuje przy awarii, której funkcji i którego wiersza gamemode ona dotyczy; bez niego błąd wykonania we własnym kodzie wygląda z zewnątrz jak atak. Utrzymywany anti-cheat w rodzaju Nex-AC pokrywa manipulacje po stronie klienta, ale pracuje wyłącznie na połączonych graczach wewnątrz logiki gry. Flood sfałszowanych pakietów nigdy nie stanie się graczem i przechodzi obok tego mechanizmu. To są dwa różne problemy.

Trzymaj poza tym include'y i pluginy w aktualnych wersjach: kilka znanych metod wywracania serwera SA-MP opiera się na wartościach spoza dozwolonego zakresu, przekazywanych do funkcji natywnych. I nigdy nie przekazuj niesprawdzonych danych od graczy do SendRconCommand ani do zapytania bazodanowego.

7. Wpis na liście serwerów i twój prawdziwy adres

Wpis na liście czyni cię znajdywalnym, zarówno dla graczy, jak i dla atakujących. Przy announce 0 znikasz z obu list, a razem z tym z naturalnego napływu graczy. To kwestia bilansu zysków i strat, a nie tajna sztuczka.

Postawienie domeny przed serwerem nic nie da: klient rozwiązuje nazwę raz, a potem rozmawia bezpośrednio z adresem, przy czym rozwiązać tę nazwę może każdy. Sprawdź zamiast tego, co jeszcze zdradza twój adres: stare rekordy DNS typu A i AAAA, panel użytkownika na tej samej maszynie, wskaźnik statusu bota Discorda, otwarty webowy interfejs bazy danych, certyfikaty TLS ze starymi nazwami hostów oraz wpisy na forach z początków projektu.

Wynika z tego zasada, której wiele projektów uczy się za późno: jeśli przenosisz się na chroniony adres, zmień równocześnie adres źródłowy. Inaczej stary będzie stał w każdej bazie skanerów, a atak pobiegnie obok ochrony.

8. Whitelista i tryb zamknięty

Dla portu gry whitelista rzadko jest praktyczna, bo gracze przychodzą ze zmiennych adresów. Hasło serwera (password w obu implementacjach) bez żadnego wysiłku zamienia serwer w zamknięte grono, a wpis na liście przy tym zostaje. Dla dostępów administracyjnych whitelista jest za to obowiązkowa, czyli dla SSH, bazy danych, panelu oraz, jeśli go zostawiasz, RCON:

ufw allow from 203.0.113.10 to any port 22 proto tcp comment 'Admin'
ufw delete allow 22/tcp
ufw status numbered

Przy zmiennym adresie twojego łącza VPN jest czystszym rozwiązaniem niż rosnąca lista wyjątków.

9. Logi: najpierw zmierz, potem działaj

SA-MP zapisuje swój log do pliku server_log.txt w katalogu serwera, a open.mp do pliku skonfigurowanego w sekcji logging. Które adresy pukają najczęściej:

grep "Incoming connection" server_log.txt \
  | grep -oE '([0-9]{1,3}\.){3}[0-9]{1,3}' \
  | sort | uniq -c | sort -rn | head -20

Wysoka liczba żądanych ciasteczek połączeniowych wskazuje na flood prób połączenia:

grep -c "requests connection cookie" server_log.txt

Najbardziej wymowna wartość nie stoi jednak w logu gry, tylko w kernelu. Jeśli proces serwera nie wybiera pakietów z bufora odbiorczego dostatecznie szybko, kernel zlicza straty:

nstat -az | grep -E 'Udp(InDatagrams|InErrors|NoPorts|RcvbufErrors)'
ip -s -s link show

Wynika z tego najważniejsze rozróżnienie w całej sprawie: jeśli błędy bufora rosną przy niskim obciążeniu CPU, dociera do ciebie więcej ruchu, niż proces jest w stanie obsłużyć. Jeśli natomiast jeden rdzeń pracuje na maksimum, a ruch wygląda normalnie, problem siedzi w gamemode, a nie w sieci. Jak odróżnić oba przypadki, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

Gdzie te działania się kończą

Wszystkie dotychczasowe kroki działają dopiero wtedy, gdy pakiety przeszły już przez twoje łącze: kernel odrzuca je po przybyciu. Wyznacza to twardy limit górny, który nie ma nic wspólnego z jakością twoich reguł.

Łącze 1 Gbit/s przyjmuje przy najmniejszym możliwym rozmiarze pakietu około 1,49 miliona pakietów na sekundę, więcej fizycznie się nie zmieści. Dla porównania dwa ataki zmierzone i odfiltrowane na serwerach KernelHost: ponad 473,4 Gbit/s przy ponad 41,5 miliona pakietów na sekundę wymierzone w serwer głosowy na UDP 9987 oraz ponad 112,2 Gbit/s przy ponad 8,7 miliona pakietów na sekundę wymierzone w serwer gry na UDP 7777. Pierwszy przypadek to około 473-krotność przepustowości i mniej więcej 28-krotność liczby pakietów, jaką łącze 1 Gbit/s jest w ogóle w stanie przyjąć. Nawet doskonały filtr na serwerze nic tu nie zmieni, bo pakiety w ogóle do niego nie docierają: łącze przed nim jest zapchane, a razem z nim przepadają też pakiety twoich graczy.

Dwie kolejne granice pojawiają się jeszcze wcześniej. Po pierwsze, serwer gry czyta port w jednym wątku wykonania. Flood query potrafi zająć ten wątek tak mocno, że pakiety synchronizacji prawdziwych graczy przepadają w buforze odbiorczym na długo przed wysyceniem łącza. Proces przy tym się nie wywraca, robi się tylko wolny, a gracze widzą rubberbanding. Po drugie, adresy nadawcy w UDP da się fałszować; blokady po adresie trafiają wtedy w osoby postronne, a w atakującego wcale.

Podsumowując na chłodno: twoja praca na serwerze decyduje o tym, czy przejdzie mały atak. O tym, czy przejdzie duży, decyduje sieć przed serwerem.

Co przeciwstawia temu KernelHost

Zawarte w każdym serwerze: dwuwarstwowa ochrona stała

Każdy serwer w KernelHoście stoi za stale aktywnym, dwuwarstwowym filtrowaniem:

• Warstwa 1: globalna sieć scrubbingu o pojemności mitygacji 17 Tbps. Ataki wolumetryczne są przechwytywane i oczyszczane blisko źródła, zanim w ogóle dotrą do centrum danych we Frankfurcie nad Menem.
• Warstwa 2: filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps bezpośrednio na miejscu we Frankfurcie nad Menem. Tuż przed serwerem rozpoznawane są wzorce charakterystyczne dla poszczególnych protokołów, a pakiety odrzucane jeden po drugim.

Decydujące są przy tym trzy cechy. Ochrona jest aktywna nieprzerwanie, nie ma więc fazy wykrywania, w czasie której twój serwer schodzi offline. Null-routing nie jest stosowany: atakowany adres zostaje w sieci, odpadają wyłącznie szkodliwe pakiety, a połączenia prawdziwych graczy biegną dalej. Do tego nie kosztuje nic dodatkowo, tylko jest zawarta w każdym pakiecie serwerowym, od serwera root KVM przez serwer gier aż po serwer dedykowany. Filtrowanie obejmuje warstwy 3, 4 i 7 na każdym porcie TCP oraz UDP, a więc również na UDP 7777. Całość pracuje w centrum danych maincubes we Frankfurcie nad Menem (Niemcy), a prowadzi ją KernelHost GmbH z siedzibą w Wiedniu (Austria). Które gry i protokoły mają własne profile, pokazuje wpis Ochrona DDoS serwerów gier w czasie rzeczywistym.

Dla projektów ostrzeliwanych bez przerwy: Advanced DDoS Protection

Niektóre projekty nie obrywają od czasu do czasu, tylko są celowo ostrzeliwane tygodniami. Na taki przypadek jest Advanced DDoS Protection od 50,00 EUR miesięcznie, w modelu PrePaid i bez minimalnego okresu umowy. Uzupełnia ona ochronę stałą o trzy rzeczy:

• Dedykowany adres IP objęty ochroną z frankfurckiego rdzenia sieci. Twój serwer zostaje na niego przełączony wewnątrz sieci KernelHost, po twojej stronie nie przebudowujesz niczego.
• Samodzielnie zarządzane reguły ochrony dla każdego portu i protokołu w panelu klienta. Zmiany działają w czasie rzeczywistym, bez zgłoszenia i bez czekania, możesz więc korygować ustawienia w środku ataku.
• Profil ochrony dopasowany do gry. Gotowe profile dla ponad 40 gier, usług i protokołów, w tym dla SA-MP i open.mp oraz dla własnych aplikacji TCP i UDP. Za tym samym chronionym adresem zmieszczą się także panel użytkownika, serwer głosowy i VPN.

Porównanie obu wariantów

Typowe błędy i ich rozwiązania

„Serwera nie ma, czyli to atak.” Sprawdź najpierw, czy proces w ogóle jeszcze działa. Błąd wykonania w gamemode wygląda z zewnątrz identycznie. Z crashdetect przyczyna stoi w logu, bez niego tylko zgadujesz.

„Zablokowaliśmy port query.” Osobnego portu query nie ma. Kto blokuje UDP 7777, blokuje rozgrywkę. W praktyce chodzi albo o query 0 (serwer znika z listy), albo o ograniczenie liczby pakietów na tym samym porcie.

„Zmieniliśmy IP i znowu jesteśmy online.” Bez zamknięcia wycieku nowy adres w ciągu kilku godzin znów będzie publiczny. Stare wpisy DNS, panel na tej samej maszynie oraz wskaźnik statusu bota Discorda zdradzą go niezawodnie.

„Ustawiliśmy limit 20 pakietów na sekundę na adres.” To za ciasno. Już pojedynczy gracz leży powyżej tej wartości, a kilku graczy za jednym adresem NAT dzieli ten sam przydział. W ten sposób wyrzucasz własnych graczy.

„Zamknęliśmy się firewallem.” Restart nie pomoże, bo UFW odtwarza swoje reguły przy starcie systemu. W KernelHoście otwierasz konsolę VNC w panelu klienta i wykonujesz tam ufw disable. Przy serwerach root KVM oraz serwerach dedykowanych nie ma żadnego IPMI ani iDRAC, droga prowadzi przez konsolę VNC.

„Hasło RCON wisi na czacie zespołu.” RCON leci jawnym tekstem przez UDP i na całej drodze da się je podsłuchać. Jeśli go nie potrzebujesz, wyłącz go, a w przeciwnym razie obowiązuje zasada: długie losowe hasło i dostęp wyłącznie przez VPN.

„Po prostu przeczekamy atak.” Ataki, które działają, są powtarzane. Dokumentuj moment rozpoczęcia, czas trwania, wartości szczytowe i porty, których atak dotyczył. Dokładnie tych danych potrzebuje też zgłoszenie wsparcia, żeby filtrowanie dało się dociągnąć celowo.

Jeśli właśnie jesteś atakowany

Jeśli twój projekt działa już w KernelHoście, filtrowanie jest aktywne nieprzerwanie i nie musisz niczego włączać. Gdybyś mimo to zauważył coś niepokojącego, załóż zgłoszenie wsparcia z przedziałem czasu, portem i zaobserwowanym zachowaniem, żeby reguły dla twojego adresu zostały skorygowane. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883.