Túlterhelés elleni védekezés (DDoS) Windows Azure-ral - System Center Mindenkinek - Site Home - TechNet Blogs

System Center Mindenkinek

A Microsoft Magyarország System Center és adatközpont megoldásokkal foglalkozó szakértőinek blog oldala

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

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

  • Comments 1
  • Likes

Az aki publikus webes szolgáltatást nyújt annak előbb 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 levő erőforrások lehetőségeit. Ez eredhet egy pozitív jellegű felhasználói érdeklődés miatt (egy jól sikerült marketing kampány miatt megugró érdeklődők száma, vagy az információk iránt érdeklődők 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ükből 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 felhő technológiák, mint a Windows Azure pont azt a lehetőséget biztosítják hogy meglegyen a gyors skálázódási lehetősé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 lehetőségeit vizsgáljuk, de a jellegükben a megnövekedett valós kérésekből eredő 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érő lehet. Az egyik leggyakoribb támadási forma hogy a célpontot olyan mennyiségű 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 kettő közti különbség hogy az első esetben a szolgáltatás összeomlik (pl.: egy sérülékenység kihasználásából eredő 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, erőforrások (pl.: sávszélesség, tárterület, CPU idő, 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 megfertőzö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 erőforrá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 egyszerű 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 működésüket, megnehezítve – gyakorlatilag lehetetlenné téve - a kizárólag támadó kiszűrésén alapuló védekezést. A DDoS támadások elleni védekezés egyik legjobb lehetősége, ha a szolgáltatás képes kiszolgálni a megnövekvő 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ékű 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 felhő 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 felhőben futtatni, az IaaS esetében pedig az ügyfelek számára virtuális gép futtatási lehetőségeket nyújt. A teljes mértékben saját infrastruktúrán futatott (on-premise) és a teljes mértékben a felhőből 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 szerződés (Enterprise Agreement – EA) alapján. Az EA konstrukció esetében egy előre 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érhetőek az alábbi linken: http://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 levő 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 belső és külső 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 szűrői, tűzfalai, 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: http://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 érkező vagy onnan kimenő 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 előre jelezni.

Védekezési lehetőségek Windows Azure használatával

A webes szolgáltatások elérhetősége több infrastruktúra komponenstől is függ, mint például az internet szolgáltatások (pl.: név feloldás), hálózat, tűzfal, terhelés elosztó, web front-end kiszolgálók, adatbázis. Ezek bármelyikének kiesése vagy szűk 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 szűk keresztmetszetet jelentő infrastruktúra komponensek az alábbiak szerint oszlottak meg:

A fentiekből látható hogy az internet kapcsolat sávszélessége, a tűzfal és behatolás védelmi megoldások és a terhelés elosztók (egy szóval a hálózati komponensek) jelentették a szűk 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 szűk 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 időtartama az alábbiak szerint alakul:

Arra vonatkozóan, hogy egy átlagos, nem DDoS támadásból, hanem megnövekedett érdeklődésből adódó túlterhelés időszak (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ínű, hogy jellemzőek egy DDoS támadás jellegű aktivitásra mint a megnőtt érdeklődésből eredő helyzetben, hiszen a DDoS támadások célja a kiszemelt célpont elérhetetlenné tétele, amely a legegyszerűbben a hálózati elérhetőség bedugításával sokkal kisebb befektetéssel elérhető 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ésekből adódó terheléseket is képes hálózatilag kivédeni. 

Védekezési lehetőségek áttekintése

A Windows Azure segítségével az alábbi lehetősé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 legegyszerűbb védekezést lehetővé tevő megoldás, mivel az Azure PaaS-ban megvalósított szolgáltatások estében a nagyobb igények kiszolgálására egyszerűen 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 egyszerűen 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 meglevő 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 első á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 vevő üzemelteti, nem a Microsoft, így olyan szoftver komponenseket telepít rá amilyenre szüksége (és licensze) van. Ez sokkal nagyobb rugalmasságot tesz lehetővé, hiszen így gyakorlatilag bármilyen Windows Server-en vagy Linux-on futó webes szolgáltatásunkat kiköltöztethetjük a felhőbe, és használhatjuk a felhő által nyújtott rugalmasság előnyeit.
  • 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 bővíthető 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 felhőbe, 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 levő tűzfalakon és terhelés elosztókon keresztül érhetőek el az internetről. 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 szűk 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 lehetősé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 meglevő kiszolgálók kapacitása kerül kibőví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 meglevő é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 felső limitje az elérhető legnagyobb Azure IaaS virtuális gép sablon, az oldalra skálázás felső 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 kezelhetősé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 megfelelő monitoring rendszerrel való integráció révén.

Az oldalra skálázódáshoz szükséges hogy legyen egy előre elkészített sablon gépek, amely sablon gép tartalmaz minden komponenst előre telepítve és konfigurálva, hogy kiszolgálják a publikus webes szolgáltatást. A másik lehetőség lehet, hogy az extra kapacitás igény kiszolgálására az lehet hogy a szükséges gépek előre el vannak készítve és konfigurálva, és kikapcsolt állapotban vannak. Ez a megoldás akkor javasolt, ha a szolgáltatás műkö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 előre elkészített, de kikapcsolt állapotban levő gépek száma sem elegendő akkor az további kapacitás bőví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 bővebb információk végett érdemes elolvasni a kollégám Michael Washam Virutális gépekről 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 jellemzőket és a publikusan elérhető 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öltő támadás alatt állunk és nézzük meg hogy mennyibe kerül az infrastruktúra fenntartása ami ellen áll erre az időre 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övő 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 levő DDoS támadások 80%-a kivédhető 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étől, időtartamától, az alkalmazás erőforrás igényeitől és az Azure szerződési konstrukciótól jelentős 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ágrendű 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éről, ami az év többi részében kihasználatlanul állna.

Az Azure extra kapacitás használatának nyilván előfeltétele a megfelelő előkészítés, és a szolgáltatások Windows Azure-ba átmozgatása, vagyis már a támadás előtt 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, hűté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érhetőségét, vagy azt hogy a szolgáltatás minden esetben garantáltan működőképes és elérhető lesz mindenki számára. Több ismert és ismeretlen faktor is kihatással lehet. Tájékoztató jellegű, nem teljes körű felsorolással ezek lehetnek például:

  • Windows Azure szolgáltatást érintő kiesések. A Microsoft a megfelelően kialakított IaaS virtuális gépek esetében 99,95%-os elérhetőséget vállal a vonatkozó SLA-ban: http://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övetkező hibákból eredő kiesések
  • Konfigurációs hibából eredő kiesések
  • Infrastruktúrát érintő 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 megfelelően, a megfelelő 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. 

Comments
  • Az eredeti ötletért jár valami? :)

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment