Ochrona przed DDoS dla serwerów gier: Runbook na erę 10-minutowych ataków

Twoja kolejka matchmakingu zacina się o 21:14. O 21:19 wraca do normy. Sprawdzasz wykres i widzisz skok 620 Mbps, szeroki na sześć minut, który zniknął, zanim alert dotarł na Twój telefon. Nikt z Twojego dwuosobowego zespołu nie widział go na żywo, a gracze sklasyfikowali to jako „lag”.

Taki kształt ataku jest teraz standardem. Raport Cloudflare DDoS Threat Report za Q3 2026 odnotował 18,2 miliona ataków warstwy sieciowej zneutralizowanych w kwartale — czyli około 8 226 na godzinę, jeden co 0,44 sekundy. Z nich 96% zakończyło się w mniej niż 10 minut, a 98% nie przekroczyło 1 Gbps. Ataki hiperwolumetryczne powyżej 1 Tbps spadły z 805 w Q2 do 251 w Q3, czyli o ~69% — raport przypisuje to likwidacji botnetów IoT Aisuru, KimWolf, JackSkid i Mossad przez organy ścigania.

Mniej gigantów. Więcej rojów. A rój to model zagrożenia, na który mały backend gier jest przygotowany najgorzej, bo jest jednocześnie zbyt mały, by uruchomić próg mitigacji u Twojego dostawcy i na tyle duży, by nasycić pojedynczą instancję serwera gry.

To jest runbook dla tego pasma przepustowości.

Co faktycznie zmieniło Q3 2026

Trzy zmiany mają znaczenie, jeśli operujesz serwerami gier. Pierwsza to czas trwania. Wzrost o 208% rok do roku w krótkich, niskopasmowych atakach to operacyjna sygnatura usług DDoS-for-hire „booter”: tanich, powtarzalnych i odpalanych seriami. Spodziewaj się 40 ataków w ciągu wieczoru, nie jednego.

Druga to rotacja wektorów. Refleksja CLDAP — wykorzystywane publiczne kontrolery domen na UDP 389 — spadła o 99,5% kwartał do kwartału, do zaledwie 0,05% ataków, po tym jak była gorąca przez całe H1. Atakujący nie przestali; zmienili wektory. Amplikacja DNS skoczyła o 215% do 3,43% ataków warstwy sieciowej, a ogólne UDP floody wzrosły z 14,06% do 31,31%.

Trzecia to poszerzenie celów. Media pozostały najbardziej atakowaną branżą, ale straciły około trzech czwartych swojego udziału z Q2. Infrastruktura internetowa awansowała z poza pierwszej dziesiątki na #6, a Consumer Services i Adult Entertainment weszły na #8 i #9. Gry znajdują się dokładnie w tym klastrze celów skierowanych do konsumentów i wrażliwych na opóźnienia.

Lekcja dla obrońców: nie buduj swojego playbooka wokół wektora z zeszłego kwartału. Zbuduj go wokół czterech kategorii — UDP flood, amplifikacja DNS, nadużycie refleksji i wyczerpanie SYN — i zakładaj, że proporcje będą się zmieniać.

Co psuje się pierwsze w backendzie gry

Nie wszystko pada naraz, a znajomość kolejności oszczędza Ci walki z niewłaściwym pożarem.

• Port gry. UDP flood na Twoim autorytatywnym porcie serwera zużywa kolejki NIC, zanim dotknie CPU. Twój serwer wydaje się „w górze” dla health checka orkiestratora, bo proces żyje, podczas gdy pakiety są odrzucane w jądrze.
• Endpointy sesji i logowania. HTTP floody uderzają w auth. Gracze, którzy rozłączą się w trakcie ataku, nie mogą wrócić, a ci już w grze wypadają, bo pętla reconnectu zawodzi.
• Odczyt leaderboardów. To najbardziej amplifikowana ścieżka odczytu w większości backendów gier: jedno żądanie klienta rozchodzi się na skan zakresu w bazie danych. 5 000 żądań na sekundę jest trywialne do wysłania i kosztowne do obsłużenia.
• Ingest telemetrii. Często nieuwierzytelniony lub luźno limitowany, często najtańszy endpoint do atakowania.
• Tabela conntrack. Wypełnienie jej wyłącza każdą usługę na hoście, w tym Twój dostęp SSH — w ten sposób czterominutowy atak zamienia się w czterogodzinną awarię.

Ataki refleksyjne zasługują na szczególną uwagę: ruch przychodzi z legalnych resolverów DNS i innych serwerów stron trzecich, więc blokowanie po reputacji IP zawodzi z założenia. Uderza Cię niewinna infrastruktura.

Detekcja: sygnały, które strzelają przed wykresami

Twoje dashboardy lagują. Liczniki jądra nie. Najważniejszym pre-indykatorem jest stosunek pakietów na sekundę do bitów na sekundę. Legalne 300 Mbps ruchu gry to mniej więcej 25 000–40 000 pakietów na sekundę przy typowych rozmiarach payloadu. UDP flood o przepustowości 300 Mbps z pakietami 64-bajtowymi to bliżej 500 000 pps. Ta sama przepustowość, 15x więcej pakietów — i zabije hosta, podczas gdy Twój wykres przepustowości wygląda umiarkowanie.

Uruchom to na podejrzanym hoście:

# socket and memory pressure summary
ss -s

# per-protocol counters and the ones that predict a lockup
nstat -az | grep -E 'UdpInDatagrams|UdpNoPorts|UdpInErrors|TcpExtListenDrops|TcpExtTCPReqQFullDrop'

# current conntrack table occupancy vs max
conntrack -C && sysctl net.netfilter.nf_conntrack_max

# what is actually arriving on the wire
tcpdump -nn -i eth0 'udp and not port 7777' -c 200

Interpretuj je tak:

• UdpInDatagrams rośnie, podczas gdy Twoja pętla gry raportuje mniejszą liczbę graczy = flood.
• UdpNoPorts pikuje = skaner przeszukujący zakres Twoich portów, często prekursor.
• TcpExtTCPReqQFullDrop niezerowe = przepełnienie kolejki SYN, co oznacza, że już tracisz legalne handshake.
• conntrack -C powyżej 70% nf_conntrack_max = dzielą Cię minuty od całkowitej awarii hosta, nie tylko serwera gry.

Jeśli chcesz widoku per-endpoint zamiast widoku jądra, protokół diagnostyczny awarii serwera UEFN przeprowadza Cię przez rozróżnienie zatrzymania na warstwie sieciowej od zatrzymania na warstwie silnika — to pierwsza decyzja w każdym triage.

Do obrony wewnątrz procesu przed śmieciami, które się przebiją, per-źródłowy token bucket na warstwie socketów jest tani i skuteczny. Ten przykład w C# bramkuje pakiety przychodzące, zanim dotrą do ticku symulacji:

using System.Diagnostics;
using System.Net;

public sealed class PacketGate
{
    private readonly Dictionary<IPAddress, Bucket> _buckets = new();
    private readonly int _ratePerSecond;
    private readonly int _burst;

    // A legit client at 30 Hz sends ~30 packets/s. 120/s allows
    // headroom for retransmits without letting a flood through.
    public PacketGate(int ratePerSecond = 120, int burst = 240)
    {
        _ratePerSecond = ratePerSecond;
        _burst = burst;
    }

    public bool Allow(IPAddress source)
    {
        long now = Stopwatch.GetTimestamp();

        if (!_buckets.TryGetValue(source, out var bucket))
        {
            bucket = new Bucket { Tokens = _burst, LastRefill = now };
            _buckets[source] = bucket;
        }

        double elapsed = (now - bucket.LastRefill) / (double)Stopwatch.Frequency;
        bucket.Tokens = Math.Min(_burst, bucket.Tokens + elapsed * _ratePerSecond);
        bucket.LastRefill = now;

        if (bucket.Tokens < 1.0) return false;
        bucket.Tokens -= 1.0;
        return true;
    }

    private sealed class Bucket
    {
        public double Tokens;
        public long LastRefill;
    }
}

Bądź świadomy, co to robi, a czego nie robi. Filtruje per-źródłowe śmieci, które mieszczą się w Twoim dostępnym paśmie. Nie robi nic, gdy rura jest pełna — wtedy pakiety są odrzucane przed Twoim procesem, niezależnie od tego, co zdecyduje Twój kod.

Runbook reagowania: pierwsze dziesięć minut

Ponieważ 96% ataków kończy się, zanim człowiek zdąży zareagować, zadaniem runbooka nie jest naprawienie ataku. Chodzi o to, byś zebrał dowody i zmniejszył promień rażenia, podczas gdy atak wypala się sam.

T+0 do T+2 minut — potwierdź, nie skaluj. Oprzyj się refleksowi dodawania instancji. Skalowanie w stronę floodu mnoży Twój rachunek i powierzchnię ataku. Potwierdź wektor powyższymi licznikami, zanotuj pps i przepustowość oraz sprawdź, czy tabela conntrack się wypełnia. Jeśli tak, natychmiast przejdź do awaryjnej ochrony hosta z T+0.

