A szolgáltatásmegtagadás típusú támadások anatómiája

Hogyan, és a rendszer mely pontjain történhet egy szolgáltatásmegtagadás típusú támadás? Nemcsak erre kapunk választ a cikkből, hanem arra is, hogy milyen eszközökkel tudjuk a DoS, DDoS-támadásokat letesztelni.

Cikkem a szolgáltatásmegtagadással járó támadások (Denial of Service: DoS) technikai hátterét igyekszik bemutatni. Egyrészt körüljárom, mit is értünk DoS és DDoS (Distributed DoS) támadás alatt. Később kicsit mélyebbre merészkedve ismertetem, miért is lehetségesek ezek a támadások, és technikailag hogy működnek. Végül számba vesszük a védekezés lehetséges módjait az elérhető leginnovatívabb megoldásokat kiemelve.

A szolgáltatásmegtagadással járó támadások lényege, hogy egy vagy több támadó a kliensek számára elérhetetlenné tesz olyan szolgáltatásokat, amelyeket a felhasználók el szeretnének érni. Érdekességként megjegyezhetjük, hogy amennyiben több támadó hajtja végre a támadást, azt jellemzően a támadó eszköz (ami speciálisan erre a célra létrehozott szoftver) együttes koordinált futtatásával szokták megtenni. Erre legemlékezetesebb példa az Anonymous csoport által létrehozott LOIC (ami a “Low Orbit Ion Cannon” rövidítéséből származik), amivel a Szcientológia Egyház, a RIAA (amerikai kiadók jogvédő szövetsége), illetve a Wikileaks-et támadó szervezetek ellen indítottak támadást.

A továbbiakban hálózati szolgáltatásokról lesz szó, illetve arról, hogy azok miért válhatnak elérhetetlenné. Ennek oka lehet többek között, hogy a hálózaton keresztül küldött kérések nem jutnak el a szerverig, vagy a szerver nem tudja azokat feldolgozni. Az okok között szerepelhet a sávszélesség, egy köztes hálózati eszköz, vagy a szerver időszakos túlterhelése, illetve a szerveren futó valamely szoftver (web-szerver, adatbázis-kezelő, webes alkalmazás) összeomlása és leállása. Ennek megfelelő sorrendben dolgozzuk fel a támadások jellegét. Hogy ne csak az elméleti fejtegetés szintjén maradjunk, az egyes témákhoz olyan eszközöket ismertetek amivel adott esetben az olvasó tesztelheti saját alkalmazása és infrastruktúrája ellenállóságát a DoS illetve DDoS támadásokkal szemben.

A hálózati szinten végrehajtott támadást az teszi lehetővé, hogy a jelenleg leginkább használatos hálózati protokoll kombináció a TCP/IP alapja a szerver és a kliens között egyfajta kommunikációs csatorna (TCP socket) felépítése. Ennek során az ún. TCP 3 utas kézfogás (three-way handshake) játszódik le. De mi történik, ha a kliens soha sem küldi el a harmadik lépést jelentő TCP csomagot? A létrejött socket-hez mind a szerveren, mind a köztes hálózati eszközök egy részén erőforrások kötődnek le (memória, CPU idő). Ezek csak akkor szabadulnak fel, ha lejár a beállított várakozási idő (time-out), és a szerver felszabadítja az erőforrásokat. Infrastruktúra szinten ez a következőképpen néz ki: a kliensek (pl. a támadók) és a szerver között elhelyezkedik az internet infrastruktúrája, továbbá a szerver IP-címét biztosító internet-szolgáltató routere(i), a szervert üzemeltető cég vagy szervezet ezen felül jó esetben tűzfalat, IDS-t, esetleg IPS-t is üzemeltet. Ezek bármelyikét érintheti a szolgáltatásmegtagadás és szűk keresztmetszetté válhatnak.

hping3 nevű programocska, amit megfelelő paraméterezéssel (–flood) hívva a gyakorlatban csak a sávszélesség szabhat határt. A védekezés kézenfekvő módja a rendelkezésre álló erőforrások növelése, vagy a félig nyitott TCP-kapcsolatok esetén érvényes várakozási idő csökkentése lehet. Erre a modern hálózati eszközök lehetőséget adnak. Belátható, hogy ezzel a módszerrel a támadás erőforrásigényét ugyan növelhetjük, de nagyságrendi változást ezzel nem érünk el. A nagyságrendi változáshoz merészebb megoldás szükséges, amire a cikk vége felé fogok kitérni. A forráscímek blokkolása intelligens támadók ellen a gyakorlatban nem megfelelő megoldás, mivel az IP-csomagokban található forrás IP-cím hamisítható. Egy támadó ezt épp az eredeti céljára is kihasználhatja, ugyanis ha a forráscímet következetesen egy meghatározott IP-re vagy címtartományra hamisítja, az fog kitiltódni. Az említett hping3 is tud forráscímet hamisítani, de nem árt tudni hogy értelmesebb routerek nem engedik tovább az olyan kimenő IP-csomagokat, melyek nem az IP-csomagban található forrás címnek megfelelő tartományból származnak.

