Masivní DDoS útoky se během let staly v internetovém prostředí celkem běžným jevem, a postupně se také objevily, a dá se říci, že i do jisté míry standardizovaly, metody a nástroje, jak tyto útoky odrážet, aby způsobily co možná nejmenší škodu. Nicméně svět se vyvíjí, internetové standardy také, a metody útočníků vývoj také nemine.

Napsali jsme pro Lupa.cz

Základní metody ochrany

S jistou mírou zjednodušení se dá říci, že DDoS útoky se řeší třemi základními metodami. Jednou z nich je zahození nežádoucího provozu na nějakém výkonném síťovém prvku, zpravidla routeru ISP, který se nachází v cestě toho nežádoucího provozu. Tato první metoda má samozřejmě několik podmnožin (RTBH, mitigace s využitím flow specifikace, případně export ACL do směrovačů apod.), nicméně společným znakem této metody je to, že provoz není přesměrováván do žádného jiného zařízení a nemůže být zahazován na základě žádné detailnější analýzy nad rámec L3 a L4 informací (tedy IP adresy, čísla protokolů, čísla zdrojových/cílových portů nebo jiných identifikátorů daných L4 protokolů, velikost packetů, případně ještě ToS/DSCP). Druhou metodou je přesměrování provozu někam do specializovaného zařízení (což má zase podmnožiny, jako je TMS čili „pračka“ u ISP nebo čištění provozu u některého cloudového operátora, jako je třeba Cloudflare, Akamai, Netscout apod.), třetí metodou pak zvládání nežádoucího provozu v cílové destinaci (za zákaznickou přípojkou) na zařízeních zákazníka (většinou jde o nějaké load ballancery nebo reverzní proxy servery). Každá z těch metod má své výhody i nevýhody, a nejlepšího výsledku je zpravidla dosaženo jejich promyšlenou kombinací.

Od jednoduchých po sofistikované

Není totiž DDoS útok jako DDoS útok.  Sice ještě čas od času vidíme chrlení velkého množství stejných nebo velmi podobných packetů, ať už přímo z kompromitovaných koncových zařízení nebo odrazem, ale i útočníci pochopili, že s tímto druhem provozu si umějí oběti a jejich ochrana poměrně snadno poradit. Jistě, SYN floody, ACK floody, fragmenty, DNS floody apod. tu s námi ještě řadu let budou, ale vedle nich se objevila skupina DDoS útoků mnohem promyšlenějších a sofistikovanějších.

Autoři ochranných systémů samozřejmě zareagovali, a tak TMS systémy alias pračky zvládají analyzovat a filtrovat provoz i podle druhu DNS dotazu či řetězce, na který se útočník ptá, v URL, v SIP packetu, existuje dokonce i možnost filtrovat vyloženě podle výskytu hexadecimálně zadaného řetězce v packetu. Má to ovšem samozřejmě jednu podmínku – ten provoz musí být pro onen TMS systém čitelný a analyzovatelný. Což je splněno u nešifrovaného provozu, nicméně z podstaty věci to není možné u provozu šifrovaného.

Hrozba jménem Tsunami

V současné době proto největší nebezpečí představují útoky, pro které se vžil název Tsunami DDoS útok. Tsunami útočí na HTTPS službu, a to packety, které útočník již odeslal buď regulérně zašifrované, případně se sice nejedná o regulérně zašifrovaný provoz, ale silně jej připomíná, a jediný způsob, jak to rozeznat, je prohnat tento provoz daným dešifrovacím algoritmem. To znamená, že payload každého packetu je, ať už pouhým okem i příslušným analytickým nástrojem, nečitelný a prakticky neanalyzovatelný (bílý šum).

V tomto směru však zatím stále určité možnosti existují. Při realizaci šifrovaného HTTPS/TLS spojení se iniciátor spojení nejprve zeptá prostřednictvím DNS na IP adresu cílového stroje, pak vůči tomuto cílovému stroji otevírá zpravidla TCP spojení, tam je opět zřejmé, jak probíhá TCP handshake, a následně v tom TCP spojení musí ještě proběhnout TLS handshake. To samozřejmě probíhá podle známých norem, například RFC 8446, a ten, kdo má přístup k datovému toku, může analyzovat, zda útočník tuto normu při zahajování spojení dodržuje a chová se jako nějaký obvyklý (například) webový prohlížeč.

Takže zatím je situace sice ernst, ale pořád ještě není hoffnungslos. Nicméně, jak už jsem předestřel na jaře, přicházejí nové standardy. Pravidla hry mění QUIC, pravidla hry mění Multiplexed Application Substrate over QUIC Encryption neboli MASQUE a nakonec právě i DNS dotazy typu HTTPS s podporou technologie Encrypted Client Hello (ECH).  Co to znamená? To znamená, že Internet budoucnosti přinese šifrovaný provoz již od prvního packetu daného spojení, ve kterém budou už i (pochopitelně zašifrované) informace pro navázání TLS spojení, protože klient obdrží veřejný šifrovací klíč příslušného serveru již v DNS odpovědi, spolu s jeho IP (v4/v6) adresou. Technologie MASQUE navíc zastíní i roli samotné IP adresy coby cíle spojení, protože díky MASQUE váš provoz například do Google bude hypoteticky moci projít nejprve několika jinými cloudovými poskytovateli.