T+2 do T+5 minut — zrzuć nieistotne obciążenie. Wyłącz wszystko, co nie jest rozgrywką: batchowanie telemetrii, odświeżanie leaderboardów, polling sklepu, feedy społecznościowe. Jeśli Twój backend wspiera konfigurację zdalną, to przestawienie jednego flagu zamiast deployu.

T+5 do T+10 minut — zastosuj limity szybkości na poziomie hosta. Filtrowanie w jądrze jest o rzędy wielkości tańsze niż filtrowanie aplikacyjne:

table inet gameguard {
    set udp_flood {
        type ipv4_addr
        flags dynamic, timeout
        timeout 60s
    }

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

        iif lo accept
        ct state established,related accept
        tcp dport { 22, 443 } accept
        tcp dport 7777-7800 accept
        udp dport 7777-7800 accept

        # drop fragmented UDP - your game protocol should never need it
        ip frag-off & 0x1fff != 0 udp drop

        # per-source UDP cap well above a real client's send rate
        udp dport 7777-7800 update @udp_flood \
            { ip saddr limit rate over 200/second burst 400 packets } drop
    }
}

Załaduj przez nft -f gameguard.nft. Zweryfikuj przez nft list ruleset i nft list set inet gameguard udp_flood. Jeśli pomylisz się i zablokujesz sobie dostęp, zamienisz incydent sieciowy w incydent wymagający fizycznego dostępu — najpierw przetestuj na stagingu i trzymaj reguły w version control.

T+10 minut i dalej — eskaluj do swojego dostawcy. Potrzebujesz możliwości scrubbingu lub blackhole na krawędzi sieci, nie na hoście. Większość zarządzanych dostawców hostingu gier to oferuje; jeśli Twój nie oferuje, to problem zakupowy do rozwiązania przed następnym atakiem. Zapytaj wprost o próg mitigacji UDP poniżej 1 Gbps, bo większość opublikowanych SLA jest napisana pod ataki terabitowe, których nigdy nie zobaczysz.

Przez cały czas: prowadź log ze znacznikami czasu. Początek ataku, wektor, szczytowe pps, szczytowe Gbps, co zmieniłeś i kiedy. Postmortem jest warte więcej niż sama mitigacja.

Playbook wektorów: dopasowanie reakcji do kształtu

UDP flood (31,31% ataków). Losowe lub celowane porty, zmuszające host do sprawdzania listenera i generowania ICMP unreachable. Artykuł architektura fallbacków warstwy sieciowej omawia, jak utrzymać tryb zdegradowany, ale grywalny, gdy główny transport jest atakowany. Reakcja: per-źródłowy rate limit w nftables, zamknij wszystkie porty UDP niebędące portem gry i wyłącz generowanie ICMP unreachable na hoście.

Amplifikacja DNS (3,43%, wzrost o 215%). Zapytania ze sfałszowanym źródłem do otwartych resolverów, duże odpowiedzi wycelowane w Ciebie. Reakcja: nie możesz blokować po źródle, bo źródła to legalne resolvery. Możesz tylko absorbować lub filtrować po rozmiarze odpowiedzi i szybkości. Potwierdź, że sam nie prowadzisz otwartego resolwera przez dig +short txt chaos version.bind @your.ip — jeśli odpowiada, zamknij go dziś.

CLDAP (spadek do 0,05%). Obecnie cichy, historycznie ogromny. Przypomnienie: amplifikacja CLDAP działa na UDP 389, więc jeśli nie potrzebujesz LDAP, trzymaj go filtrowanego zarówno na hoście, jak i na firewallu chmurowym. Atakujący wracają do niezabezpieczonych portów, gdy rotują z powrotem.

SYN flood. Rzadko o wolumen, zawsze o wyczerpanie. Włącz SYN cookies (sysctl -w net.ipv4.tcp_syncookies=1), podnieś net.core.somaxconn i upewnij się, że tabela conntrack jest rozmiarowana pod Twój najgorszy realistyczny przypadek, a nie pod domyślne wartości.

Prewencja: architektura, która przetrwa czterominutowy atak

Najpierw matematyka pojemności, bo zabija mnóstwo życzeniowego myślenia. Serwer 64-osobowy na 100 tickach przesyła mniej więcej 15–20 KB/s na gracza — nazwijmy to 1,2 MB/s, czyli około 10 Mbps na instancję. Atak 400 Mbps to 40x legalnego ruchu tej instancji. Ponieważ 98% ataków mieści się poniżej 1 Gbps, prawie każdy atak w obecnym rozkładzie jest wystarczająco duży, by zdmuchnąć pojedynczą instancję gry, a jednocześnie zbyt mały, by zainteresować auto-mitigację providera scrubbingu klasy tier-1.

