Túlterhelés elleni védekezés (DDoS) Windows Azure-ral

Az aki publikus webes szolgáltatást nyújt annak elobb utóbb szembesülnie kell azzal, hogy az általa szolgáltatatott webes tartalom kiszolgálási kapacitási igényei megugranak, és adott esetben ez elérheti azt a mértéket is ami meghaladja a használatban levo eroforrások lehetoségeit. Ez eredhet egy pozitív jellegu felhasználói érdeklodés miatt (egy jól sikerült marketing kampány miatt megugró érdeklodok száma, vagy az információk iránt érdeklodok számának megugrása, pl: hóhelyzet, árvíz helyzet, stb.), vagy rosszindulatú túlterhelési támadási kisérlet (DDOS) miatt.

Mind a két esetben közös, hogy egy adott terhelésre tervezett infrastruktúrában a megnövedett kérések száma a szolgáltatás elérhetetlenné válását okozza, aminek a presztízs kérdéseken felül valós anyagi vagy egyéb kihatásai lehetnek. A túlterhetések jellegükbol adódóan csak viszonylag rövid ideig állnak fent, amit a normál terhelésre méretezett infrastruktúra nem tud kiszolgálni, ha pedig ezekre a "túlterhelési tüskékre" méretezzük az infrastruktúránkat, akkor a normál terhelés esetén a valójában használt költségek többszörösét vagyunk kénytelenek költeni az infrastruktúránkra. A felho technológiák, mint a Windows Azure pont azt a lehetoséget biztosítják hogy meglegyen a gyors skálázódási lehetoségünk és költséghatékonyan tudjuk kezelni ezeket a megjelent többlet kapacitás igényeket, "tüskéket"

Ebben a tanulmányban a túlterheléses támadások elleni védekezés lehetoségeit vizsgáljuk, de a jellegükben a megnövekedett valós kérésekbol eredo túlterhelések és annak a kezelése nem különbözik.

Túlterheléses támadás

A wikipedia vonatkozó cikke alapján a túlterheléses támadás (denial-of-service attack, DoS) vagy az elosztott túlterheléses támadás (distributed denial-of-service attack, DDoS) alatt egy olyan informatikai támadást értünk, amely célja a kiválasztott célpont gép, hálózat vagy szolgáltatás elérhetetlenné tétele. A támadás jellege, motivációja eltéro lehet. Az egyik leggyakoribb támadási forma hogy a célpontot olyan mennyiségu kéréssel árasztják el, amellyel megbénítják, hogy a kiszolgáló a valódi felhasználói lekérdezésekre válaszolni tudjon, vagy a válasz olyan lassú lesz, ami gyakorlatilag használhatatlanná teszi a szolgáltatást. A támadások két általános kategóriába sorolhatóak: olyan támadások, amelyek a szolgáltatások összeomlását akarják elérni és olyan támadások, amelyek a szolgáltatások túlterhelését, elárasztását akarják elérni. A ketto közti különbség hogy az elso esetben a szolgáltatás összeomlik (pl.: egy sérülékenység kihasználásából eredo támadás esetén), míg a második esetben a szolgáltatás továbbra is fut és kiszolgálja mind a valós mind a támadó kéréseket, ám a nagy kérés számtól annyira belassul, hogy a valódi felhasználók számára gyakorlatilag használhatatlanná válik.

A DDOS támadások elkövetése az alábbi öt alap kategóriába sorolható:

• Szolgáltatást kiszolgáló számítási kapacitások, eroforrások (pl.: sávszélesség, tárterület, CPU ido, memória) kimerítése
• Konfigurációs információk megzavarása (pl.: hálózati elérési információk, mint routing vagy DNS névfeloldás)
• Állapot információk megzavarása (pl.: TCP kapcsolatok kéretlen megszakítása)
• Fizikai hálózati komponensek megzavarása
• A célpont és a valós felhasználók közötti kommunikáció akadályozása

