Ochrona serwera Rust przed atakami DDoS

Serwer Rusta rzadko pada przypadkiem. Moment ataku niemal zawsze zdradza motyw: uderzenie przychodzi dokładnie w minucie wipe'u albo w środku raidu. Kto jest pod ostrzałem, nie potrzebuje dyskusji o zasadach, tylko kolejności działań. Ten wpis pokazuje najpierw, co możesz zmienić samodzielnie na serwerze, potem, gdzie te możliwości się kończą, a na końcu, co musi się wydarzyć wcześniej, już w sieci.

Dlaczego akurat serwery Rusta są atakowane tak często

Rust to gra, w której postęp jest ściśle związany z czasem. Raid trwa kilka minut, cykl wipe'u kilka tygodni. Dlatego przestój ma tu większą wartość niż w niemal każdej innej grze: kto się broni, zyskuje czas, gdy serwer pada. Kto atakuje, nie dopuszcza przeciwnika do gry. A kto prowadzi konkurencyjną społeczność, wie, że pierwszy wieczór wipe'u decyduje o liczbie graczy w całym miesiącu.

Dochodzi do tego rzecz, której nie da się usunąć żadną konfiguracją: serwer Rusta jest publicznie widoczny wraz z adresem IP i portem, bo inaczej nikt by do niego nie dołączył. W odróżnieniu od strony WWW schowanej za proxy serwer gry musi ujawnić swój prawdziwy adres. Pytanie nigdy nie brzmi więc, czy atakujący znajdzie twoje IP, tylko co się stanie, kiedy zacznie w nie strzelać.

Porty, o które chodzi

Serwer Rusta zajmuje w typowej konfiguracji cztery porty:

• 28015/UDP, port gry (server.port). Tędy idzie cały ruch rozgrywki. UDP nie zna nawiązywania połączenia, każdy pakiet jest samodzielny, a adres nadawcy da się podrobić. Dla atakującego oznacza to: żadnej możliwości namierzenia, a mimo to praca dla twojego serwera przy każdym pakiecie.
• Port query (server.queryport), również UDP. Przez niego serwer odpowiada na zapytania Steama A2S_INFO, A2S_PLAYERS i A2S_RULES, a bez niego nie pojawi się na żadnej liście serwerów. Bez jawnie podanej wartości leży bezpośrednio obok portu gry, a wiele linii startowych ustawia go na 28017/UDP. Sprawdź to we własnej linii startowej, zamiast polegać na wartości domyślnej.
• 28016/TCP, RCON (rcon.port), przy rcon.web 1 w wariancie WebSocket.
• 28082/TCP, aplikacja towarzysząca Rust+ (app.port).

Port query jest najbardziej kłopotliwy z całej czwórki, bo odpowiedź A2S jest wyraźnie większa od zapytania. Atakujący może odpytywać cudze serwery gier z podrobionym adresem nadawcy i kierować odpowiedzi na swój właściwy cel. Twój serwer nie jest wtedy tylko ofiarą, ale też wzmacniaczem uderzającym w osoby trzecie. Valve dołożyło dlatego do A2S_INFO zapytanie typu challenge, co złagodziło sprawę, ale jej nie zamknęło. Po czym rozpoznasz atak, opisuje wpis Jak rozpoznać atak DDoS na serwerze.

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

Ta część nic nie kosztuje i opłaca się niezależnie od tego, gdzie stoi twój serwer. Nie zdejmie z ciebie ataku wolumetrycznego, ale sprawi, że drobne ataki pozostaną bez efektu, a ty w sytuacji awaryjnej nie będziesz musiał zgadywać.

1. Inwentaryzacja: co naprawdę nasłuchuje

Zanim napiszesz jakąkolwiek regułę, ustal, które usługi są osiągalne. Na serwerze gry, który rósł przez lata, jest ich prawie zawsze więcej, niż się spodziewasz:

ss -lntup

Wszystko, co jest przypięte do 127.0.0.1 albo ::1, nie potrzebuje otwarcia w firewallu. Wszystko na 0.0.0.0 albo [::] jest osiągalne z internetu, łącznie z usługą bazy danych, którą przyniósł ze sobą jakiś plugin. Porównaj wynik z własną linią startową:

