DDoS (Distributed Denial of Service) útoky jsou velmi jednoduchým a efektním způsobem, jak zaútočit na poskytované IT služby jako jsou e-shopy, internetové bankovnictví, portálové služby, zpravodajství, webové servery, poštovní systémy, atd. Pro většinu organizací je takovýto útok útokem na jejich obchodní značku, nicméně v případě finančních institucí nebo společností zakládajících svůj business na e-commerce jako jsou elektronické obchody, jde o přímou finanční ztrátu způsobenou již během několika málo minut nebo hodin.

Metody ochrany, které se používají pro odražení DoS útoků, jsou v případě DDoS útoků neúčinné, neboť nelze útočící systémy jednoduše blokovat a především identifikovat tím, že z nějaké sítě, země nebo systému proudí nezvykle velké množství požadavků. V případě DDoS útoku přichází z jedné sítě, z „jedné“ země nebo jednoho útočícího systému stejné množství požadavků a dat jako z jakéhokoliv jiného legálního systému. Proto v případě aktivní ochrany proti DDoS může docházet k „false positive“ vyhodnocením, nebo li zakázání přístupu ke službě naprosto legálnímu klientovi, který je na černou listinu zařazen jen pro to, že se zrovna snaží přistupovat například z letiště, restaurace nebo sítě mobilního operátora, kteří svým charakterem mohou skrývat i opravdové škůdce. Výsledkem takového snažení je pouze to, že nejsou vyčerpány prostředky cílového systému, ale došlo k zakázání přístupu na přenosové trase, což je sice dobře pro administrátora serveru, ale legální uživatel služby nebyl obsloužen, tudíž byl cíl útočníků dosažen.

Moderní bezpečnostní opatření používají mnohé metody, jak odlišit útočníka od legitimního uživatele, jako jsou různé formy globálních reputačních databází, honey-podů, virtuálního patchování, všemožných heuristických analýz, které identifikují podobnost a odlišnost požadavků či jejich chování, a to až téměř v reálném čase přes koncepci chalange response, až po stále velmi účinné metody založené na signaturách. Ať již je množina nástrojů na identifikaci jakákoliv, vždy dochází k menšímu či většímu množství false positive.

Zkusme uvážit jednoduchý příklad. Náš systém běžně odbavuje 100 000 uživatelů, jeho kapacita je dimenzovaná s rezervou přibližně 100 % (obvyklá rezerva bývá menší). Budeme mít aplikované velmi sofistikované zařízení pro identifikaci DDoS útoků používající moderní metody identifikace, tudíž lze ve velmi optimistickém případě očekávat úspěšnost detekce, nebo-li true positive, na úrovni 70 %. Takovému systému dopřejme taktéž velmi výjimečně nízkou chybovost na úrovni 10 % false positiv. Náš potenciální útočník si pronajme/využije ke svému útoku např. veřejně identifikovanou botnet síť Kraken, která čítala 495.000 ovládaných zařízení (největší známá síť BredoLab čítala 30 000 000 ovládaných zařízení1). To že útok může být veden desítkami odlišných metod (vektory útoku) pro jednoduchost příkladu neuvažujeme, ale naopak by takový fakt přispíval k informaci. Tudíž náš systém z takového útoku vyjde s těmito jizvami:

• teoreticky bude odbaveno 90 000 legitimních uživatelů,
• 10 000 legitimních uživatelů bude odmítnuto,
• botnet síť dokáže prosadit 148 500 ([495000]*[1-0,7]) útočících zařízení,
• výsledná zátěž bude 238 500 požadavků,
• což i při zmíněné rezervě přesahuje o 38 500 požadavků možnosti našeho systému a tudíž DDoS útok bude úspěšný.

Uvedený výsledek není vítězstvím, ale zároveň ani prohrou, protože odbavit 238 500 požadavků je mnohem snazší než odbavovat 595 000 požadavků.

Pomoc přichází z datových center

Existuje způsob, jak se takovýmto DDoS útokům bránit a zvládnout je ze všech hledisek tak, že nedojde k odmítnutí služby a ohrožení značky či reputace provozovatele systému.