A DDoS támadások legtöbb esetben megfertozött vagy eltérített „zombi” gépeket használnak a túlterheléses támadások végrehajtásához - mint például az a támadás, amely a DC++ fájlmegosztó alkalmazás eltérítésével több, mint 250 000 gépes támadó hálózattal támadta célpontjait. A támadási kísérletek mögött állhatnak önkéntesek is akik saját maguk ajánlhatják fel a gépük eroforrásait támadásokhoz. Ilyen az Anonymus által végrehajtott DDoS online tiltakozó akciókban is gyakran használt Low-Orbit-Ion-Canon (LOIC) alkalmazás is. Ezzel gyakorlatilag bárki akár egyszeru számítógép felhasználói ismeretekkel is DDoS támadó eszközzé alakíthatja a gépét. A DDoS támadások definíciójuk szerint elosztottak, a sok kicsi sokra megy elv alapján fejtik ki muködésüket, megnehezítve – gyakorlatilag lehetetlenné téve - a kizárólag támadó kiszurésén alapuló védekezést. A DDoS támadások elleni védekezés egyik legjobb lehetosége, ha a szolgáltatás képes kiszolgálni a megnövekvo kérések számát, mind hálózati, mind számítási kapacitásban, így védve ki a túlterhelési támadási kísérletet. Azonban egy olyan infrastruktúra fenntartása, ami képes ilyen nagymértéku kérést kiszolgálni nem költséghatékony normál terhelés esetén.

A Windows Azure

A Windows Azure a Microsoft publikus felho szolgáltatása, amely platform mint szolgáltatás (Platform-as-a-Service - PaaS) és infrastruktúra mint szolgáltatás (Infrastructure-as-a-Service - IaaS) szolgáltatások nyújtására képes. A PaaS szolgáltatások esetében a kifejezetten Windows Azure-ra fejlesztett szolgáltatásokat képes a felhoben futtatni, az IaaS esetében pedig az ügyfelek számára virtuális gép futtatási lehetoségeket nyújt. A teljes mértékben saját infrastruktúrán futatott (on-premise) és a teljes mértékben a felhobol nyújtott szolgáltatások közötti alternatívák közti átmeneteket (ahová az IaaS és a PaaS is tartozik) az alábbi ábra mutatja.

A Windows Azure esetében a szolgáltatás költség elszámolása a szolgáltatás által használt kapacitások alapján történik a Microsoft felé, perc alapú elszámolásban. A szolgáltatás által használt kapacitások közé tartozik például a használt számítási kapacitás (virtuális gép CPU és memória használat), tárkapacitás, hálózati forgalom, stb.. Ez történhet havi fizetési konstrukcióban (pay-as-you-go) illetve nagyvállalati szerzodés (Enterprise Agreement – EA) alapján. Az EA konstrukció esetében egy elore megvásárolt Azure használati mennyiség kerül lekötésre, amely a pay-as-you-go árhoz képest kedvezményes kapacitás árakat biztosít. Az IaaS komponensek lista (pay-as-you-go) árai elérhetoek az alábbi linken: https://www.windowsazure.com/en-us/pricing/calculator/?scenario=virtual-machines

Az elszámolás kapcsán fontos kiemelni, hogy a felhasznált tároló és számítási kapacitások perc alapú elszámolásban, történnek. A kikapcsolt állapotban levo gépek esetében csak a foglalt tárolási kapacitásért kell fizetni. A hálózati forgalom esetében pedig a Microsoft adatközpontjaiból kifelé haladó forgalmakra vonatkoznak.

 A Windows Azure szolgáltatások védelme

A Windows Azure szolgáltatások a Microsoft Global Foundation Services (GFS) által üzemeltetett adatközpontokban futnak. A GFS által üzemeltetett adatközpontokban futnak a Microsoft egyéb saját belso és külso szolgáltatásai (Office 365, Hotmail, Bing, Xbox Live, stb.). Így a Windows Azure-ban futó szolgáltatásokat is védik a GFS által nyújtott behatolás védelmek (a Microsoft adatközponti router szuroi, tuzfalai, terhelés elosztói, stb.). Az Windows Azure-ban futó szolgáltatások biztonságával kapcsolatos leírások találhatók az alábbi linken: https://www.windowsazure.com/en-us/support/legal/security-overview/

