DDoS útoky na herní servery: upřímný pohled

Útok typu denial-of-service na herní server obvykle není ani sofistikovaný, ani drahý. Někdo prohrál kolo, nebo chce tvoje hráče, nebo chce dvacet dolarů, a pronajme si kapacitu od služby, která se propaguje jako stress tester za pár liber měsíčně. Dorazí jedna z asi pěti dobře známých technik, z nichž většina je stejná už deset let. Upstream filtrování zahodí ty nejzjevnější, než se dostanou ke stroji, a tím vyřeší většinu toho, co se opravdu posílá. Zbytek - provoz, který má tvar skutečných hráčů dělajících skutečné věci - není síťový problém a větší trubka ho nevyřeší. Tento článek je o tom, jak tyhle dvě kategorie rozeznat, protože reakce na každou je úplně jiná a většina rad na toto téma je míchá dohromady.

Jak útok vypadá zevnitř#

Než cokoli jiného, znej příznaky, protože útok se často zaměňuje za pád a pád se často zaměňuje za útok.

Během objemového útoku:

• Hráčům vyprší spojení, všem najednou, nebo se vůbec nemohou připojit.
• Konzole je tichá. Žádné chyby, žádné stack trace, v logu nic neobvyklého.
• Paměť a CPU vypadají na grafech normálně nebo nízko, protože server dělá méně práce než obvykle, ne víc.
• Pokud se ke stroji dostaneš jinou cestou, proces serveru běží a je v pořádku.

Tahle kombinace - pro hráče mrtvý, na grafech živý a nečinný - je podpis. Provoz se zahazuje nebo něco nasytí dřív, než ho herní proces vůbec uvidí, takže z pohledu serveru prostě všichni odešli.

Porovnej to s pádem: konzole má poslední věc, kterou řekla, než zhasla, graf paměti obvykle ukazuje stoupání a restart je zaznamenaný. A porovnej to s útokem na aplikační vrstvě, který vypadá opačně než záplava: CPU na maximu, tick rate na podlaze, log plný pokusů o připojení a server viditelně dělá příliš mnoho práce.

Tři vrstvy a která z nich je ta tvoje#

Útoky se dělí podle toho, kterou část zásobníku vyčerpávají. Dělení není akademické: každá vrstva se zastavuje na jiném místě a jinou stranou.

Objemová je ta, kterou si představuje každý: tolik bitů za sekundu, aby se zaplnila trubka. Nezáleží na tom, co s nimi tvůj server udělá, protože zahlcení nastane dřív, než dorazí. Jediné místo, kde se to dá opravit, je upstream, kde je kapacity víc než útoku.

Protokolové útoky jsou menší v bitech a větší v paketech. SYN záplava otevírá napůl dokončená spojení, která spotřebovávají stav sledování na všem stavovém, co leží v cestě. Záplava fragmentů posílá IP fragmenty, které se nikdy nedokončí, takže se plní buffery pro skládání. Jsou levné na odeslání a zastaví je bezstavové filtrování a rozumné výchozí hodnoty jádra, mimo jiné net.ipv4.tcp_syncookies.

Aplikační útoky posílají malé množství naprosto platného provozu, jehož zpracování tě stojí hodně. Dotaz serverového prohlížeče stojí útočníka jeden malý paket a tebe odpověď sestavenou z živého stavu serveru. Pokus o připojení ho nestojí nic a tebe autentizační výměnu, vstup do světa a možná i uložení. Tahle vrstva je ta, se kterou filtrování nepomůže, a má níže vlastní sekci.

Reflection a amplification, ta levná část#

Většina toho, co booter služba skutečně posílá, je reflection, protože reflection je způsob, jak z malého rozpočtu udělat velký útok. Mechanismus stojí na jedné vlastnosti UDP: neexistuje handshake, takže zdrojová adresa v paketu je to, co do ní odesílatel napíše, a server, který paket přijme, odpoví na tu adresu.

Útočník pošle malý dotaz cizímu serveru, který odpovídá na UDP, a jako zdroj napíše tvou adresu. Třetí strana pošle odpověď tobě. Není napadená ani spoluvinná; odpovídá na otázku, o které věří, že jsi ji položil ty. Amplification je poměr mezi velikostí dotazu a velikostí odpovědi a u některých protokolů je obrovský:

