V minulých dnech české firmy, tentokrát pak zejména banky, zase poznaly, že útoky typu DDoS je dovedou pěkně potrápit. Jaká byla anatomie těchto proběhlých útoků a co se s nimi dá dělat?

zdroj: Lupa.cz

Obecně (D)DoS ((Distributed) Denial of Service) útok je takovým útokem, jehož smyslem není ani proniknout do některého systému s cílem jej ovládnout, ani odcizit data, ale jen znemožnit běžnému uživateli cílový systém používat. Zpravidla si pod takovým útokem představujeme zahlcení nějakého zdroje sítě nebo koncového systému. Volumetrický (D)DoS útok cílí zpravidla na kapacitu internetové konektivity oběti, pak dochází k zahlcení přístupových linek koncových systémů, nebo na výkon některého slabšího softwarového směrovače na trase, pak dochází k jeho „utloukání“ velkým množstvím malých packetů. „Aplikační“ (D)DoS útok je takový, který zahlcuje až cílové systémy.

V reálu takový útok zpravidla probíhá tak, že útočník nějakým nelegitimním způsobem získá přístup k cizím koncovým systémům, které pak z nějakého řídícího bodu (CoC) ovládá. To znamená, že určuje cíl, vektor a čas útoku. Ovládání zkompromitovaných cizích systémů je pak zpravidla automatizováno do té míry, že jedním příkazem lze přikázat zahájení útoku mnoha (v praxi i statisícům až milionům) takových zkompromitovaných systémů. To mohou být IoT zařízení, třeba webkamery nebo termostaty, domácí routery, stanice koncových uživatelů, případně to mohou být i servery, fyzické i virtuální, v housingových centrech.

V případě útoků NoName057(16) z přelomu srpna a září to byly převážně servery v datových centrech, často právě VPS. Zajímavé je, že malware jménem DDosia si tam často provozovatelé těchto serverů spustili dobrovolně sami, v některých případech za to údajně dostali i zaplaceno.

Princip útoku pak byl následující: Dokud cílový systém odpovídá, DDosia posílá HTTPS požadavky na náhodné řetězce. V okamžiku, kdy odpovídat přestane, posílá už jen SYN packety (TCP packet s nastaveným SYN bitem otevírá TCP relaci). Z pohledu síťového provozu byly tyto útoky nevýznamné, avšak koncovým systémům dokázaly jak zcela vytížit jejich procesory, tak případně zaplnit tabulky TCP spojení.

Tak, a co s tím?

S HTTPS resp. TLS je z hlediska boje proti DDoS útokům poněkud problém. Ten spočívá v tom, že provoz v HTTPS relaci je zašifrovaný a odhalit se 100% spolehlivostí, zda je, či není legitimní, je, vidíme-li jen tuto relaci, na hranici nemožného. Nicméně ani útočníci nejsou dokonalí, nemají k dispozici neomezené zdroje a jsou také zranitelní.

Prehistorickým způsobem, jak bojovat s DDoS útoky, je tzv. remotely-triggered blackholing (RTBH). To spočívá v tom, že cílový autonomní systém takového útoku oznámí protokolem BGP adresní rozsah cíle útoku svému upstream operátorovi, případně též vybraným peeringovým partnerům, s nějakou specifickou BGP komunitou, která zajistí, že provoz pro cílový rozsah nebo pro jednotlivou cílovou adresu se zahodí už v síti, od které oběť nakupuje IP konektivitu. Má to samozřejmě celou řadu nevýhod, z nichž tou zásadní je, že cílová síť sice ochrání svoji kapacitu pro další uživatele, ale v zajištění nedostupnosti cíle útoku útočníkovi naopak pomůže. To nechcete.

Lepší a modernější způsoby samozřejmě existují. Můžete si ochranu proti DDoS útokům koupit od některého cloudového operátora, jako je například Cloudflare nebo Akamai, vlastní službu tohoto typu ohlásil přednedávnem i Wedos. Existují dva základní principy fungování takové cloudové ochrany, varianta anycast reverzní https proxy vám ochrání https, ale jakékoli jiné řešení, než využívat takové služby trvale, naráží na zásadní provozní těžkosti (a ten trvalý provoz často taky). Druhou možností je směřování veškerého provozu pro postiženou cílovou síť (s minimální granularitou /24) ke cloudovému operátorovi. To zase vyžaduje výrazné zásahy do vaší směrovací politiky a jejího popisu v databázi RIR (v našem případě RIPE NCC). Cloudový poskytovatel vám pak vyčištěný provoz posílá zpravidla nějakým GRE tunelem, ale existují i jiné možnosti. Nevýhody jsou také zřejmé, packet k vaší službě cestuje mnohem delší trasou a přes více systémů, což způsobí nějaké zpoždění, které uživatel může vnímat negativně. A samozřejmě tuto druhou možnost lze použít jen tehdy, máte-li a oznamujete-li sami své vlastní rozsahy IP adres do Internetu.