Fontos kiemelni, hogy a Microsoft nem végez semmilyen monitorozást, csomag analízist az ügyfelek Windows Azure-ba érkezo vagy onnan kimeno hálózati forgalmain (a Microsoft nem tekint bele, nem rögzíti, és nem elemzi a Windows Azure-ban futó szolgáltatások hálózati forgalmait) A fenti információk megtalálhatóak a Windows Azure Trust Center biztonsággal foglalkozó leírásában.

 A fentiek közül kiemelném, hogy amennyiben az saját Windows Azure-ban futó szolgáltatásunkon szeretnénk behatolási teszteket elvégezni, az esetleges kellemetlenségek elkerülése végett javasolt ezt az erre rendelkezésre álló Penetration Testing Approval Form-on 48 órával elore jelezni.

Védekezési lehetoségek Windows Azure használatával

A webes szolgáltatások elérhetosége több infrastruktúra komponenstol is függ, mint például az internet szolgáltatások (pl.: név feloldás), hálózat, tuzfal, terhelés elosztó, web front-end kiszolgálók, adatbázis. Ezek bármelyikének kiesése vagy szuk keresztmetszetté válása a szolgáltatás elérhetetlenségét, lassulását eredményezheti. A Radware Emergency Response Team által kiadott 2012-es évre vonatkozó jelentése alapján a DDoS támadások esetén szuk keresztmetszetet jelento infrastruktúra komponensek az alábbiak szerint oszlottak meg:

A fentiekbol látható hogy az internet kapcsolat sávszélessége, a tuzfal és behatolás védelmi megoldások és a terhelés elosztók (egy szóval a hálózati komponensek) jelentették a szuk keresztmetszetet az esetek 70%-ában! A kiszolgáló számítási kapacitások az esetek 22%-ában, az adatbázis szolgáltatások pedig az esetek 8%-ában jelentettek szuk keresztmetszetet és, bizonyultak a leggyengébb láncszemnek egy DDoS támadás esetén.

Meddig tart egy támadás és mekkora kapacitás igényt jelent?

A Neustar: 2012 Annual DDoS Attack and Impact Survey: A Year-to-Year Analysis tanulmánya alapján a DDoS támadások idotartama az alábbiak szerint alakul:

Arra vonatkozóan, hogy egy átlagos, nem DDoS támadásból, hanem megnövekedett érdeklodésbol adódó túlterhelés idoszak (sikeres marketing kampány, árvíz, havazás, stb.) esetében meddig áll fent az extra kapacitás igény állapot nem találtam kimutatást, de nagyságrendileg azt gondolom, hogy a fentiekhez hasonló eredményt kapnánk.

Ami pedig a támadások által jelentett sávszélesség igényt jelenti szintén a korábban említett Neustar: 2012 Annual DDoS Attack and Impact Survey: A Year-to-Year Analysis tanulmánya lehet mérvadó:

A fenti értékek már inkább valószínu, hogy jellemzoek egy DDoS támadás jellegu aktivitásra mint a megnott érdeklodésbol eredo helyzetben, hiszen a DDoS támadások célja a kiszemelt célpont elérhetetlenné tétele, amely a legegyszerubben a hálózati elérhetoség bedugításával sokkal kisebb befektetéssel elérheto mint CPU intenzív lekérdezések révén. Ennek alapján azt gondolom, hogy ha az infrastruktúránk képes a túlterheléses támadás kivédésére akkor a megnövekedett felhasználói lekérdezésekbol adódó terheléseket is képes hálózatilag kivédeni. 

Védekezési lehetoségek áttekintése

A Windows Azure segítségével az alábbi lehetoségek vannak a túlterheléses támadások elleni védekezésre:

• Platform mint szolgáltatás (PaaS) alapú webes szolgáltatások: Ez a legegyszerubb védekezést lehetové tevo megoldás, mivel az Azure PaaS-ban megvalósított szolgáltatások estében a nagyobb igények kiszolgálására egyszeruen további worker, vagy web role gépeket kell beállítani és a PaaS-ra fejlesztett alkalmazások automatikusan kiskálázódanak. A kapacitás igény elmúlása után ugyan ilyen egyszeruen visszaskálázható a szolgáltatás az alap értékekre. A PaaS megoldások használatának egyik nagy nehézsége hogy ebben az esetben a webes szolgáltatást a Windows Azure PaaS-ra kell eredetileg is fejleszteni, tehát a meglevo alkalmazásokat csak átfejlesztés révén lehet DDoS védetté tenni.
• Infrastruktúra mint szolgáltatás (IaaS) alapú szolgáltatások: Az IaaS esetében egy Windows Server vagy Linux alapú virtuális gépeket használhatunk. Ahogy az elso ábra is mutatja az IaaS esetében a virtuális gép operációs rendszere és az a feletti rétegek a szolgáltatást igénybe vevo üzemelteti, nem a Microsoft, így olyan szoftver komponenseket telepít rá amilyenre szüksége (és licensze) van. Ez sokkal nagyobb rugalmasságot tesz lehetové, hiszen így gyakorlatilag bármilyen Windows Server-en vagy Linux-on futó webes szolgáltatásunkat kiköltöztethetjük a felhobe, és használhatjuk a felho által nyújtott rugalmasság elonyeit.
• Hibrid infrastruktúra: A hibrid kialakítás az IaaS alapú megoldás egy módosított változata, amely esetében a szolgáltatás nyújtó komponensek részben a Windows Azure-ban részben a saját adatközpontban vannak. Ebben az esetben a szolgáltatásunk front-endjei egy része a saját infrastruktúrán, egy része az Azure-ban fut, mivel az Azure infrastruktúránkat egy site-to-site VPN kapcsolaton össze tudjuk kapcsolni, vagyis gyakorlatilag a Windows Azure virtuális gépek egy másodlagos adatközpontot fognak jelenteni, ami ráadásul rugalmasan bovítheto kapacitást is biztosít. Ennek az alternatívának az értelme lehet egy beruházás védelem, amely esetben az Azure-t mint egy túlcsordulási kapacitást használjuk. Hibrid alternatíva lehet abban az esetben, ha a publikus szolgáltatásunknak csak egy részét akarjuk kiköltöztetni a felhobe, a többi részét (pl.: adatkezelési okokból, stb.) szeretnénk saját infrastruktúrán tartani.

Hogyan véd a túlterhelés ellen a Windows Azure?

A Windows Azure szolgáltatások akár a PaaS akár az IaaS megvalósítás esetében a szolgáltatást futtató kiszolgálók a Microsoft adatközpontjában futnak, és a Microsoft adatközpontjában levo tuzfalakon és terhelés elosztókon keresztül érhetoek el az internetrol. A Microsoft adatközpontok hálózati infrastruktúrája úgy került méretezésre, hogy nem csak a Windows Azure ügyfelek, hanem a Microsoft egyéb szolgáltatásainak (Office 365, Bing, Hotmail, stb.) hálózati forgalmait, illetve az ezek a szolgáltatások elleni támadásokat is képes legyen elviselni, kezelni. Ahogy a fenti riportban láthattuk az esetek 70%-ában a hálózati komponensek bizonyulnak szuk keresztmetszetnek, amely tehát egy Windows Azure-ban futó szolgáltatás esetén sokkal nagyobb kapacitásokkal áll rendelkezésre.