Je zjevné, že tímto způsobem lze celkem efektivně zamezit tomu, aby ISP (či přesněji státy, které to ISP pod pohrůžkou likvidačních sankcí nařídí) mohli provádět cenzuru provozu, založenou na blacklistingu IP adres. Vedlejším efektem toho všeho však budou i velmi omezené možnosti analytické ochrany proti promyšleným DDoS útokům, jako je právě třeba Tsunami.

Likvidace nedostatků?

Na druhou stranu, vypadá to, že se také mírně rozšíří možnosti v síťových prvcích. Existuje oficiální IETF draft draft-ietf-idr-flowspec-v2-04, který navrhuje zavedení nového Flowspec 2 (FSv2), řešícího některé nedostatky stávající flow specifikace podle RFC 8955, jako je nejasné a nekonzistentní pořadí pravidel, nemožnost práce s posloupnou sekvencí packetů atd. Ovšem jde zatím jen o návrh, který se ještě nedostal ani do stádia, kdy by byl normou (tedy z draftu se stane RFC). Od vydání RFC je pak ale ještě dlouhá cesta k implementacím v takovém stádiu, aby byly reálně nasaditelné do ostrého provozu.

Samozřejmě některé vlastnosti praček provozu zůstanou i s návrhem FSv2 neohroženy. Jde například o prakticky neomezeně velké ACL (v hw směrovačích jsou velikost ACL i množství flowspec pravidel omezeny velikostí TCAM přidělenou pro ACL a PBR, a ta rozhodně není neomezená), pokročilou geolokaci, mnohem lepší statistické a třeba ladící možnosti z pohledu uživatele takového zařízení.

Klíč je v kombinování

Máme-li to shrnout, nové druhy útoku v kombinaci s novými technologiemi, které jsou zaváděny do internetového provozu, přinášejí útočníkům další možnosti útočit, přičemž možnosti centralizované obrany, přestože se v některých aspektech zlepšují, budou jako celek zaostávat. Efektivní obrana proti vícevektorovým DDoS útokům, obsahujícím i Tsunami DDoS, pak znamená využívání celé škály nástrojů, od filtrování provozu ve směrovačích přes využívání TMS až po WAF resp. reverzní proxy s TLS offloadingem. S jediným samostatným nástrojem toho proti dobře promyšlenému útoku v (už poměrně blízkém) budoucnu mnoho nezmůžete.

A ještě jedna věc. ZoKB ani NÚKIB vám s tímto problémem taky nijak nepomohou. Nicméně čas, úsilí a prostředky, které vás bude stát konformita se ZoKB a reportování NÚKIBu, už nebudete moci investovat do účelnějších záležitostí.

Efektivní řešení od Quantcomu

Quantcom řeší ochranu zákaznické sítě před DDoS útoky kombinací vlastních hardwarových a softwarových prostředků. Jedná se zejména o systém detekce a vyhodnocování anomálií v provozu zákaznické sítě, což je realizováno pomocí platformy Arbor Sightline od společnosti Netscout. Samotná reaktivní ochrana je pak postavena na několika klíčových komponentech, které jsou tvořeny jednak podporou technologie BGP FlowSpec a dalších v páteřních směrovačích Cisco ASR 9900 a Juniper MX, jednak samotným zařízením pro selektivní odstraňování nežádoucího provozu Arbor TMS. Zákazníci mají možnost využít detailního zaškolení svých IT pracovníků od odborníků v Quantcomu a následně si sami řídit a ladit jak probíhající čištění provozu, tak i případně zakládat čištění nová, pokud je intenzita útoku pro spuštění automatizovaných mitigačních procedur kupříkladu příliš nízká.

Sdílejte článek

Nenechte si ujít novinky z Quantcomu

Přidejte si nás na sociálních sítích a mějte vždy přehled o dění ze světa B2B telekomunikace.

Quantcom Logo

V souladu s ustanovením § 89 odst. 3 zákona č. 127/2005 Sb., o elektronických komunikacích v platném znění Vás tímto informujeme, že tyto stránky mohou využívat technické a funkční cookies, které umožňují správné fungování našich stránek a jejich pokročilých funkcí, relační cookies napomáhající správnému zobrazování průběhu návštěvy, jež jsou automaticky mazány v okamžiku, kdy stránky opouštíte, a analytické a statistické cookies umožňující shromažďovat anonymizovaná data pro statistické a analytické účely. V rámci shora uvedených úkonů nedochází ke shromažďování ani jinému zpracování dat osobních údajů uživatelů a získané údaje nelze spojit s žádnou konkrétní osobou.