To ogranicza Twoją architekturę na trzy sposoby.

Oddziel płaszczyznę kont od płaszczyzny gry. Jeśli Twój endpoint logowania, odczyty leaderboardów i zapisy graczy działają na tym samym hoście co serwery gry, flood na porcie gry wyłącza również konta, a gracze nie mogą nawet dotrzeć do ekranu „zaraz wracamy”. Uruchomienie tych usług związanych z kontami na horizOn — authentication, Cloud Save i leaderboardy są tam w pełni zarządzane — oznacza, że atak na port gry degraduje rozgrywkę, ale nie blokuje graczom dostępu do profili.

Spraw, by zrzucanie funkcji było zmianą konfiguracji, nie deployem. Gdy uderza flood, masz sekundy. Konfiguracja zdalna pozwala natychmiast wyłączyć kosztowne ścieżki odczytu. Jeśli Twoją jedyną opcją jest wdrożenie builda, nie użyjesz jej.

Zbuduj health check tak, by widział awarię sieci. Check procesu raportuje „healthy”, podczas gdy jądro odrzuca 90% pakietów. Testuj faktyczną osiągalność rozgrywki — syntetyczny klient wykonujący prawdziwy handshake i oczekujący odpowiedzi w ciągu 250 ms — i niech to napędza Twój failover.

Najlepsze praktyki: pięć zmian wartych wdrożenia w tym tygodniu

1. Alertuj na szybkość pakietów, nie tylko na przepustowość. Ustaw próg na 2,5x Twojego 95. percentyla pps. Alertowanie tylko po przepustowości całkowicie pomija krótkie ataki; detekcja anomalii pps łapie flood 300 Mbps na hoście z linkiem 1 Gbps, którego żaden wykres przepustowości by nie oznaczył.
2. Rozmiaruj tabelę conntrack celowo. Ustaw net.netfilter.nf_conntrack_max na podstawie szczytowej liczby równoczesnych sesji, nie domyślnej wartości dystrybucji, i alertuj przy 70% zajętości. Ta jedna zmiana zapobiega najczęstszej eskalacji „atak stał się awarią”.
3. Przygotuj wcześniej ruleset nftables i testuj go kwartalnie. Trzymaj go w repo obok konfiguracji deployu. Nietestowana reguła firewalla zastosowana podczas incydentu to drugi incydent.
4. Opublikuj kontrakt trybu zdegradowanego dla graczy. Jeśli leaderboardy i czat znikną na dziesięć minut podczas mitigacji, napisz o tym w patch notesach i na stronie statusu. Cisza jest czytana jako martwa gra. Jeśli chcesz wzorca, wzorce odporności w analizie architektury backendu po kompromitacji przekładają się bezpośrednio na incydenty dostępności.
5. Loguj każdy atak jako ustrukturyzowane zdarzenie. Znacznik czasu, wektor, szczytowe pps, szczytowe Gbps, czas trwania, zastosowana mitigacja. Po pięciu zobaczysz własny wzorzec — większość indie backendów jest atakowana tego samego dnia tygodnia, o tej samej godzinie, przez tego samego bootera.

Podsumowanie

Profil zagrożeń 2026 jest wrogi zespołom, które planują na ataki terabitowe, a ignorują sześciominutowy atak 400 Mbps. Giganci spadli o 69%; roje wzrosły o 208%. Twoja mitigacja musi być zautomatyzowana, tania i w jądrze, bo żaden człowiek nie zadziała w trakcie ataku, który kończy się, zanim alert zostanie przeczytany.

Zacznij od liczników, nie od dashboardów. Dodaj per-źródłowy rate limit, rozmiaruj tabelę conntrack, oddziel płaszczyznę kont od płaszczyzny gry i przećwicz dziesięciominutowy runbook, aż stanie się nudny.

Jeśli część tego rozdzielenia to niewdzięczna praca, której wolisz nie posiadać — uwierzytelnianie graczy, Cloud Save ze świadomością rewizji, leaderboardy, konfiguracja zdalna, którą możesz przestawić w trakcie incydentu — to właśnie tę część obsługuje horizOn, dzięki czemu Twój czas dyżurowy idzie na serwery gier. Wypróbuj za darmo lub przeczytaj dokumentację przed następnym oknem startowym.

---

Źródło: Cloudflare DDoS Threat Report 2026 Q3: Więcej rojów, mniej gigantów