Ahogy a fenti jelentés mutatja az esetek 22%-ában a front end kiszolgálók számítási kapacitása jelentik a hálózati szúk keresztmetszetet az adatbázis szint csak az esetek 8%-ában bizonyult szúk keresztmetszetnek. A Windows Azure esetében lehetoség van a kiszolgálók rugalmas skálázására mind felfelé mind oldalra. A felfelé skálázás esetén a kiszolgálók száma nem változik, hanem a meglevo kiszolgálók kapacitása kerül kibovítésre, mind CPU magok száma, mind memória tekintetében. Az oldalra skálázódás esetében a szolgáltatást nyújtó kiszolgálók számát növeljük meg és a Windows Azure terhelés elosztó (load ballancer) szolgáltatása gondoskodik róla, hogy a terhelés a meglevo és az újonnan beállított kiszolgálók között egyenletesen kerüljön elosztásra.

A felfelé skálázódás felso limitje az elérheto legnagyobb Azure IaaS virtuális gép sablon, az oldalra skálázás felso limitje a Windows Azure szempontjából lényegében nincsen, ebben az esetben olyan gyakorlati határok merülnek fel, mint a gépek számának kezelhetosége, illetve a gépek által jelentett költség. A Windows Azure szolgáltatások, beleértve a virtuális gépek konfigurálását és további új gépek létrehozását vagy törlését PowerShell segítségével lehet szkriptelni. Ennek révén az szolgáltatás oldalra vagy felfelé skálázása automatizálható a megfelelo monitoring rendszerrel való integráció révén.

Az oldalra skálázódáshoz szükséges hogy legyen egy elore elkészített sablon gépek, amely sablon gép tartalmaz minden komponenst elore telepítve és konfigurálva, hogy kiszolgálják a publikus webes szolgáltatást. A másik lehetoség lehet, hogy az extra kapacitás igény kiszolgálására az lehet hogy a szükséges gépek elore el vannak készítve és konfigurálva, és kikapcsolt állapotban vannak. Ez a megoldás akkor javasolt, ha a szolgáltatás muködéséhez kapcsolódóan olyan konfigurációk, módosítások szükségesek amelyek nem automatizálhatóak. Ennek a megoldásnak a hátránya, hogy amennyiben az elore elkészített, de kikapcsolt állapotban levo gépek száma sem elegendo akkor az további kapacitás bovítés csak kézi telepítésekkel oldható meg, valamint hogy a kikapcsolt gépekért ugyan nem, de az általuk foglalt tárterületért folyamatosan fizetni kell (bár az Azure-ban a tárolási költségek elég alacsonyak)

A Windows Azure szolgáltatás beépítetten nem tartalmaz automatikus skálázódási képességet!

Azt figyelembe kell venni, hogy a hálózati kapacitásoknak is van oldalra és felfelé skálázódási vonatkozásuk, mivel a virtuális gépek esetében a virtuális gép mérete nem csak a CPU és a memória hanem a maximális hálózati sávszélesség és a maximálisan használható diszk szám (tárterület) méretét is meghatározza.

A bovebb információk végett érdemes elolvasni a kollégám Michael Washam Virutális gépekrol szóló blogbejegyzését, a fenti ábra is onnan származik.

Miért éri meg az Azure használata? 

Ahogy láthatjuk tehát akkor is, ha egy lényegében akármilyen saját platformra fejlesztett webes szolgáltatásunk van (legyen az Windows-on, Linux-on, IIS-en, Apache-on, Tomcat-en, stb.) akkor is az IaaS révén egy gyorsan skálázható a túlterhelésekre rugalmasan tudunk reagálni. És hogy mennyibe kerül egy támadás kivédése? Ehhez használjuk a korábban említett támadási jellemzoket és a publikusan elérheto Windows Azure árkalkulátort

Vegyük alapul a korábban említett tanulmányokból az alábbiakat:

• a DDoS támadások 87%-ában az okozott forgalom kevesebb, mint 1 Gbps,
• a támadások 80%-a kevesebb, mint 2 napig tart. 

Vagyis vegyünk egy olyan esetet, ami lefedi az 2012-es DDoS támadási esetek 80%-át vagyis hogy 2 napon keresztül folyamatos 1 Gbps-es vonalat teljesen kitölto támadás alatt állunk és nézzük meg hogy mennyibe kerül az infrastruktúra fenntartása ami ellen áll erre az idore a támadásnak.

1 Gbps-es forgalom estében egy óra alatt összesen legfeljebb 450 GB forgalmat generál (1 Gbps / 8 * 3600 -al megadja az egy óra alatt átküldött adatmennyiséget). Ez egy 2 nap alatt 21 TB forgalmat jelent (450 * 48).

Ahogy a fenti táblázatból láthatjuk, ehhez két darab XL, három darab L vagy öt darab M gép szükséges legalább. Számoljunk azzal, hogy CPU intenzív és memória intenzív is a támadás és vegyünk ezért 8 darab L gépet ami plusz kapacitásként bevonásra kerül.

A publikus kalkulátor alapján a két nap alatt generált 21 TB-nyi kijövo adatközpont adatforgalom költsége 2750 USD, a 8 db Large gép költsége 2 napra pedig 138 USD. Vagyis a 2012-ben levo DDoS támadások 80%-a kivédheto a Windows Azure esetében nagyjából 2900 USD extra költséggel (nyilván ez egy becsült összeg a támadás jellegétol, idotartamától, az alkalmazás eroforrás igényeitol és az Azure szerzodési konstrukciótól jelentos mértékben függ a valós összeg). De mondhatnám azt is, hogy egy havazás vagy árvíz által okozott plusz kiszolgálási kérésszám is mindössze ilyen nagyságrendu többlet költséget jelent egy szervezetnek. Ezt az összeget kell összehasonlítani csak azzal, hogy milyen költséget jelentene, ha webes szolgáltatásunkhoz folyamatosan dedikált 1 Gbps sávszélességet szeretnénk, nem is beszélve az extra számítási kapacitás igények (ami a kalkulált példában 8 darab 4 CPU-s 7 GB RAM-os gépet jelent) költségérol, ami az év többi részében kihasználatlanul állna.

Az Azure extra kapacitás használatának nyilván elofeltétele a megfelelo elokészítés, és a szolgáltatások Windows Azure-ba átmozgatása, vagyis már a támadás elott is a Windows Azure-ban kell futnia a szolgáltatásnak. Így természetesen a normál terhelés esetén is a Windows Azure kapacitások használata szükséges és az azok díját is fizetni kell, amely szintén versenyképes a saját infrastruktúrában futtatott gépek költségeivel (hiszen ebben az árban benne van virtuális gépek által jelentett áram, hutés, adatközpont, stb. költsége).

Kiegészítés és összefoglalás

Egy webes szolgáltatás Windows Azure-ba mozgatása nem jelenti a szolgáltatás 100%-os elérhetoségét, vagy azt hogy a szolgáltatás minden esetben garantáltan muködoképes és elérheto lesz mindenki számára. Több ismert és ismeretlen faktor is kihatással lehet. Tájékoztató jellegu, nem teljes köru felsorolással ezek lehetnek például:

• Windows Azure szolgáltatást érinto kiesések. A Microsoft a megfeleloen kialakított IaaS virtuális gépek esetében 99,95%-os elérhetoséget vállal a vonatkozó SLA-ban: https://www.windowsazure.com/en-us/support/legal/sla/
• Alkalmazás szúk keresztmetszetek, az alkalmazás skálázódási képességei, limitációi
• Az IaaS-ben futó virtuális gépek és a rajta futó szoftverkomponensek nem javított, sérülékenységeit kihasználó támadások
• Az IaaS-ben futó virtuális gépek üzemetetése közben bekövetkezo hibákból eredo kiesések
• Konfigurációs hibából eredo kiesések
• Infrastruktúrát érinto támadások vagy kiesések (pl.: névfeloldást, stb.)

Vagyis a Windows Azure egy jó eszköz a túlterhelések, extra kapacitás igények kiszolgálására, de ezt is, mint minden eszközt megfeleloen, a megfelelo szakértelemmel kell használni. Ebben tudunk segíteni akár mi mint Microsoft (Microsoft Consulting Services, és Premier Support Services) vagy akár a rendszer integrátor partnereink.