Hasonló elvet alkalmazva az alkalmazás-rétegbeli HTTP-protokoll szintjén is eláraszthatóak a szerverek túlterhelést okozó kérésekkel. Az előbbi bekezdésekben ismertetett TCP szintű támadást szokás SYN flood-nak nevezni, ennek megfelelően a HTTP szintű támadást hívhatjuk például GET vagy POST flood-nak. A web-szerverek általában a beérkező egyes HTTP-kérések kiszolgálásához külön-külön processzeket és/vagy thread-eket (ennek részleteire most nem térünk ki, aki akar, utána olvashat) hoznak létre, ami szintén erőforrás (CPU, memória) lekötésével jár. A teljes képhez hozzátartozik, hogy a web-szerverek természetesen limitálják a párhuzamosan kiszolgálható HTTP-kérések számát. A gyakorlatban ez néhány száz párhuzamos TCP-kapcsolatot jelent alapértelmezésben (pl. Apache webszerver esetében 150 a kliensek alapértelmezett maximális száma egy időben). Továbbá egy TCP-kapcsolat felett egymás után több HTTP-kérést is lehet küldeni (a keep-alive HTTP header paraméter használatával), így a TCP-kapcsolat ismételt felépítésére és lebontására használt TCP-csomagok megspórolhatóak a sávszélesség jobb kihasználtságát elősegítve. Amennyiben a támadók tartósan kimerítik a web-szerver számára engedélyezett kapcsolatokat, a tényleges felhasználókhoz tartozó klienseket a web-szerver nem fogja kiszolgálni. Ebből a web-böngésző előtt ülő normál felhasználó egy néhány perces várakozást, és végül a böngészőben definiált várakozási idő lejárta után egy hibaüzenetet érzékel. Ha ezt a gyakorlatban ki szeretnénk próbálni, az Apache JMeter nevű eszközzel megtehetjük, ami grafikus felülettel és parancssorból is futtatható.

Két trükkösebb lehetőséget ismertetnénk a következőekben, melyek a HTTP-kérések feldolgozása során elkövethető hibákat igyekeznek kihasználni. Mindkét trükk lényege, hogy egy HTTP-kérés feldolgozását a lehető leghosszabb ideig próbálják elnyújtani. Minden HTTP-kérés egy header-t tartalmaz, ami a feldolgozásával kapcsolatos információkat és előírásokat tartalmazhat, a POST kérések ezen felül még meghatározott formátumú adatokat tartalmaznak, ezeket a szervernek fel kell dolgoznia a kérés kiszolgálásához.