Základní myšlenka této obrany, resp. vykrývání zcela neočekávané zátěže, spočívá v odbavování každého požadavku, o kterém nejsme schopni s  99,9% pravděpodobností prohlásit, že jde o nežádoucí požadavek. Jinými slovy, raději odbavíme škůdce než riskovat, že nebude odbaven náš klient. Všechny požadavky budou vyřizovány systémy, které se dokáží flexibilně a automaticky škálovat a získávat dodatečné zdroje v době, kdy je to třeba, a naopak v době, kdy se zátěž dostane na běžnou úroveň, dojde k automatickému snížení čerpání zdrojů, které byly třeba na vykrytí špiček. Jak toho lze dosáhnout?

Automatizovaný výkon dle potřeby

Virtualizaci serverů v dnešní době odborná, ale i široká veřejnost akceptuje a je běžně užívanou technologickou a koncepční součástí datových center. Mezi hlavní výhody, ve smyslu škálovatelnosti, lze u virtualizace spatřovat to, že dokáže řídit přidělování zdrojů v relativně malých, až téměř plynulých kvantech. Také vytvoření nového virtuálního serveru je podstatně snazší, než tomu bylo ve fyzickém světě. Není třeba nic nikam montovat, získávat dodatečné napájení a chlazení, připojovat síťovou konektivitu atd., prostě jen konfigurační změnou, která může proběhnout od klávesnice nebo z automatizovaných skriptů, lze během několika málo minut vytvořit desítky až stovky nových serverů. Moderní aplikace všech možných typů, jako jsou databázové, webové, poštovní, telefonní, monitorovací, renderovací a mnohé další systémy včetně operačních, lze velmi „snadno“ škálovat. Pokud přidáváme další uzly dané aplikace, mluvíme o tzv. „scale out“ a vytváříme tak aplikační clustery, které krom zvýšené odolnosti proti plánovanému, ale i neplánovanému výpadku, dokáží poskytnout mnohem vyšší výkon, resp. obsluhovat mnohem více požadavků. Takovéto rozšiřování aplikačních clusterů má svá pevná pravidla a lze jej zautomatizovat. Pro úplnost uveďme, že podobné označení, tzv. „scale up“ se používá, pokud škálujeme pouze přidáváním zdrojů, jako je výkon CPU, operační paměť, procesorové karty, výkonnost pevných disků, různé cache atd.

Jestliže shrneme situaci, scale up dokážeme velmi snadno řídit/řešit pomocí virtualizace, a to zcela bezvýpadkově včetně přesunů mezi různě výkonným hardware, scale out dokážeme automatizovat rozšiřováním/zmenšováním počtů členů aplikačních clusterů, což je podpořeno tím, že nový virtuální hardware lze v rámci automatizace snadno získat/zrušit taktéž díky serverové virtualizaci. Jinými slovy jsme schopni v rámci svého datového centra zvýšit výkonnost aplikace přerozdělením volných zdrojů, až po mezní hodnotu celého datového centra Taktéž připadá v úvahu získávání dodatečných zdrojů od méně důležitých aplikací, což lze opět zcela automatizovat.

Interně i externě

Mezní hodnoty volných zdrojů celého datového centra budou určitě umožňovat růst o více než 100 %, ale velmi pravděpodobně to nebude 1 000 %. Jako ideální se jeví technologické řešení, které dokáže získat dodatečné zdroje, násobně větší než je naše datové centrum, a interně se „pouze“ zajistí plynulé rozprostření naší automaticky škálující aplikace přes tyto dodatečné volné zdroje.

Takovéto řešení je v dnešní době k dispozici například od společnosti VMware v podobě vCloud Connectoru, ale jsou i jiná řešení. Tato technologie umožní, velmi zjednodušeně řečeno, propojit naše datové centrum s jiným datovým centrem, například cloudového poskytovatele, a chovat se k němu jako k jednomu logickému datovému centrum nicméně s násobkem zdrojů než má naše datové centrum. Toto logické datové centrum lze nazvat hybridním cloudem. Tato koncepce může být velmi podpořena účtovacím ekonomickým modelem, neboť obvykle lze sjednat účtování na základně rezervací a reálného využití zdrojů což znamená, že nevyužívané zdroje budou generovat významně menší náklady u cloudového poskytovatele než v našem datovém centru (nižší náklady za rezervy).