./RustDedicated -batchmode -nographics \
  +server.port 28015 \
  +server.queryport 28017 \
  +server.identity "wipe" \
  +server.maxplayers 150 \
  +rcon.port 28016 \
  +rcon.web 1 \
  +rcon.password "TWOJE-DLUGIE-LOSOWE-HASLO"

Jeśli Rust jest u ciebie zainstalowany przez SteamCMD, w kwestii fundamentów pomoże wpis Instalacja serwera gry przez SteamCMD.

2. Otwarte tylko te porty, których Rust naprawdę potrzebuje

Cztery porty, nic więcej. RCON nie ma czego szukać w otwartym internecie, więc ogranicz go do swojego adresu, a Rust+ otwieraj wyłącznie wtedy, gdy korzystasz z aplikacji towarzyszącej:

ufw allow 28015/udp comment "Rust port gry"
ufw allow 28017/udp comment "Rust Query"
ufw allow from 203.0.113.10 to any port 28016 proto tcp comment "Rust RCON"
ufw allow 28082/tcp comment "Rust Companion"

Zastąp 203.0.113.10 własnym adresem. Przy adresie zmiennym droga prowadzi przez tunel SSH.

Uwaga, która co roku kosztuje kilka serwerów: kolejność przy uzbrajaniu firewalla decyduje o tym, czy zamkniesz dostęp sobie samemu. Opisuje ją, razem z drogą powrotną, wpis Konfiguracja firewalla UFW. Gdyby jednak do tego doszło: przy serwerach root KVM i serwerach dedykowanych od KernelHost dostaniesz się do maszyny przez konsolę VNC w panelu klienta. Nie wisi ona na stosie sieciowym systemu gościa i żadna reguła firewalla w gościu jej nie zablokuje.

3. Zabezpieczenie portu query bez wypadania z listy serwerów

Odruch, który nasuwa się pierwszy, czyli zablokowanie portu query, jest najdroższym błędem w całym tym temacie. Bez niego twój serwer znika z przeglądarki serwerów, pokazuje błędną liczbę graczy, a zewnętrzne listy serwerów pokazują go jako offline. Atak dokończyłbyś wtedy własnymi rękami.

Właściwym rozwiązaniem jest ograniczenie liczby zapytań na adres nadawcy. Prawdziwy klient przy przeglądaniu listy pyta kilka razy na sekundę, a narzędzie do ataków typu reflection tysiąckrotnie więcej. W nftables robi to własna tabela, wyliczana przed łańcuchem filtrującym:

table inet rust {
    chain input {
        type filter hook input priority -10; policy accept;
        udp dport 28017 meter rustquery { ip saddr limit rate over 15/second } drop
    }
}

Plik wczytasz poleceniem nft -f. Priorytet -10 sprawia, że reguła zadziała przed łańcuchem filtrującym, który UFW zakłada z priorytetem 0. W klasycznym iptables to samo osiąga moduł hashlimit:

iptables -A INPUT -p udp --dport 28017 -m hashlimit \
  --hashlimit-name rustquery --hashlimit-mode srcip \
  --hashlimit-above 15/sec --hashlimit-burst 30 -j DROP

Zacznij od hojnego limitu i zaciskaj go dopiero wtedy, gdy masz dowód, że legalne zapytania przechodzą. Zbyt ciasny limit wychodzi na jaw dopiero w dniu wipe'u.

4. Odciążenie śledzenia połączeń

Ten punkt jest pomijany prawie zawsze, a tłumaczy przestoje, które wyglądają jak atak wolumetryczny, choć nim nie są. Kernel zakłada dla ruchu UDP wpisy w śledzeniu połączeń (conntrack), a przy podrobionych adresach nadawcy każdy nowy adres to nowy wpis. Gdy tablica się zapełni, kernel odrzuca pakiety bez różnicy: atak i twoi gracze wylatują razem. W logu systemowym pojawia się wtedy nf_conntrack: table full, dropping packet. Sprawdzisz to tak:

sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
dmesg | grep -i conntrack

Najskuteczniejszy krok to w ogóle nie pozwolić na śledzenie ruchu rozgrywki. Rust nie potrzebuje do tego śledzenia stanu w kernelu, bo sesjami zarządza sam:

table inet raw {
    chain prerouting {
        type filter hook prerouting priority raw; policy accept;
        udp dport 28015 notrack
    }
}

W iptables odpowiednik brzmi:

iptables -t raw -A PREROUTING -p udp --dport 28015 -j NOTRACK

Dopiero potem opłaca się podnieść nf_conntrack_max. Kto najpierw powiększa tablicę, przesuwa problem tylko o kilka minut i zużywa na to pamięć RAM.

5. Bufory odbiorcze i parametry kernela

Jeśli pakiety przychodzą szybciej, niż proces Rusta zdąży je odebrać, bufor odbiorczy socketu się przepełnia. Dla graczy wygląda to jak utrata pakietów, mimo że łącze jest wolne:

net.core.rmem_max = 16777216
net.core.rmem_default = 1048576
net.core.netdev_max_backlog = 16384

Zapisz te wartości w /etc/sysctl.d/ i uaktywnij je poleceniem sysctl -p. Czy są w ogóle potrzebne, zdradzi ci kernel: jeśli UdpRcvbufErrors w nstat -az rośnie albo w ss -lunp stale coś wisi w kolejce odbiorczej, to znaczy, że działają. Jeśli obie wartości zostają na zerze, zmiana niczego nie da. To rezerwa, a nie ochrona.

6. Zabezpieczenie RCON

Otwarty port RCON ze słabym hasłem to nie problem DDoS, tylko przejęcie serwera: kto ma RCON, może banować, odbanowywać i zatrzymać grę. Nigdy nie zostawiaj rcon.password pustego ani zgadywalnego, bo wartość z openssl rand -base64 32 wygenerujesz w pięć sekund. I nie otwieraj tego portu publicznie, tylko ogranicz go do swojego adresu.

7. Działania po stronie anti-cheatu i pluginów

Spora część przestojów, które operatorzy zgłaszają jako DDoS, wcale nim nie jest. To awarie wywołane przez pojedynczego klienta kilkuset pakietami, bo w binarce serwera albo w jakimś pluginie pozostaje otwarta luka. Pomaga tu bieżące utrzymanie, a nie przepustowość:

• Utrzymuj binarkę serwera w aktualnej wersji. Comiesięczna aktualizacja, która wymusza wipe, jest jednocześnie aktualizacją bezpieczeństwa. Kto ją odwleka, zostaje ze znanymi błędami.
• Utrzymuj framework pluginów w aktualnej wersji. Oxide/uMod i Carbon dostosowują się dopiero po każdej aktualizacji Rusta. Framework, który nie pasuje do wersji serwera, jest najczęstszą przyczyną awarii w wieczór wipe'u.
• Mniej pluginów. Każdy plugin to dodatkowy kod w tym samym procesie. Pluginy z własnymi usługami WWW (podglądy mapy, strony ze statystykami) otwierają kolejne porty i często publikują przy tym dokładnie ten adres, który chcesz chronić.
• Dbaj o listy banów. Powtarzające się próby połączenia z tego samego konta ukrócisz środkami wbudowanymi. Rust zapisuje właścicieli i moderatorów w server/<identity>/cfg/users.cfg, a bany w server/<identity>/cfg/bans.cfg. Ban nałożony przez banid przeżywa restart.

Rust w samym rdzeniu nie ma whitelisty, przychodzi ona dopiero z frameworkiem pluginów. Na serwerze prywatnym albo społecznościowym działa skutecznie. Na publicznym serwerze z regularnymi wipe'ami nie wchodzi w grę: serwer, na który nikt nie może wejść, jest równie pusty jak ten, który stoi offline.

8. Lista serwerów i własny adres

Publicznego adresu IP serwera gry nie zmienisz, ale wszystko obok już tak. Atakujący często znajduje od razu całe otoczenie: serwer WWW ze sklepem, host bota Discorda, serwer backupów, dostęp do panelu. Te adresy nie mają czego szukać ani w tym samym ogłoszeniu, ani w starych wpisach DNS. Raz na kwartał sprawdź, która subdomena gdzie wskazuje.

9. Zbieranie danych, żeby w trakcie ataku nie zgadywać