Obrana proti DDoS útokům poskytovaná ISP/NSP, tedy dodavatelem vaší internetové konektivity, je další možností. Výhodou zde je to, že operátor je vám síťově nejblíž, dokáže snadno rozlišit vyčištěný provoz od nevyčištěného, a vám v zásadě stačí jen požádat svého operátora o aktivaci a podle dohodnuté úrovně služeb pak můžete nebo také nemusíte dostat přihlašovací údaje k webovému portálu, kde si potom do svého provozu a jeho případného čištění můžete sami podle potřeby zasahovat. Zde je hlavní výhodou zapouzdřenost a téměř poměrně malé úsilí ze strany chráněné sítě při implementaci.

Nejčastějším a asi také nejlépe propracovaným komerčním řešením pro ISP je systém, který se nejprve jmenoval Arbor Peakflow SP. Posléze společnost Arbor Networks odkoupila společnost NetScout, došlo tam také k produktovým změnám a současný de-facto industry standard v oblasti anti-DDoS řešení pro síťové operátory se jmenuje Sightline. Sestává z několika hlavních prvků, jimiž je uživatelský portál, flow kolektor/analyzátor a „pračka“, oficiálně tedy Threat Mitigation System (TMS). Tyto prvky pak komunikují pomocí různých síťových protokolů s páteřními síťovými prvky dotyčného ISP, v současnosti je využíván zejména BGP FlowSpec.

Pračka neboli TMS pak má řadu chytrých funkcí, včetně toho, že zcela převezme některé druhy komunikace za chráněný cílový systém a teprve po příslušném prověření, že kupříkladu TCP handshake je korektně navázán nebo že DNS klient je schopen svůj dotaz zopakovat, pak příslušný datový provoz na onen chráněný cílový systém propustí. Mezi další funkce pak patří například omezení počtu TCP relací per IP adresa vůči chráněnému cílovému systému, filtrování podle výskytu řetězců v payloadu packetů (vzpomínám si na útok, který měl vypadat jako DNS, ale nebylo to DNS, kde se právě tohle ukázalo jako nejefektivnější metoda), filtrování na bázi geolokace, vnějších nešifrovaných markerů při navazování HTTPS/TLS relací atd.

Nejdůležitějším přínosem takové služby je ale to, že nejste slepí. Vidíte velmi detailní statistiky útoku, vidíte podle potřeby i do jednotlivých packetů, někdy v nich najdete i něco zajímavého. Můžete nacházet souvislosti. Útočník si často testuje, zda je cíl pod jeho útokem dostupný a zvolené metody jsou občas zajímavé, někdy tím útočník o sobě i cosi prozradí (viz 2. obrázek).

Rozdíly pak jsou v míře toho, co jednotliví operátoři nechají své uživatele s takovými systémy dělat. K tomu je pochopitelně potřebné získat i nějaké to know-how. V Quantcomu jsme zvolili variantu detailního zaškolení IT pracovníků a možnost, aby si sami mohli ří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á.

V případě DDosie bylo překvapivých a nezvyklých několik věcí. Významnými zdroji provozu byly sítě Linode (AS63949), M247 (AS9009), něco málo přicházelo kupříkladu i z Microsoftu a Amazonu, čili typicky od poskytovatelů VPS, které často tvoří exit nody různých anonymních VPN. Naopak obvyklé zdroje DDoS útoků z Ruské Federace a dalších zemí zejména jihovýchodní Evropy byly tentokrát zcela nezajímavé.

Dá se dělat něco navíc?

Jistě. Dobře dimenzovaná přípojka do Internetu zajistí, že vás nezahltí dva nebo tři gigabity provozu – a takových útoků je zdaleka nejvíc. Slušný a příslušně dimenzovaný hardwarový firewall a/nebo reverzní proxy před serverem, na kterém běží vaše kritická aplikace, odchytí malé SYN útoky. Nemít oba autoritativní name servery v tomtéž racku, ideálně ani v téže serverovně (zdravíme projekt gov.cz), ale nastudovat si BCP 16 resp. RFC 2182. Naučit se rozkládat zátěž. A hlavně si uvědomit, že každý řetěz unese jenom to, co unese jeho nejslabší článek.

Ideální tedy bude nějaká rozumná a chráněným hodnotám přiměřená kombinace výše zmíněných metod, tedy třeba anycast reverzní proxy pro kritickou webovou službu a následně ochrana celých adresních rozsahů u operátora.

Nicméně platí vždy základní tři principy:

1. vždycky lze přidat další úroveň zabezpečení, nicméně nekonečně velká míra zabezpečení také stojí nekonečně mnoho peněz

2. pokud někdo nabízí nějaké zázračné řešení, které automaticky a snadno vyřeší vaše bezpečnostní problémy, je to s jistotou podvodník

3. neměli byste to dělat útočníkům zbytečně snazší, ale naopak se snažit být co nejodolnějším cílem sami o sobě

Alternativní metody

S  DDoS (Distributed Denial of Service)  útoky se ale dá bojovat i jinak než konvenčními metodami. Někdy se podaří infiltrovat CoC centrum a ovládnout celý botnet nebo jeho významnou část. To už není obrana, ale protiútok, což může být pro někoho značně kontroverzní téma, v každém případě to vyžaduje stejné know-how pro průniky do cizích systémů, jako využívají black hats. To je ale mimo škálu běžných opatření a mimo možnosti většiny postižených provozovatelů internetových služeb.

1 / 2
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.