Tyto hodnoty uvádí upozornění US-CERT k amplification založené na UDP a zprávy o incidentech z velkých událostí s memcached. Prakticky to znamená: útočník se skromným připojením na tebe může nasměrovat desítky gigabitů tím, že si půjčí cizí šířku pásma, a pakety dorazí z tisíců nevinných adres, ne z jeho. Blokovat zdroje je zbytečné, protože zdroje jsou také oběti.

Poslední řádek se herního hostingu týká přímo. Query porty enginu Source se roky používaly jako reflektory, a proto Valve přidalo k A2S_INFO challenge: server nyní odpoví neznámému zdroji malým číslem challenge a pořádně odpoví, až když se to číslo vrátí. Je to stejná logika jako TCP handshake, dodatečně nasazená na query protokol, a z internetu tím zmizel oblíbený reflektor.

Skutečná oprava všeho tohoto je ingress filtering v sítích, které podvržené pakety pouštějí ven, což je zveřejněný osvědčený postup od roku 2000 a pořád není nasazený všude. Dokud nebude, zůstává reflection levný.

Proč jsou herní servery snadný cíl#

Čtyři vlastnosti dělají z herního serveru neobvykle lákavý cíl a žádná z nich se netýká toho, jak jsi důležitý.

Tvoje adresa je veřejná záměrně. Hráči se k ní musejí dostat. Je v serverovém prohlížeči, na výpisovém webu, v kanálu na Discordu, na screenshotu. Neexistuje způsob, jak provozovat veřejný server a mít adresu tajnou.

Většina herního provozu je UDP. Žádný handshake znamená, že podvrhování je triviální a bezstavové záplavy jsou levné. Znamená to také, že filtr nemůže použít stav spojení k odlišení skutečného klienta od podvrženého paketu, aniž by znal protokol hry. TCP vs UDP pro herní servery vysvětluje, proč hry zvolily UDP a co to stojí.

Služba je citlivá na latenci. Web, který potřebuje o 400 ms navíc, je pomalejší. Herní server, který potřebuje o 400 ms navíc, je nehratelný. Útočník tě nemusí shodit; stačí, aby se přestalo vyplácet hrát, a na to mu stačí zlomek provozu.

Motiv bývá osobní. Konkurenční komunita, zabanovaný hráč, klan se zášti nebo vydírání namířené na někoho, kdo má padesát stálých hráčů a žádný technický personál. Útoky se proto opakují, přicházejí v tvé špičce a skončí, když se dotyčného omrzí - proto je běžným případem desetiminutový výpadek páteční večer, ne dlouhodobá kampaň.

Co filtrování umí a co ne#

Tady je upřímný účet a je stejný jako na stránce o zabezpečení.

Upstream filtrování zahodí zjevné objemové záplavy, než dorazí ke stroji. Zahodí také reflection provoz, kterého je, jak bylo popsáno výše, většina odesílaného, a poškozený provoz, který by žádný legitimní klient nevytvořil. To je skutečné a stojí to za to: pokrývá drtivou většinu toho, co booter služba skutečně dokáže vygenerovat, a funguje to, protože tyto kategorie jsou rozpoznatelné, aniž by se vědělo cokoli o tvé hře.

Co neumí, je oddělit provoz, který vypadá přesně jako hráč, od hráče. Na síťové vrstvě není rozdíl mezi skutečným klientem posílajícím paket pro připojení a útočníkem posílajícím týž paket. K rozlišení je potřeba vlastní stav hry - kdo se autentizoval, kdo je omezen rychlostí, která identita se připojila devětkrát za minutu - a ten stav žije v herním serveru, ne ve filtru upstream.

Ještě tři omezení, která stojí za to znát, protože vysvětlují chování, které můžeš vidět:

• Filtrování má práh. Něco musí spustit mitigaci, než se zapne, a vteřiny před tím jsou skutečné. Krátký ostrý nápor může skončit dřív, než na čemkoli záleží.
• Filtrování tě může stát legitimní provoz. Agresivní pravidla proti UDP záplavám mohou zahodit pakety skutečných hráčů, proto je mitigace vyvažování, ne vypínač, a proto „prostě filtruj víc“ není zadarmo.
• Poslední úsek až k hráči doma nefiltruje nic. Pokud útočník cílí na hráče, ne na tvůj server, je to problém jeho poskytovatele a ty ani tvůj hosting s tím nic nezmůžete. Adresy tudy unikají přes hlasový chat a peer-to-peer funkce.