I „velký“ potřebuje rezervy

Seriózní cloudový poskytovatelé mají zpracovaný plán na řízení svých zdrojů včetně operativy jak čelit vyčerpání svých interních zdrojů, neboť business je založen na statistickém předpokladu, že k čerpání rezervací jednotlivých klientů nedochází v jeden čas. Z tohoto důvodu mají poskytovatelé dohody s dalšími poskytovateli (typicky většími jako je například Amazon, ale není to nezbytné) o možnosti využívání zdrojů pro vykrývání špiček. Technologicky je problematika řešena identicky jako ve výše zmíněném případě. Pravdou je, že v českém prostředí existují velcí poskytovatelé cloudových služeb, kteří se domnívají, že jim dojít zdroje nemohou. Na druhou stranu existují i tací, kteří k problematice řízení zdrojů přistupují seriózně. Ve své podstatě se jedná o podobný vztah, jako je mezi pojišťovnou a zajišťovnou.

Velmi podstatné je, že proces škálování a rozprostření takto vybudovaných služeb mezi naše, poskytovatelovo a poskytovatelovo záložní centrum může probíhat velmi dynamicky a flexibilně na základě vnějších podmínek a v rámci malých kvant. Obohacení řešení například o směřování 100 % legitimních požadavků do našeho datového centra a podezřelých do ostatních datových center není ani třeba zmiňovat.

Ekonomika ochrany

Tato koncepce přináší řešení jak čelit DDoS útokům, aniž by došlo k jakýmkoliv projevům takového útoku. Nejedná se pouze o technologické řešení, ale o řešení, které požaduje vstupy z pohledu obchodu, resp. cílů organizace, aby nebyl přerušen provoz kritických služeb a/nebo ohroženo dobré jméno společnosti. Ekonomická stránka tohoto řešení závisí na dvou hlediscích – jednak na efektivitě určení „true positive“ útočníka a za druhé na účtovacím modelu poskytovatele cloudových služeb. Vedlejším efektem této koncepce je to, že při zvyšující se zátěži aplikace ze zcela legitimních důvodů, např. nárůst klientů služeb o desítky procent v důsledku úspěšné marketingové kampaně, již negeneruje žádné náklady na rozšiřování infrastruktury nebo změny designu aplikace, neboť aplikace škáluje zcela automaticky.

Je nutné si uvědomit, že zavedení této koncepce je komplexní problematika týkající se aplikací, systémové i komunikační infrastruktury, vyvažování zátěže, bezpečnostních zařízení a vyhodnocování chování celého prostředí. Také je třeba uvažovat, že náklady na vedení DDoS útoku jsou řádově nižší než takováto obrana. Na druhou stranu, pokud lze vyčíslit škody takovýmito útoky způsobené, tak je lze zcela přesně porovnat s náklady na vybudování této obrany a pak se jedná o manažersko-ekonomické rozhodnutí.

Jak již bylo řečeno dříve, v případě e-commerce, jako jsou například e-shopy, je možné ztrátu z těchto útoků vyčíslit velmi snadno a postavit ji jako protipól zavedení této koncepce. Pokud přihlédneme i k sezónnímu nárůstu tržeb (Vánoce, Velikonoce, atd.), může výpadek dostupnosti služby trvající v řádu několika minut nebo hodin způsobit značné škody vyčíslitelné právě jako ztráty zisků. Náklady po útoku jsou vždy vyšší Náklady na zajištění záložních kapacit v datových centrech a zavedení takové koncepce pro menší systémy, resp. méně exponované, je rozhodně v ekonomických silách většiny organizací, protože mohou být pouze zlomkem ušlých tržeb. Naopak provozní náklady patnáctičlenného týmu expertů, který minimálně 2 týdny pracuje na identifikaci a opatřeních po úspěšném DDoS útoku, budou jistě vyšší než náklady zmiňovaného řešení.

Cílem této koncepce je tedy zamezení projevů útoků na naše systémy legitimním klientům, a to i v případě, kdy je na náš systém veden masivní DDoS útok, a poskytnout bezpečnostním expertům čas pro přijetí vhodných opatření.

Tomáš Jirák