SYN-eláraszás elleni védekezés a RESPIRE algorimus segíségével Korn András Dr. Fehér Gábor Gyimesi Judi Budapesi Műszaki és Gazdaságudományi Egyeem Távközlési és Médianiformaikai Tanszék HSNLab A múlban sok ismer webszerver béníoak meg rosszindulaú felhasználók hosszabb-rövidebb időre egy SYN-eláraszás (SYN flood) néven ismer ámadás segíségével. Ezeknek a ámadásoknak a kivédésére öbb olyan módszer javasolak amely bevál és elerjed. Cikkünkben egy olyan újszerű megoldás ismereünk amely leheősége bizosí a SYN-áradaok auomaikus felismerésére és szűrésére anélkül hogy számoevő öbbleerhelés okozna az áldoza számára. Haékonyságá mind szimulációval mind numerikus analízissel igazoljuk. Bevezeő A TCP SYN-eláraszás a TCP-kapcsolafelépíés (handshake) egy sajáosságá használja ki. A kapcsolao kezdeményező kliens először olyan csomago küld a szervernek amelyen a SYN bi be van állíva egy kezdei szekvenciaszámmal. A szerver erre egy SYNACK csomaggal válaszol a sajá szekvenciaszámával. Végül a kapcsola lérejön amin a kliens visszaküld egy olyan csomago amelyben csak az ACK bi van beállíva és a szerver kezdei szekvenciaszámá nyugázza. Ahhoz azonban hogy a szerver el udja döneni hogy egy beérkező ACK üzene egy kapcsola-felépíés uolsó üzenee-e meg kell jegyeznie melyik kliensnek milyen kezdei szekvenciaszámú SYNACK csomago küldö. Ezek az adaok a TCP kapcsolapuffer (TCP backlog queue) nevű adasrukúrában ároldónak amelynek a méree véges (poronkén eseleg csak pár uca félig nyio kapcsola árolására elegendő). A SYN-árada során a ámadó nagyszámú SYN csomago küld gyakran hamis IP-címről ám egyik kapcsola felépíésé sem fejezi be ACK üzeneel így a szerver puffere megelik: nem képes új kapcsolaoka fogadni. A pufferben árol ún. félig nyio kapcsolaok egy idő uán (imeou) ha addig nem érkezik rájuk ACK örlődnek. Ám ha a ámadó csomagok gyorsan jönnek akkor eláraszják a ároló és az áldoza nem lesz képes a legöbb legiim kliens kérésének feldolgozására. Léező megoldások Egyes gyárók például a Cisco forgalmaznak a SYN-eláraszás ellen valamekkora védelme nyújó rouereke. Álalában ugyanaz a módszer alkalmazzák min az OpenBSD: a TCP-kapcsolafelépíés ők maguk végzik el és a véde szervernek csak akkor küldik el a SYN csomago ha ők maguk már megkapák a végső ACK-o. Ahhoz hogy a kapcsola működjön a ovábbiakban minden áhaladó csomagon módosíani kell a TCP-szekvenciaszámo (hiszen a rouer bizonyára más első szekvenciaszámo válaszo amikor a SYNACK-o külde min a szerver). Emelle ezek a rouerek hamarabb eldobják a félig nyio kapcsolaoka min a szerverek így valóban kevésbé érzékenyek a SYN-eláraszásra. Az azonban lánunk kell hogy a volaképpeni problémá nem oldják meg csupán megnövelik a ámadás kölségé mivel ovábbra is szükség van erőforrások (memória) allokálására minden félig nyio kapcsolahoz ezek az erőforrások pedig végesek. Egy másik javasol védelem alapja a SYN csomagok vélelenszerű eldobása (RED jelleggel) [RAD]. Hasonlóan a félig nyio kapcsolaok élearamának csökkenéséhez ez a megoldás sem nyúj valódi védelme csupán a ámadás kölségé növeli meg. A SYN-eláraszás elleni védekezés egy igen eredei és széles körben elerjed módja az ún. SYN cookie-k használaa [SCS]. A módszer lényege az hogy a szerver a sajá SYNACK csomagjában beállío szekvenciaszámba belekódolja azoka az információka amelyeke különben a helyi pufferben kellene árolni; így nincs szükség memória-allokációra csak néhány számíásra. A bejövő ACK csomag álal nyugázo szekvenciaszám segíségével a kapcsola helyi adasrukúrája felépíheő anélkül hogy a SYN és az ACK beérkezése közö bármi is árolnunk kellene. Annak érdekében hogy ez ne járjon azzal a veszéllyel hogy az algorimus ismereében egy ámadó helyesen megválaszo nyugaszámmal kapcsolao udjon hamisíani a beállío kezdő szekvenciaszámnak kripográfiai érelemben erősnek kell lennie; így a ámadónak csak nagy erőfeszíés (sok próbálkozás) árán sikerülhe érvényes nyugaszámo generálni.
A SYN-cookie-k hárányai Sajnos a SYN cookie-k használaa hárányokkal is jár. Először is az ilyen módon lérehozo kapcsolaok nem használhanak nagy ablakméree és a maximális szegmensmére sem válaszhaó meg szabadon. Másodszor az erős szekvenciaszám előállíása számíásigényes; Bernsein pl. a Rijndael kódoló használaá javasolja minden egyes SYNACK csomag szekvenciaszámának kiszámíására. Harmadszor és alán ez a legnagyobb probléma a SYN cookie-ka használó szerver a SYN-áradara SYNACK-áradaal válaszol: ha a SYN csomagok feladója hamis cím akkor a hamis címre vagyis egy mi sem sejő áralan harmadik félnek (bounce aack). Így annak ellenére hogy a SYN cookie-k még ámadás eseén is garanálják a szolgálaás elérheőségé ovábbra is van érelme a ámadók csomagjai szűrni (vagyis megakadályozni hogy eljussanak a szerverhez). Az i bemuao RESPIRE algorimus jó kiegészíése a SYN cookie-knak is; ezek szavaolják a szolgálaás zavaralanságá a RESPIRE mechanizmus pedig felderíi a SYN-árada forrásai és kiszűri őke. (RESPIRE: Resource Efficien SYN-flood Proecion for Inerne Rouers and End-sysems Erőforráshaékony SYN-árada elleni védelem az Inerne hoszjai és rouerei számára). Mivel azonban a RESPIRE reakcióideje igen rövid a SYN cookie-kra elegendően nagy kapcsolapuffer meglée eseén volaképpen nincs szükség. Az irodalomban öbb módszer is alálunk a folyamaban levő SYN-eláraszás felismerésére; az újabb algorimusok egyiké az Olvasó a [DSF]-ben alálhaja meg. Ennek a módszernek az a háránya hogy a ámadás elleni védekezéshez csak akkor nyúj hahaós segísége ha a ámadó közelében lehe elhelyezni az az eszköz amely megvalósíja; ez lényegében az jeleni hogy minden Inerne-szolgálaónál be kellene vezeni. Amíg erre nem kerül sor vagy ha az eszköz az áldoza közelében helyezzük el az algorimus csak felismerni képes a ámadás az azonban nem udja megállapíani melyik állomás küldi az áradao. A RESPIRE rendszer elve Az i javasol módszer nem igényli ovábbi adagyűjő eszközök elhelyezésé. Azoka az adaoka használjuk fel a ámadás felismerésére amelyeke az áldozanak amúgy is gyűjenie kell ahhoz hogy TCP szolgálaás legyen képes nyújani. Az alábbi adaok mind rendelkezésre állnak (vagy könnyen előállíhaók) és alkalmasak a ámadás felismerésére vagy legalábbis valószínűsíésére az alábbi feléelek eljesülése eseén: a másodpercenkén beérkező SYN csomagok száma meghalad egy küszöbéréke; valamely TCP por kapcsolapuffere (backlog queue) megelik SYN cookie-ka kell küldeni a ovábbi kapcsolaok fogadásához; a félig nyio kapcsolaok száma meghalad egy küszöbéréke; arányalanul öbb SYNACK csomag hagyja el a rendszer min ahány kapcsola-felépíés véglegesíő ACK csomag érkezik (a ovábbiakban ACK üzeneen mindig ilyen csomago érünk). A RESPIRE i leír válozaa az uóbbi heurisziká alkalmazza azonban minimális módosíásokkal akár az összes módszer kombinációja is használhaó. Megjegyezzük hogy leheséges lenne a bejövő SYN és bejövő ACK üzeneek számának arányá is vizsgálni. A SYNACK üzeneekben küldö szekvenciaszám ismereére mindenképpen szükségünk van a számolandó ACKüzeneek azonosíásához a SYNACK üzene alapján pedig rekonsruálhaó a hozzá arozó SYN így a SYN-ek számolása redundánsnak űnhe. Hozzá kell azonban ennünk hogy ahhoz hogy a SYNACK-ok számolására alapozhassuk a védelme az áldoza képes kell hogy legyen a bejövő SYN-ek elegendően nagy részére SYNACKkal válaszolni. Ez a SYN-cookie-k garanálják ha azonban nem használunk SYN-cookie-ka akkor a kapcsolapuffer méreé kell úgy megválaszanunk hogy a RESPIRE számára elegendő SYNACK üzene ermelődjön a puffer megelése elő. Ha ez sem leheséges akkor számolhajuk a SYN-üzeneeke a SYNACK-ok helye ám a SYNACK-okkal ekkor is foglalkoznunk kell a szekvenciaszámok mia. Összefoglalva: a SYNACK-üzeneek helye akkor célszerű a SYN-üzeneeke számolni ha a védendő szerver nincs felkészíve SYN-cookie-k használaára és a kapcsolapuffer méreé sem udjuk elegendően nagyra beállíani. Támadáskor egy leheséges védekezés ha nem válaszolunk azokra a SYN csomagokra amelyeke a ámadó küld; ez a legegyszerűbben úgy bizosíhajuk hogy űzfalunkban kiszűrjük őke. Tehá a legfonosabb dolgunk izolálni a ámadás forrásai. (Ennél öbbe csak akkor eheünk ha pushbackkel [PSB] vagy más hasonló mechanizmussal a ámadó csomagjai álal használ úvonalon a ámadó felé oljuk a szűrés.) A ámadó kiszűrése az Inerne hőskorában gyakorlailag leheelen le volna mivel a csomagok forráscímei szabadon hamisíhaóak volak. Mosanra azonban a legöbb hálózaból nem engednek ki olyan csomago amelynek az állíólagos feladója nem 2
része a hálózanak. Emia a ámadók álalában csak sajá C oszályú hálózaukon belüli címeke udnak használni. Globális szolgálaás nyújó szerverek eseében ennek az egész arománynak a szűrése is csak elenyészően kevés legiim kliens érinhe hiszen nagyon kedvező az arány az összes léező és a ámadó álal használ hálózaok száma közö. Megjegyezzük hogy a feni feléelezés alapfeléele a RESPIRE működésének; ha a ámadó eszőleges forráscíme képes lenne hamisíani a RESPIRE még ronhana is a helyzeen mivel legiim klienseke is kiszűrhe a ámadás vél forrásának kiilása során. Ennek a veszélye számoevő mérékben csökkenheő ha a RESPIRE- csomaghamisíás-érzékelővel (spoof deecor) pl. a [HCF]-ben leír algorimussal kombináljuk. A SYN-ámadások anaómiája Napjainkban az ilyen ámadások során a ámadó álalában öbb uca olyan számíógépről ún. zombiról küldi a SYN-áradao amelyekre korábban beör. Ezeken a gépeken eloszo ámadások megvalósíására kifejlesze programoka helyez el amelyeke egyszerű uasíásokkal képes ávvezérelni. Hogy az árada szűrésé megnehezísék a zombik álalában hamisío forráscímekről küldik a csomagoka; a fen leírak mia azonban mindegyik hamisío forráscím ugyanahhoz az IP-alhálózahoz arozik min a zombi ényleges címe. Megjegyezzük hogy amennyiben a bejövő SYN-árada sávszélessége elegendően nagy ahhoz hogy az áldoza vonalá elíse már nincs érelme SYN-ámadásról beszélni; a ámadás olyan álalános kapcsola-elíő ámadás amely öréneesen TCP SYN csomagoka használ. Nem célunk ezzel az eseel foglalkozni noha a pushbackkel kombinálva a bemuao RESPIRE algorimus az ilyen ámadások ellen is haásos lehe. Ki a ámadó? Korábban már ualunk arra hogy SYN-árada eseén a kimenő SYNACK csomagok és a bejövő kapcsolafelépíés véglegesíő ACK csomagok aránya sokkal nagyobb lesz egynél. Mivel a legöbb válasz nélkül maradó SYNACK csomago éppen a ámadó SYN-csomagjaira ado válaszkén küldjük el a ámadó úgy alálhajuk meg ha megkeressük az(oka) a hálózao(ka) amely(ek)nél nagy az egy érvényes bejövő ACK csomagra eső kimenő SYNACK csomagok száma. Erre egy leheséges naiv módszer az lenne ha egy nagy (2 24 azaz 67 millió sor aralmazó) áblázaban számolnánk hogy hány SYNACK csomago küldünk az egyes C oszályú hálózaokba ill. hogy hány ACKo küldenek ezekből nekünk. Jól láhaó hogy ez a megoldás nem lenne haékony: a legöbb számláló a nullán állna és a poziív érékeke muaó számlálópárok öbbsége is normális ( körüli) arány ükrözne. A ámadó azonosíásához mégis az összes sor meg kellene vizsgálnunk (egy ámadó megalálásához álagosan minegy nyolc és fél millió sor). A RESPIRE működése A RESPIRE alapöleé szolgálaó MULTOPS[MPS] ez a problémá úgy oldja meg hogy a számlálóka dinamikusan bővíheő hierarchikus adasrukúrában egy 256-odrendű fában árolja kihasználva az IP-címek hierarchikus jellegé. A RESPIRE-ben a fa gyökere ké kezdeben nulla érékű számláló és 256 darab kezdeben NULL muaó aralmaz. Az egyik számláló a neve Synack_Ou a rendszer elhagyó SYNACK üzeneeke számolja a másik Ack_In nevű pedig a beérkező hieles ACK csomagoka (azoka amelyek egy TCP-kapcsola felépíésé véglegesíik). Miuán legalább Synack_Min darab SYNACK csomago küldünk ki minden ovábbi Synack_Period darab csomag uán inkremenáljuk a megfelelő számlálóka és megvizsgáljuk a árol érékek arányai. Min az később láni fogjuk a fasrukúra mia ez aránylag olcsó művele; így az javasoljuk hogy Synack_Period éréke legyen. Olyan szervereken amelyeken különösen nagy forgalomra számíunk a paraméer éréke növelheő a öbbleerhelés csökkenése érdekében; ez azonban ronja az algorimus ponosságá és reakcióidejé. A deerminiszikus minavéelezés helye ermészeesen alkalmazhaunk valamilyen szochaszikus módszer is vagy válozahajuk a paraméer éréké dinamikusan (pl. a forgalomól függően) ez azonban a lényege nem érini. Amin a fasrukúra gyökérelemében Synack_Ou és Ack_In aránya meghaladja a válaszo -nél nagyobb R max paraméer éréké (.5 körül javasoljuk megválaszani; az alacsonyabb érékekhez jobb reakcióidő arozik ám növelik a évedés valószínűségé) feléelezzük hogy SYN-eláraszás áldozaai vagyunk és megkezdjük a kiküldö SYNACK csomagok célcímeinek figyelésé a ámadók felismerése érdekében. Ezekhez arozó levelekkel bővíjük a fá a kövekező módon: Minden ovábbi Synack_Period darab kimenő SYNACK vagy bejövő ACK csomag eseén megjegyezzük a ávoli IP-címe: legyen ez A.B.C.D. Amennyiben a gyökér A-adik muaója NULL lérehozunk egy új csúcso és 3
befűzzük a gyökér alá (roo A). A ovábbiakban minden az A.0.0.0/8 hálózaal összefüggő SYN/ACK forgalma ké helyen számolunk: a gyökérben és az imén lérehozo új csúcsban. Ha roo A már léezik megvizsgáljuk igaz-e hogy roo A Synack_Ou Synack_Min A roo A Synack_Ou > roo A Ack_In Amennyiben mindez eljesül valószínűsíheő hogy az A.0.0.0/8 hálóza reji a(z egyik) ámadó. A fá a feni algorimussal ovább bővíjük amíg az A B C levél lére nem jön. A Synack_Min paraméer éréke különbözhe a fa egyes szinjein. Ha a fában lefelé haladva csökkenjük a paraméer éréké a ámadások felismerése gyorsul a ponosság azonban romlik; ez ellensúlyozandó növelhejük pl. R max éréké. Amennyiben az A B C levél léezik már legalább Synack_Min C SYNACK csomago gyűjö és számlálóinak aránya meghaladja R max -o feléelezzük hogy az A.B.C.0/24 egy ámadó ellenőrzése ala áll és forgalmá a ovábbiakban kiszűrjük (pl. az operációs rendszer beépíe csomagszűrője segíségével). Célszerű ezeke a szűréseke egy idő (Block_Timeou) uán megszüneni. Az álalunk megfigyel SYNámadások nem aroak 5 percnél ovább így ez az éréke javasoljuk. A ámadás megszűnének érzékeléséhez lehene ugyan néhány drága heuriszikával próbálkozni min például az újraküldö SYN-ek felismerése ennél azonban sokkal gazdaságosabb a szűrés ámenei megszüneésével kipróbálni vége ér-e a ámadás. Amennyiben a ámadás folyaódik ermészeesen újra felismerjük és újabb 5 percre kiszűrjük (i is leheséges lenne valamilyen adapív viselkedés bevezeése). Ha alálunk és kiszűrünk egy ámadó alhálózao a hozzá arozó levele örölhejük a fából mivel már nem fogunk innen SYN csomago kapni; számlálóinak éréké levonjuk a fában fölöe levő csúcsok számlálóiból. Ha a gyökérben még ezuán sem áll helyre az arány ovábbi ámadók is léezhenek. További opimalizációs leheőség az imén elávolío csúcsok újbóli lérehozása a szűrés feloldásakor hogy gyorsabban udjunk reagálni ha a ámadás még nem ér volna vége. Prune_Inerval másodpercenkén (2-nél alacsonyabb érék nem javasol) megvizsgáljuk van-e gyanús csúcs a fában (ehá olyan ahol a számlálók hányadosa nagyobb R max -nál de ahol Synack_Min- még nem érük el). Az összes nemgyanús csúcso öröljük a gyanúsaknak pedig nullázzuk a számlálói. Ezzel memóriá és későbbi feldolgozási idő akaríunk meg. Megjegyezzük hogy a örlendő csúcsok kiválaszására összeeebb algorimus is használhaunk amely pl. figyelembe veszi hogy az ado csúcsban hogyan válozo a számlálók aránya az előző Prune_Inerval ala; a RESPIRE alapöleének megéréséhez azonban elegendő az i bemuao naiv módszer. Egy összeeebb algorimus a lassú áradaok lejjebb ismeree problémájának megoldásában segíhe. Azálal hogy a gyanús csúcsoknak csak nullázzuk a számlálói de a csúcsoka nem szünejük meg az ado alhálózaból érkező ámadó a kövekező Prune_Inerval ala hamarabb megaláljuk mivel nem kell megvárnunk amíg a szülő-csúcsokban összegyűlik Synack_Min csomag: az alacsonyabb szinű csúcs eleve léezik. Az összeeebb algorimusra vonakozó feni megjegyzések i is megállják a helyüke. A számlálók nullázására azér van szükség mer csak a énylegesen folyamaban levő ámadásokra akarunk reagálni. Sajnos azonban így a ámadó lassú áradaok ( slow flood ) segíségével elkerülhei az észlelés. Ha rendkívül sok különböző C-oszályú hálózaból küld másodpercenkén kevesebb min Synack_Min C /Prune_Inerval csomago akkor a fa gyökerében ugyan lájuk hogy ámadás ala vagyunk de a ámadó folyamok egyenkén nem okoznak akkora forgalma hogy a fa alsóbb szinjein is elérjék Synack_Min- a számlálók a nullázás elő; együes haásukra mégis beelik a kapcsolapuffer. Ebben az eseben egy leheséges reakció a kövekező: a gyanús csúcsok számlálói nem öröljük Prune_Inerval lejárakor; ovábbá finomíjuk a gyanússág megíélésé. Minden gyanú fele áll az olyan csúcs amelyben a számlálók aránya R legi -nél alacsonyabb (javasol érék pl. vagy 05). Az ilyeneke öröljük a fából az inervallumhaárokon. Enyhén gyanúsak azok a csúcsok amelyekben az arány R legi és R max közöi: ezeke nem öröljük csak nullázzuk és ovábbi megfigyelés ala arjuk. Azon csúcsok számlálói pedig amelyeknél az arány meghaladja R max éréké még csak nem is nullázzuk. Arra számíunk hogy így idővel lesz olyan C szinű csúcs amely a szűrés feléelei eljesíi. Az. ábrán egy háromszinű RESPIRE-fá láhaunk. Az egyes csúcsokban levő oszlopok a SYNACK és ACK csomagok relaív számá muaják (nem ponos számérékeke). A 92.0.0.0/8-as és a 96.0.0.0/8-as csomópon közel ugyanannyi ACK csomago küldö amennyi SYNACK-o kapo ehá valószínűsíheően legiim. A bal oldalon R max és 4
láhaó söéebb háerű csúcsok viszon nagyon is gyanúsak. Vegyük észre hogy a gyökér is gyanús ebből kövekezeheünk a ámadás ényére. 0 gyökér h level 0.0.0.0 A s szin level A szin level A szin level 7.0.0.0 92.0.0.0 96.0.0.0 B szin 7.85.0.0. ábra: példa egy RESPIRE-fára A RESPIRE memóriaigénye Mivel dinamikus adasrukúrákkal dolgozunk el kell kerülnünk hogy maga a RESPIRE rendszer DoS-ámadás eszköze lehessen: korláoznunk kell a memóriahasználaá. Egy csúcs memóriaigénye 32 bies archiekúrán (2+256) 32 bi (a ké számláló plusz a 256 muaó). Ez összesen 032 bye. Ha nem korláoznánk a lérehozhaó csúcsok számá összesen legfeljebb 677726 + 65536 + 256 darab csúcsunk lehene (ez a fennaro IParományok elhanyagolása mia nem úl ponos felső becslés); így a eljes RESPIRE adasrukúra méree elérhené a 625 gigabájo aminek a kezelése már nehézkes. A lérehozandó csomóponok száma a gyanús (ámadó) alhálózaok számáól függ. Nem valószínű hogy egyelen ámadó készáznál öbb C-oszályú hálózao ellenőrizne. A legkedvezőlenebb ese az ha ez a készáz C-hálóza mind különböző A-hálózaban alálhaó ekkor ugyanis mindegyik áradaforráshoz három csomópono kell lérehoznunk összesen ehá haszáz darabo (minegy 600 kilobye). Álalában elegendőnek űnik öszázra korláozni a lérehozhaó csúcsok számá; érelemszerűen ha rendkívül eloszo ámadásokra számíunk ez a korlá növelheő. Ha elérük a korláo de új csúcso kellene lérehoznunk egy leheséges eljárás az hogy megkeressük a gyökér legkevésbé gyanús gyermeké és öröljük a hozzá arozó részfával együ. Ha csak egyelen A-csúcsunk van folyassuk a keresés az A-szinen; az egyelen A-csúcsnak bizonyosan egynél öbb gyermeke lesz mivel különben nem érheük volna el az öszázas korláo. Idővel feleheően izolálunk egy ámadó és csökken majd a csúcsok száma. Analízis a RESPIRE reakcióideje Először álalános közelíés adunk az algorimus reakcióidejére majd pedig felső haáréréke. Láni fogjuk hogy a RESPIRE még a legrosszabb eseben is gyorsan reagál (így a SYN cookie-k használaa nem felélenül szükséges) ráadásul az észlelés ideje szemponjából a kis inenziású áradaok jelenik a legrosszabb esee: minél nagyobb az árada inenziása annál gyorsabban ki udjuk szűrni. Jelen analízis arra az esere vonakozik amikor a ámadók ha öbben vannak azonos C alhálózaban vannak. A számíások álalánosíhaók összeeebb ámadásra is kivéve a lassú árada eseé ami már árgyalunk. Felesszük hogy a rosszindulaú SYN csomagok egyenleesen érkeznek ψ csomag/sec inenziással. Ha öbb ámadó van akkor haásuka összegződve aralmazza ez az érék. A legiim kliensek SYN forgalma Poissonfolyamaal közelíheő mivel a ámadáson kívül időegységenkén érkező csomagok száma függelen egymásól. Az egyszerűség kedvéér felesszük hogy a SYNACK válaszcsomago a szerver a SYN kézhezvéelével egy időben kiküldi így a kimenő SYNACK csomagok is Poisson-eloszlás muanak. Ugyanez érvényes a beérkező ACK csomagokra is mivel bár az egy szakaszban bejövő ACK-ok nem az abban a szakaszban kimenő SYNACKokra ado válaszok de a darabszámuk várhaó éréke megegyezik hiszen Poisson-folyamanál csak a vizsgál időinervallum hossza és nem a kezdőideje számí. Az RTT (Round Trip Time) figyelembevéele ugyan bonyolíhaná a helyzee de ha nincsen komoly burs-ösödés akkor nem okoz nagy hibá a közelíés. A ámadás kezdeé aól az időponól számoljuk amikor a szerverhez ér az első rosszindulaú SYN csomag. Ezzel az adaal kapcsolaban csak az számí hogy mennyi idővel van egy Prune_Inerval kezdee uán: legyen ez Δ. A ovábbiakban Δ idő múlva már ψ Δ ámadó SYN csomag érkeze. Hogy eközben mennyi legiim kapcsolakezdeményezés örén az a kövekező módon haározhajuk meg: az egy időinervallumban beérkező legiim csomagok számának várhaó éréke λ l Δ. Ugyanennyi SYNACK-o küld ki a szerver és közel ennyi ACKnak is kell visszaérkeznie. A RESPIRE mechanizmusa szerin ké feléelnek kell eljesülnie hogy felismerje a ámadás ényé: 5
λl + ψ R λ l max λ + ψ synack_ min és l roo Lászik hogy jelen feléelezések melle az első egyenlőlenségben az arány nem függ az időől ámadás eseén ennek mindig eljesülnie kell. Tehá ha egy ámadás deekálhaó akkor felismerjük amin a minimális SYNACK éréke elérjük az ado Prune_Inerval-ban ( ). p A deekálhaóság feléele pedig a megfelelő arány amiből a ámadás inenziására a kövekező adódik: ψ R λ ( ) max l Minden szinre hasonló gondolamene köveheő min a gyökér eseén azzal a különbséggel hogy az egyes szinekre a legiim forgalomnak csak valamekkora hányada ju el. Ha feléelezzük hogy minden alhálózaból azonos mennyiségű csomag jön az egy A alhálózaból érkezők csak kb. az /256-odá eszik ki az egész beérkező forgalomnak B-nél ennek négyzeé C-nél köbé. Ez ermészeesen nem lesz igaz mivel a kliensek IP-címeinek eloszlása nem egyenlees. Az A szinen még közelíőleg sem az mivel a eljes címér jelenős része speciális célokra van fennarva. Sajnos azonban még a B szinen sem éelezheünk fel egyenlees eloszlás: Magyarországon például a 95-el kezdődő IP-címek második okeje nagy valószínűséggel 228 sb. Bevezehenénk a φ(x) paraméer úgy hogy φ(x) a bejövő összes legiim SYN csomagnak az x alhálózara eső részé jeleni. Közelíésnek azonban elfogadhajuk az a megoldás hogy A szinen valamilyen a paraméerrel számolunk a B és C szinen pedig egyenleesnek vesszük az eloszlás. Ha szinenkén másképp válaszouk meg Synack_Min- akkor ez is figyelembe kell venni. Könnyen beláhaó hogy hosszabb idő szükséges ha a csomagszámlálás közben álépünk egy Prune_Inervalhaár és örlődnek a számláló-érékek. Ekkor csak az ado szin számlálása kezdődik újból hiszen maguka a csomóponoka nem öröljük. Szinenkén csak egy haárálépés leheséges ugyanis ha a csomópon gyanússágának eldönéséhez öbb min egy inervallumnyi időre volna szükség akkor a vizsgála soha nem fejeződne be. A szinenkén szükséges időre a második felismerési feléel alapján a kövekező képle adhaó ha haárálépés sehol nem örénik: synack min _ roo roo λl + ψ synack_ A min l a λ + ψ synack_ B C A minb λl + ψ a 256 synack_ minc λ 2 l + ψ a 256 Ha az inervallumhaár-álépéseke is figyelembe vesszük akkor a feni közelíésekkel élve az alábbi módon fejezheő ki az algorimus reakcióideje a fa egyes szinjein (I{A} az A esemény indikáora): 6
+ I roo = roo < + p roo p p p + + + + I roo roo A = < roo A + p roo p p A p + + + + + I roo A roo A B + + = roo A B < + p roo A B p p p + + + + + + + + + = I roo A B < roo A C roo A B C + p roo A B C p p p Ha az előző szin vizsgálaának vége és az akuális szin vizsgálaának vége külön inervallumba esik akkor a szükséges idő a eljes ehhez a szinhez szükséges inervallumálépés nélküli idő plusz az előző szin vizsgálaának végéől az inervallumhaárig elelő idő. A eljes reakcióidő a fa egyes szinjein elölö idő összege: T = roo + A + B + C Felső becsléskén nézzük a reakcióidő szemponjából legrosszabb esee amely mivel a reakcióidő deekálhaó ámadás eseén csak a Synack_Min eléréséől függ akkor kövekezik be amikor minden legális SYN csomag más A alhálózaból jön min a ámadó csomagok. Ebben az eseben nem kell semmiféle feléelezéssel élnünk a forgalom eloszlásával kapcsolaban. Az érékek a kövekezők szerin váloznak: synack = min _ szin szin ψ Az egyes szineken ölö idő felülről becsülheő az álépés nélküli ese idejének készeresével hiszen ha a vizsgála nem fejeződik be az inervallum-haárig akkor az indikáorfüggvény uáni szorzó kisebb min Δ szin ellenkező eseben a vizsgála befejeződhee volna abban az inervallumban amelyben kezdődö. 2 szin Tehá az algorimus eljes reakcióideje nem haladhaja meg a legöbb idő igénylő szin álépés nélküli idejének négyszeresé: synack _ min szin T 8max szin ψ A formulából jól lászik hogy minél nagyobb inenziású a ámadás annál gyorsabban reagál a RESPIRE. Min már ualunk rá ez a felső becslés csak a különösen kis inenziású ámadások udják megközelíeni. ψ egyre nagyobb érékeinél egyre kisebb a valószínűsége hogy keőnél öbb inervallum kellene a ámadó hálóza azonosíásához ugyanis a nagyon gyors ámadások felismerési ideje 0-hoz ar. A második inervallum csak akkor szükséges ha a ámadás egy inervallum végéhez közel kezdődik. Szimuláció Az algorimus eljesíőképességé szimulációval is vizsgáluk [RSP]. A kép eljessé éele érdekében röviden e helyü is összefoglaljuk a szimuláció eredményei. Egy nagy forgalmú SMTP-szerver szimulálunk álagosan 628 folyamaban levő legiim kapcsolaal és 26 új kapcsolakéréssel másodpercenkén. A legiim kliensek IP-címe eljesen vélelenszerű vol. A rendszerben elhelyezünk nyolc ámadó akik vélelen időponban vélelen inenziású SYN-áradaal ámadák meg a szerver; a rendelkezésükre álló alhálóza méree szinén vélelenszerű vol /24-es alhálózai maszkól /6-osig. Az alhálózaukon belül vélelenszerűen válaszoak forráscíme minden egyes ámadó SYN csomaguknak egy ámadáson belül is válogava az. A szimuláció néhány számszerű eredményé az alábbi ábláza foglalja össze: ' szin 7
Támadás sorszáma Első csomag (s) Alhálóza méree Csomagráa (csomag/s) Elfogado csomagok Reakcióidő (s) 80780 32768 4274 229 0629 2 239046 52 9938 505 00 3 764754 4096 58563 920 0045 4 890803 52 8203 505 00 5 229573 6384 39586 6766 0244 6 2039080 892 40932 3535 00 5* 229699 6384 39586 6767 065 6* 293957 892 40932 3535 03 7 4060253 32768 88895 323 093 8 4729277 52 3267 505 002 Láhajuk hogy a áblázaban az öös és a haos ámadás készer is szerepel; ennek az a magyarázaa hogy a űzfalszabály maximális élearamá 900 másodpercre (5 perc) állíouk be ezek a ámadások pedig ennél hosszabb ideig aroak. A szabály elévülése uán ismé fel kelle őke ismerni és kiszűrni. Az elfogado csomagok oszlopban alálhaó érékek az adják meg hány az ado ámadóól származó hamis SYN csomag ére el a szerver a ámadás kiszűrésének pillanaáig; a öbbi oszlop jelenése remélheőleg egyérelmű. A reakcióidő ekineében megállapíhajuk hogy az azonos mérékben eloszo de nagyobb inenziású ámadások kiszűréséhez szükséges idő álalában kisebb vol; a közel azonos csomagráájú ám eloszoabb ámadás kiszűréséhez szükséges idő pedig álalában nagyobb. Elvégezünk néhány próbaszámíás is hogy összevessük az analízis eredményei a szimulációéival. Vegyük a 3. ámadó. Ő 4096 címből álló aromány ellenőriz; ez 6 darab szomszédos C oszályú hálózao jelen. Így egyszerre 6 gyanús C szinű csúcsunk lesz a fában mind azonos B csúcs ala. Egyenlees címkiválaszás feléelezve minden C csúcsba a eljes inenziás /6-od része ju vagyis 36609 csomag/s. A B szinig ehá alkalmazhajuk az egy ámadó aloszály feléelező analízis eredményé: synack _ min szin Troo + TA + TB 6 max = 00 szin= roo AB ψ A C csúcsok felismerésénél pedig egyenkén 83009 csomag/s ámadó inenziással számolva: synack _ minc TC 2 = 0.055 ψ Az összes időre ehá az analízis alapján a feni ké eredmény összegé 0065s-o kapunk ami jó felső becslése a mér éréknek. Nagyságrendileg ehá megegyezik a ké módszer álal muao eredmény. Hasonlóképpen az. ámadás álal kiválo reakció idejének felső becslésére 0635s-o a 2.-éra 00s-o a 4.-ére 002s-o az 5.-ére 0338s-o a 6.-éra 07s-o a 7.-ére 0293s-o a 8.-éra pedig 0032s-o kapunk. Természeesen előfordulha hogy nem azonos a válaszo hamis IP címek eloszlása és eseleg egy C alhálózao hamarabb felismerünk min egy másika. Ha vannak olyan alhálózaok amikben lényegesen kisebb az inenziás akkor az összidő növekedhe. Vegyük észre azonban hogy ez lényegé ekinve az az ese amikor a lassú ennélfogva veszélyelenebb ámadásoka később ismerjük föl hiszen a aromány öbbi részé már ilouk így az áldozao énylegesen elérő ámadó forgalom kisebb inenziású lesz. Érékelés A fen ismeree RESPIRE algorimus nem az egyelen amely a SYN-áradaok elleni védelme szolgálja ám késégkívül az egyik legkisebb járulékos számíásigényű módszer ami megbízhaóan gyorsan szűri ki a ámadás; ezenkívül részben védelme nyúj az ellen is ha a szerver használják kisebb sávszélességű áldozaok kapcsolaelíésére ( bounce aack ). A SYN-ámadások elleni védelem öbbi eszközének elsősorban a SYN cookie-k kiegészíésekén is hasznos. Memóriaigénye is csak ámadás eseén nő meg néhány kilobájnyinál nagyobbra. A fejleszés korai fázisában levő linuxos referenciaimplemenáció elkészüle uán éleszerű körülmények közö is kipróbálhaó lesz az algorimus. C 8
Irodalomjegyzék [ACC] Raul Mahajan Seven M. Bellovin Sally Floyd John Ioannidis Vern Paxson Sco Shenker Conrolling High Bandwidh Aggregaes in he Nework Compuer Communicaions Review 32:3 July 2002 pp. 62-73. [HCF] Cheng Jin Haining Wang Kang G. Shin Hop-Coun Filering: An Effecive Defense Agains Spoofed DDoS Traffic Proceedings of he 0 h ACM conference on Compuer and communicaion securiy 2003 pp. 30-4. [SCS] Daniel J. Bernsein SYN cookies hp://cr.yp.o/syncookies.hml 997. [DSF] Haining Wang Danlu Zhang Kang G. Shin Deecing SYN Flooding Aacks Proceedings of IEEE InfoCom 2002 [PSB] John Ioannidis Seven M. Bellovin Implemening Pushback: Rouer-Based Defense Agains DDoS Aacks Nework and Disribued Sysem Securiy Symposium February 2002. [RAD] Livio Ricciulli Parick Lincoln and Pankaj Kakkar TCP SYN Flooding Defense Comm. Ne. and Dis. Sysems Modeling and Simulaion Conf. (CNDS' 99) 999. [MPS] Thomer M. Gil Massimiliano Poleo MULTOPS: a daa-srucure for bandwidh aack deecion Proceedings of he 0 h Usenix Securiy Symposium Augus 200. [RSP] Gábor Fehér András Korn RESPIRE a Novel Approach o Auomaically Blocking SYN Flooding Aacks Proceedings of EUNICE 2004 pp. 8-87 9