Žádný hosting nemůže slíbit opak. Hosting, který slibuje žádný výpadek při jakémkoli útoku, ti prodává větu, ne službu. Co skutečně děláme proti útokům je krátká verze téhož postoje.

Útoky, které vypadají přesně jako hráči#

Tuhle kategorii lidé neočekávají nejvíc, protože na síťovou událost vůbec nevypadá. Server běží, linka je v pořádku a hra je nepoužitelná. Všechno tohle se řeší v konfiguraci hry, ne upstream.

Záplavy dotazů. Opakované dotazy serverového prohlížeče rychlostí, jakou by žádný prohlížeč nevytvořil. Každý z nich nutí server sestavit odpověď se seznamem aktuálních hráčů a mapou. Opravou je cache dotazů nebo omezení rychlosti, pokud ho hra má, přesunutí query portu z výchozí hodnoty a v některých enginech vypnutí veřejného výpisu na dobu útoku. Přesně to poskytují serverové pluginy několika her; viz omezení rychlosti a zneužití.

Záplavy připojení a boti. Klienti, kteří se připojí, projdou handshake a vstupem do světa a zabírají slot, pak se odpojí a vrátí se. Minecraft je klasická oběť, protože spojení jsou TCP a klient je vytváří levně; mitigací je anti-bot plugin nebo proxy před serverem, která autentizuje dřív, než backend cokoli uvidí. Velocity před sítí Minecraftu je standardní podoba toho řešení.

Brute force na RCON. Opakované hádání hesla vzdálené konzole, které jednak spaluje CPU, jednak občas uspěje. Pokud je RCON vůbec vystavený, měl by mít heslo, které nikdo neviděl, nikdy nesdílet hodnotu s ničím jiným a ideálně být omezený na adresy, které ovládáš. Bezpečné používání RCON to pokrývá.

Vyčerpání zdrojů ve hře. Vůbec ne síťový útok: hráč dělá něco legálního, co server obrovsky stojí. Spawnování tisíců entit, stavba stroje navrženého k lagování, zneužití hledání cest v módu, zneužití funkce stahování mapy. Celou odpovědí je moderace, oprávnění a limity entit.

Nepříjemný vzorec napříč všemi čtyřmi: nejúčinnější aplikační útoky na malou komunitu obvykle spustí někdo, kdo v ní už je.

Co můžeš udělat, aby to pomohlo víc než jakýkoli filtr#

Seřazeno zhruba podle toho, kolik která věc změní.

1. Drž adresu mimo místa, která nejsou seznamem serverů. Nezveřejňuj holou IP tam, kam bys nedal domácí adresu. Pro hráče používej hostname a věz, že hostname je pohodlí, ne úkryt: záznam A se přeloží na adresu a záznam SRV pro Minecraft dělá totéž. Připojení domény k herním serveru vysvětluje, co jméno přináší a co ne.
2. Odděl web od herního serveru. Dej web na jiný hosting s jinou adresou. Webový front end může stát za proxy, která skrývá původ; herní server na UDP ne. Záleží na tom, protože web je obvykle způsob, jak lidé herní adresu vůbec najdou. Cloudflare pro weby a herní servery je konkrétní v tom, co oranžový obláček proxuje a co nikdy nebude.
3. Ber query port jako vystavení. Díky němu tě najdou výpisové weby a stejně tak útočníci. Provozuj ho, protože chceš být ve výpisu, ne ze zvyku, a nenechávej přidělený druhý, který nic nepoužívá. Porty herních serverů vysvětleny popisuje, které porty která hra opravdu potřebuje.
4. Počítej s tím, že někdo z tvé komunity jednou bude problém. Drž oprávnění týmu minimální a odvolatelná, nesdílej administrátorská hesla a veď záznam aktivity, který si můžeš později přečíst. Subusers a nejmenší oprávnění je k tomu mechanismus na straně panelu.
5. Omezuj rychlost na herní vrstvě. Omezení připojení, cache dotazů, anti-bot plugin, fronta. To jsou jediné obrany, které fungují proti provozu, který filtrování nevidí.
6. Měj zálohy, které jsi obnovil. Útok není jediný špatný den a cesta k nápravě je táž. Záloha, kterou nikdo neobnovil, je hypotéza.
7. Zapni dvoufázové ověření na účtu, který tohle všechno ovládá. Většina příběhů „dostali jsme DDoS“, které skončí špatně, jsou ve skutečnosti příběhy o napadeném účtu. Dvoufázové ověření na účtu panelu zabere dvě minuty.