A HTTP header elküldését elnyújtva a web-szervert hosszú várakozásra készteti a Slowloris nevű eszköz ( http://ha.ckers.org/slowloris/ ), ami egy perl nyelven írt programocska. A trükk lényege, hogy a befejezetlen HTTP-kéréseket intéz a szerverhez, meghatározott időnként egy újabb részletet elküldve a headerből, ami így nem fogy ki a türelemből elég gyorsan. Amennyiben tesztelnénk ezt a fajta támadást, érdemes figyelembe venni, hogy különböző web-szerver implementációk másféleképpen dolgozhatják fel a különféle HTTP-kéréseket. Például adott esetben egy GET kérés befejezése előtt egy adott típusú web-szerver nem biztos, hogy ténylegesen lefoglalja az adott kérés kiszolgálásához rendelt erőforrásokat. Ellenben ha például a POST kéréseket másképp kezeli, így mégis lehetséges hogy kimeríthetőek az erőforrások. Hasonló eszközök a PyLoris, QSlowloris és a slowhttptest.

A RUDY (r-u-dead-yet) nevű eszköz ( http://www.hybridsec.com/tools/rudy/ ) tulajdonképpen egy python nyelven írt programocska. A HTTP POST kérések tartalom (content) részét küldi lassan, darabonként a szervernek, így késztetve azt várakozásra. Az eszköz parancssorból és konfigurációs állományból is paraméterezhető, még kényelmesebbé teszi használatát, hogy egy URL-t megadva felismeri a POST paramétereket, és egy menüből kiválaszthatjuk, melyikkel próbálkozzon.

Maguk a webes alkalmazások is sebezhetőek lehetnek DoS támadásokra, amennyiben olyan funkciókat támogatnak, melyek jelentős terhelést okozhatnak a háttérfeldolgozást végző rendszerekben. Gondolhatunk itt például összetett lekérdezésekre, vagy háttértár I/O igényes feldolgozásokra. Ha egy támadónak sikerül ilyen funkciót azonosítani, viszonylag egyszerűen okozhat komoly problémákat a szerver üzemeltetőknek. Egyes alkalmazásoknál a nem megfelelő naplózás is okozhat problémákat a szolgáltatások felhasználóinak. Ha például a naplófájlok az alkalmazásszerveren helyezkednek el és a háttértár megtelik, az alkalmazást futtató operációs rendszer is tartósan működésképtelenné válhat. Ez a probléma elsőre banálisnak tűnhet, de a gyakorlati tapasztalatok alapján régóta élesben futó webes alkalmazások is tartalmazhatnak ilyen hibákat. Ilyen jellegű problémák teszteléséhez az Apache JMeter kitűnően alkalmazható.

A problémák után foglalkozzunk a védekezési lehetőségekkel is röviden. Elméletileg tökéletes védelem nincs, mivel a gyakorlatban csak a sikeres támadáshoz a támadó számára szükséges erőforrásigényt növelhetjük. A modern hálózati eszközök tartalmazhatnak védelmet a DoS ellen, például a TCP 3 utas kézfogást egy router is kezelheti: például a félig nyitott TCP-kapcsolatokat még nem továbbítja a tényleges szervernek. Ha belegondolunk, könnyen belátható, a védekező eszközön a támadás erőforrásokat köt le, tehát a védekezésre fordított erőforrások is kimeríthetőek. A már említett forrás IP kitiltás alapú védelem is számos tűzfalban megtalálható, a gyakorlatban ilyenkor a gyanúsnak ítélt IP-címek egy rövid időre kitilthatók. Itt a probléma a gyanús tevékenység detektálásával és a kitiltás idejével lehet. A gyakorlatban ilyenkor normális tevékenységet folytató IP-című eszközök is kitiltódhatnak, ha “túl sokszor” próbálnak a szerverhez csatlakozni egy adott időintervallumban. Emiatt szokott a tiltás rövid ideig élni. Ez esetben végiggondolhatjuk a támadó megfontolásait: egy időintervallumban csak annyit indít egy forrás IP-ről, ami még nem triggereli a kitiltást, továbbá a forrás IP-k számát addig növeli, amíg a támadás sikeres lesz.

A már hivatkozott innovatív megoldáshoz képzeljük el, hogy nem csak a támadó használhat számos forrás IP-t, a védekezést is tehetjük elosztottá. Ha a kliensek felől érkező forgalmat egy nagyszámú speciális hálózati eszközből álló “felhőn” irányítjuk keresztül, továbbá a felhő elemei egyenként képesek a támadások észlelésére és a védekezésre, a támadó dolgát nagyságrendileg nehezíthetjük meg. Így a támadónak már az egész felhőt kell kiiktatni a kis számú router, tűzfal és szerver helyett, hogy a támadás sikeres legyen. Egy ilyen infrastruktúrát nyilván nem érdemes minden cégnél üzemeltetni, viszont léteznek szolgáltatók (Verizon – Terremark, Verisign, CloudFlare, Incapsula), akik ilyen védelmet tudnak nyújtani.

Végezetül szót ejtenék a DoS sebezhetőség tesztelésével kapcsolatos saját tapasztalatokról. A nagyszámú támadó modellezésére ma már kézenfekvő megoldásként alkalmazható bármely cloud szolgáltató infrastruktúrája. Személyesen az Amazon EC2 cloud szolgáltatásával vannak gyakorlati tapasztalatim. Itt egy regisztráció és hitelkártyaszám megadása után 7 régióban (európai, 3 észak-amerikai, dél-amerikai, kettő ázsiai) régiónként 20 virtuális géppel (az összesen 140 hoszt) szimulálhatjuk a támadók botnet-jét. Természetesen figyelembe kell venni, hogy a távoli régiók esetében a sávszélesség kisebb, és a hálózat késleltetése nagyobb lehet, de a tapasztalatok alapján nagy léptékű támadások szimulációja oldható meg némi idő, és néhány száz dollár ráfordításával.

Szerző:Major Marcell