W trakcie ataku liczy się jedno pytanie: ile przychodzi i na którym porcie. Wystarczą trzy polecenia:

ip -s link show eth0
nstat -az | grep -i udp
journalctl -u rust-server -f

Pierwsze polecenie pokazuje pakiety, błędy i odrzuty w rozbiciu na interfejsy. Wykonaj je dwa razy w odstępie dziesięciu sekund, a dostaniesz tempo zamiast wartości bezwzględnej. Interfejs i unit usługi mogą się u ciebie nazywać inaczej, więc sprawdź jedno i drugie przez ip -br link oraz systemctl list-units --type=service. Jak wyglądają pakiety, pokaże próbka, która powinna zostać krótka, bo zrzut pod obciążeniem kosztuje czas procesora:

tcpdump -ni eth0 -c 200 "udp port 28015"

Gdzie kończy się ochrona własnymi siłami

Teraz część uczciwa. Wszystko opisane do tej pory działa dopiero wtedy, gdy pakiety dotarły już na twoją kartę sieciową. Serwer wisi zwykle na łączu 1 Gbit/s albo 10 Gbit/s. Przy najmniejszym możliwym rozmiarze pakietu łącze 1 Gbit/s przenosi około 1,49 miliona pakietów na sekundę, a łącze 10 Gbit/s około 14,88 miliona. To górna granica narzucona przez fizykę, niezależna od CPU, kernela i firewalla.

Po drugiej stronie stoją prawdziwe ataki. Dwa przykłady z ruchu produkcyjnego w KernelHoście, oba odfiltrowane w czasie rzeczywistym: UDP flood na serwer gry ARK na porcie 7777/UDP o natężeniu ponad 112,2 Gbit/s i ponad 8,7 miliona pakietów na sekundę oraz atak wielowektorowy na serwer głosowy na porcie 9987/UDP o natężeniu ponad 473,4 Gbit/s i ponad 41,5 miliona pakietów na sekundę.

Przelicz to na własne łącze: 473,4 Gbit/s to około 470-krotność łącza 1 Gbit/s i wciąż około 47-krotność łącza 10 Gbit/s. Twoja reguła może być idealnie poprawna, a mimo to nigdy się nie wykona, bo straty powstają już na routerze przed serwerem. A na długo przed zapełnieniem łącza swoje możliwości wyczerpuje CPU: każdy pakiet kosztuje jedno przerwanie i jedno przejście przez stos sieciowy, nawet jeśli zaraz potem zostanie odrzucony.

Dlatego oba popularne hamulce bezpieczeństwa są niezadowalające. Null-routing (blackholing) wyjmuje atakowany adres IP z sieci i owszem, kończy atak, ale kończy też twój serwer. A reaktywne przekierowanie ruchu do systemu filtrującego kosztuje w czasie przełączania dokładnie te minuty, w których rozstrzyga się raid. Skuteczne jest wyłącznie filtrowanie, które działa stale w sieci przed serwerem.

Co KernelHost przeciwstawia takim atakom

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

Ochrona DDoS w KernelHoście jest zbudowana dwuwarstwowo i stale aktywna, bez konieczności włączania czegokolwiek. Pierwsza warstwa to globalna sieć scrubbingowa o pojemności mitygacji 17 Tbps, która przechwytuje ataki wolumetryczne blisko ich źródła, zanim dotrą do centrum danych. Druga warstwa to filtrowanie Arbor w czasie rzeczywistym o wydajności 3,2 Tbps, pracujące bezpośrednio na miejscu we Frankfurcie nad Menem, które bierze na siebie drobiazgową robotę blisko protokołu i odrzuca złożone wzorce na warstwach od 3 do 7.

Dwie rzeczy są rozstrzygające. Po pierwsze filtrowanie działa nieprzerwanie, nie ma więc czasu wykrycia i przełączenia, w którym twoi gracze wylatują z serwera. Po drugie nie stosuje się null-routingu: atakowany adres IP zostaje w sieci, wypadają wyłącznie szkodliwe pakiety. Ochrona jest zawarta w każdym pakiecie serwerowym bez dopłaty, bez osobnego pakietu ochrony i bez konfiguracji. Serwery stoją w maincubes Premium Datacenter we Frankfurcie nad Menem (Niemcy), z certyfikatem TÜV TIER3+ i bezpośrednio przy DE-CIX. Dostawcą jest KernelHost GmbH z siedzibą w Wiedniu (Austria). 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

Część projektów opartych na Ruście jest atakowana nie od czasu do czasu, tylko celowo przez całe tygodnie, ze zmiennymi wzorcami i zawsze dokładnie na wipe. Na takie przypadki jest Advanced DDoS Protection od 50,00 € miesięcznie, w modelu PrePaid i bez minimalnego okresu umowy. Daje trzy rzeczy, których wliczona ochrona stała w tej postaci nie oferuje:

• Dedykowany chroniony adres IP. Twój serwer zostaje na niego przełączony w naszej własnej sieci, a przebudowa po twojej stronie nie jest potrzebna.
• Samodzielnie zarządzane reguły ochrony dla portu i protokołu. W panelu klienta ustalasz, który port jest filtrowany jakim profilem, na przykład 28015/UDP inaczej niż port query. Zmiany działają w czasie rzeczywistym, bez zgłoszenia i bez czekania.
• Profil ochrony dopasowany do konkretnej gry. Dla Rusta tak samo jak dla ponad 40 innych gier, usług i protokołów, a do tego dowolnie przypisywane profile TCP i UDP dla serwerów modyfikowanych.

Tu również obowiązuje model PrePaid: bez minimalnego okresu umowy, bez okresu wypowiedzenia, bez umowy i bez opłaty aktywacyjnej. Kiedy fala ataków minie, po prostu nie przedłużasz.

Porównanie obu wariantów

Typowe błędy i ich rozwiązania

Serwer zniknął z przeglądarki serwerów, ale nadal działa: prawie zawsze port query jest zablokowany albo zbyt ostro ograniczony limitem. Sprawdź poleceniem ss -lunp, czy nasłuchuje, i poluzuj limit stopniowo. Jeśli Rust+ milczy, zwykle zamknięty jest app.port.

Wszyscy gracze mają wysoki ping i rubberbanding, a łącze nie jest pełne: to wskazuje na liczbę pakietów, a nie na wolumen. Przyjrzyj się odrzuconym pakietom w ip -s link show oraz licznikom UDP w nstat -az. Taki obraz daje pełny bufor odbiorczy albo wyczerpane śledzenie połączeń.

Reguła firewalla jest poprawna, a mimo to nie działa: w takim razie łącze przed serwerem jest wysycone. Reguła, która nigdy się nie wykona, bo pakiet padł już na routerze przed serwerem, nie zdziała nic. Od tego momentu pomaga wyłącznie filtrowanie w sieci.

Po uzbrojeniu firewalla nie ma już dostępu po SSH: zaloguj się przez konsolę VNC w panelu klienta. Tą drogą wyłączysz firewalla i dopiszesz brakującą regułę, nawet gdy przez sieć nic już nie przechodzi.

Atak robi przerwę po zmianie IP i wraca po jednym, dwóch dniach: to sytuacja normalna. Twój serwer sam publikuje nowy adres na liście serwerów, gdy tylko wróci do trybu online. Zmiana IP daje kilka godzin, a nie rozwiązanie.

Na serwerze wykonują się cudze polecenia administracyjne: to nie DDoS, tylko przejęty dostęp RCON. Natychmiast zmień hasło, ogranicz port do swojego adresu i sprawdź listę banów.

Jeśli właśnie jesteś atakowany

Jeśli twój serwer stoi już w KernelHoście, filtrowanie jest aktywne na stałe i nie musisz niczego włączać. Gdybyś mimo to zauważył coś niepokojącego, załóż zgłoszenie wsparcia, żeby nasz zespół dostroił reguły filtrowania dla twojego adresu IP. Przy trwającym ataku dotrzesz do nas dodatkowo przez awaryjny czat WhatsApp pod numerem +43 650 8209883.

Podaj od razu cztery informacje: adres IP, port, przedział czasu w twojej strefie czasowej oraz krótko, co widzisz (gracze wylatują, serwer nieosiągalny, wysoki ping). To oszczędza jedną rundę dopytywania, a ta się liczy, gdy trwa wipe.