Co nepomáhá, přestože se to doporučuje pořád: změna IP adresy. Funguje, dokud se adresa znovu neobjeví, což se u veřejného serveru měří v hodinách, a rozbije každou uloženou oblíbenou položku, kterou mají tvoji hráči.

Během útoku#

Krátký postup, protože v tu chvíli lidé improvizují špatně.

1. Potvrď, na co se díváš. Zkontroluj konzoli a grafy. Nečinný server, v logu žádná aktivita, hráči pryč: objemový nebo protokolový útok. CPU na maximu, log plný spojení: aplikační vrstva.
2. Zapiš si čas. Začátek, konec a co hlásili hráči. Bez časových značek nikdo nemůže potom nic dohledat.
3. Neresartuj opakovaně. Záplavu to nevyčistí, ztratíš neuložený postup a incident se později hůř čte.
4. Otevři ticket s časovými značkami. Z panelu dorazí všem pracovníkům a přílohy zůstávají soukromé. Uveď, zda byla hra odkudkoli dosažitelná, a jakýkoli trace, který se ti podařilo pořídit - metodu najdeš v čtení traceroute a mtr.
5. Pokud jde o aplikační vrstvu, změň konfiguraci hry. Vypni veřejný výpis, zvyš omezení připojení, dočasně zapni whitelist. Whitelist je hrubý nástroj a incident ukončí okamžitě.
6. Potom zjisti, jak tě našli a komu na tom záleželo. Útoky na malé servery jsou téměř vždy osobní a odpověď na „kdo“ obvykle získáš, když se zeptáš stálých hráčů.

Poslední poznámka k šířce pásma: provoz útoku je provoz. Unmetered znamená, že neplatíš za gigabajt, ne že sdílený uplink pojme cokoli donekonečna. Šířka pásma a fair use uvádí, co to slovo skutečně pokrývá.

FAQ#

Může mi hosting zaručit, že server během útoku zůstane online?

Ne, a každý hosting, který tvrdí opak, popisuje marketingový postoj, ne technický. Upstream filtrování zahodí zjevné objemové záplavy, reflection a poškozený provoz, což je většina odesílaného. Provoz s tvarem skutečných hráčů se na síťové vrstvě rozlišit nedá a musí se řešit ve hře.

Ochrání mě skrytí za doménovým jménem?

Ne. Doména je pohodlí pro tvé hráče, ne štít: záznam se přeloží na stejnou adresu a kdokoli ji zjistí za vteřinu. Proxy, které skutečně skrývají původní adresu, fungují pro webový provoz přes TCP; UDP, které používají herní servery, nepřenášejí.

Proč je server nehratelný, když grafy vypadají v pořádku?

Protože úzké hrdlo není server. Záplava je zahlcení před strojem, takže herní proces vidí méně paketů než obvykle, ne víc, a hlásí zdravý nečinný server, zatímco se k němu nikdo nedostane. Nečinné grafy plus chybějící hráči jsou podpis síťové události, ne poruchy.

Jsou booter a stresser služby opravdu hrozba?

Ano, v úzkém smyslu, že jsou levné, snadno koupitelné a generují přesně ten provoz, který je tu popsán. Jsou to také většinou reflection, tedy kategorie, kterou filtrování zvládá nejlépe. Hrozbou pro malou komunitu je opakovaná špatná půlhodina ve špičce, ne dlouhodobý výpadek.

Co je join flood a jak ho zastavit?

Klienti, kteří se opakovaně připojují, aby spotřebovali sloty a práci s handshake. Zastaví se uvnitř hry: anti-bot plugin, omezení připojení, proxy, která autentizuje dřív, než se zapojí skutečný server, nebo dočasně whitelist. Žádné upstream filtrování nepomůže, protože každé spojení je samo o sobě legitimní.

Mám si za ochranu připlácet jako za doplněk?

Přečti si, co doplněk skutečně dělá, než za něj zaplatíš. Pokud jde o upstream filtrování objemového a reflection provozu, stojí to za to a mnoho hostingů to zahrnuje. Pokud je to počet gigabitů bez popisu toho, co se zahazuje, kupuješ číslo, ne chování.