Hálózati támadások és férgek elleni védekezési mechanizmusok

Hálózati támadások és férgek elleni védekezési mechanizmusok Korn András okleveles mérnök-informatikus PhD-értekezésének összefoglalója

Témavezető: Dr. Fehér Gábor PhD

Nagysebességű Hálózatok Laboratóriuma Távközlési és Médiainformatikai Tanszék

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Informatikai Tudományok Doktori Iskola

Budapest, 2011.

1 Bevezetés A hálózatbiztonság fontosságát aligha kell hangsúlyozni. Ahogy a számítógép-hálózatok egyre jobban áthatják életünket, és egyre több embert érnek el, ezek az emberek pedig egyre kevesebbet tudnak a hálózatok működéséről, ezen hálózatok biztonsága kritikus jelentőségűvé válik. Disszertációmban két új hálózatbiztonsági algoritmust mutatok be, valamint egy új, gráfokban használható centralitásmércét. Az első algoritmus, a WANDA, lehetővé teszi, hogy hálózatok autonóm módon vagy együttműködve felismerjék a pásztázó férgeket. Legvonzóbb tulajdonságai közé tartozik az egyszerű implementálhatóság; az erőforrás-takarékosság; a téves riasztásoknak a szolgáltatásonként különböző küszöbértékeknek köszönhetően alacsony száma; és az, hogy képes akár a széles körben elterjedt NetFlow-adatok, akár egy kapcsolatkövető tűzfal kapcsolat-nyilvántartása alapján is működni. A második algoritmus, amely a RESPIRE nevet kapta, a tűzfalak meglevő kapcsolatkövető képességeit felhasználva gyorsan észleli a SYN-áradatokat, azonosítja azok forrásait és megfelelő tűzfalszabályok létrehozásával kiszűri az áradatot. Más, a SYN áradatok szűrését célzó megoldásokkal szemben a RESPIRE-t elegendő az áldozatra, vagy annak közelébe telepíteni. A RESPIRE alacsony erőforrásigény mellett kiküszöböli a syncookie algoritmus [39] hátrányait. Végül javaslatot teszek egy új centralitásmérce, a lobbi-index bevezetésére, valamint meghatározom az eloszlását különféle generált ill. a valódi életből vett gráfon. Egy csomópont lobbiindexének meghatározása pusztán lokális információ (a szomszédok fokszáma) alapján is lehetséges, így rendkívül olcsó művelet. A centralitásmércék megkísérlik számszerűsíteni egy-egy gráfcsomópontnak a gráfon átáramló bizonyos tulajdonságokkal bíró folyamok szemszögéből vett „fontosságát”. Számos bevett centralitásmérce létezik, de ezek többségének meghatározásához az egész gráfot ismerni kell (ilyen pl. a „closeness”, a „bridgeness” és az „eigenvector” centralitás); ezen túlmenően látszólag egyik sem igazán releváns a skálafüggetlen gráfokban terjedő fertőzések szempontjából [36]. A lobbi-index azokhoz a csomópontokhoz rendel nagy mérőszámot, amelyeknek sok nagy fokszámú szomszédja van, így különösen alkalmasak arra, hogy egy immunizáló (vagy fertőző!) ágenst terjesszenek, ill. hogy immunizációjukkal hatékonyan akadályozzák egy fertőzés továbbterjedését a gráfnak azon részeibe, amelyek rajtuk keresztül érhetők el. A skálafüggetlen gráfok immunizációjával kapcsolatban fontos kihívást jelent, hogy ha egy fertőzés eljut a „gazdagok klubjába” (a gráf rendkívül sűrűn összekapcsolt magjába), megállítása szinte lehetetlen. Mivel magas lobbi-indexű csomópontból kevesebb van, mint magas fokszámúból, és ezek gyakran a gráf magjának „kapui”, gyors immunizálásuk gátat szabhat a járványok kialakulásának. Noha egyelőre bizonyításra vár, hogy a lobbi-index erre a célra valóban megfelelő, független kutatók már találtak a számára alkalmazásokat úgy az ad-hoc hálózatok, mint a keresési eredmények sorbarendezése terén.

2 Kutatási célkitűzés Természetesen hatalmas irodalma van a jelen disszertációban érintett témáknak; részletes bemutatására a tézisfüzetben terjedelmi okokból nincs lehetőség, de a disszertáció mintegy huszonöt oldalt szentel ennek a célnak. Összefoglalásképpen: a kutatók által javasolt új hálózatvédelmi megoldások gyakran a létező infrastruktúra nehezen megvalósítható megváltoztatását igénylik ([19], 2

[43], [45], [47]); vagy annyira összetett algoritmusokat/matematikát használnak, hogy helyes implementációjuk kihívás ([18], [40], [45]); vagy nagy erőforrásigényűek ([19], [41], [42], [47], [49]); vagy az Internet egészének részvételét igénylő globális együttműködésre alapoznak ([40], [19], [45], [52], [53]); vagy szabadalmi védelem alatt állnak ([34]); vagy figyelmen kívül hagyják a valóság valamely fontos aspektusát ([44]); vagy csak részben oldják meg a problémát ([46], [48], [49], [50], [54]); vagy azon az áron oldják meg a problémát, hogy bevezetésük új gondokat okoz ([39], [51], [46]). Így a gyakorlatban többnyire nehezen alkalmazhatóak. Hosszú távon természetesen értékesek és hasznosak ezek az eredmények, én azonban olyan megoldásokat próbáltam találni, amelyeket autonóm módon (globális együttműködés nélkül), akár azonnal is be lehet vezetni. Szándékosan nem szabadalmaztattam egyik általam kitalált megoldást sem. Az volt a célom, hogy lehetővé tegyem az Interneten jelenleg is széles körben használt SYN támadások elleni védekezést, valamint hogy javítsam a hálózat ellenállóképességét a fertőzésekkel (férgekkel) szemben. A SYN támadások és a férgek tekintetében arra törekedtem, hogy olyan egyszerűen megvalósítható, csekély erőforrásigényű védelmi mechanizmusokat találjak, amelyeket a védendő eszközökön vagy közelükben kell telepíteni úgy, hogy ehhez a létező infrastruktúra minél kisebb mértékű módosítása legyen szükséges. A szoftveres megvalósíthatóság könnyűsége (az algoritmusok és adatszerkezetek egyszerűsége) fontosabb volt, mint az optimalizálás. Olyan kis memóriaigényű algoritmusokat kerestem, amelyek bemenetét a legtöbb hálózatban eleve rendelkezésre álló adatok képezik. Arra is törekedtem, hogy algoritmusaim hasznot húzhassanak több hálózat együttműködéséből anélkül, hogy függnének tőle. Célom volt továbbá, hogy az Internet – ill. pontosabban a skálafüggetlen overlay hálózatok – architektúráját ellenállóbbá tegyem. A lobbi-index (l. a 3. tézist) a hálózat csomópontjainak „fontosságát” olyan módon méri, hogy a magasabb lobbi-indexű csomópontokat hamarabb immunizálva jobban korlátozható a járványok terjedése (vagy legalábbis ezt remélem bebizonyítani).

3 Kutatási módszertan Az informatikai biztonsággal kapcsolatos eredmények gyakran két élesen eltérő módszer valamelyikének kizárólagos alkalmazásával születnek. Az egyik módszer tisztán tudományos: egy absztrakt és leegyszerűsített modell segítségével keresnek megoldást egy vélt vagy valós biztonsági hiányosságra. Ezek a megoldások általában nagyon ígéretesnek tűnnek papíron, ám gyakorlati megvalósításuk esetleg nehézségekbe ütközik. A másik módszert azok az emberek szokták alkalmazni, akik a számítógép-hálózatok és az általuk nyújtott szolgáltatások mindennapi üzemeltetéséért felelősek és gyakran saját maguk tapasztalják, észlelik a biztonsági hiányosságokat – nem ritkán akkor, amikor már késő. Megpróbálnak ad-hoc megoldásokat találni a problémákra, ám ezek többnyire nem tökéletesek, valamint formális vizsgálatuk, általánosításuk is nehézkes. Úgy gondolom, mindkét megközelítésnek vannak fontos előnyei, ezért megkíséreltem kombinálni őket, saját üzemeltetői tapasztalatom felhasználásával. Olyan hálózatbiztonsági kérdéseket kerestem, amelyekkel az üzemeltetők nap mint nap találkoznak, és megpróbáltam rájuk olyan válaszokat adni, amelyek nemcsak a gyakorlatban állják meg a helyüket, hanem tudományos szempontból is érdekesek.

3

Ezen túlmenően azzal szembesültem, hogy a vírusokkal szembeni immunizáció szempontjából releváns centralitásmérce tekintetében [36] az adott problémával kapcsolatos alapkutatásra is szükség volt. Olyan problémákkal foglalkoztam, amelyekkel a valódi életben is gyakran felmerültek, ami azt sugallta, hogy nem volt rájuk elegendően jó megoldás. Kiderült, hogy más kutatók már tettek kísérletet a megoldásukra, de a megoldások ilyen vagy olyan okból nem bizonyultak tökéletesnek; lehetségesnek tűnt azonban, hogy javítsak rajtuk, vagy újszerű módon kombináljam őket annak érdekében, hogy jobb vagy praktikusabb megoldás jöjjön létre. Ha sikerült ilyen megoldást találnom, a következő módszerek legalább egyikével vizsgáltam meg: • Formális módszerekkel, feltéve, hogy ez lehetséges. A formális analízis segítségével megmutatható, hogy algoritmusok rendelkeznek a tőlük elvárt tulajdonságokkal; valamint adhatók korlátok bizonyos paraméterekre. Előfordul azonban, hogy a vizsgálandó modell annyira összetett, hogy a formális analízis irreálisan sokáig tartana. Matematikai módszerrel mutattam meg, hogy a RESPIRE gyorsabban reagál a nagyobb intenzitású támadásokra; szintén formális módszerrel határoztam meg a lobbi-index eloszlását skálafüggetlen gráfokban. • A formális analízishez túl bonyolult modellek gyakran vizsgálhatók eredményesen szimulációval. Szintén a szimuláció a logikus választás akkor, ha a valódi megvalósításon végzett mérés túl drága vagy nehezen megszervezhető lenne. A paraméterterek szisztematikusan bejárhatók a szimulációk automatizálásával; könnyen szimulálhatunk továbbá a valóságban csak ritkán előforduló eseményeket. Például igen nehéz lett volna a WANDA viselkedését valós körülmények között tanulmányozni: nemcsak számítógépek ezreire lett volna szükség, hanem arra is, hogy ezek némelyikét féreg fertőzze meg. Mindez a szimuláció során gyerekjáték volt. Szintén nem állt rendelkezésemre sem több tucat valódi C osztályú hálózat, amelyekből SYN támadásokat indíthattam volna a RESPIRE ellen, sem akkora sávszélesség, amely másodpercenként százezer SYN-csomag szállítására elegendő lett volna; így ezeket a kísérleteket szintén szimulátorban kellett elvégezni. • Végezetül megpróbáltam prototípusokat fejleszteni és módszereimet a valóságban is kipróbálni. A valós tesztek során fény derülhet olyan aspektusokra, amelyeket a szimuláció figyelmen kívül hagyott, vagy arra, hogy a szimuláció valamely feltevése helytelen volt. A RESPIRE esetében például nehéz lett volna analitikusan megállapítani, hogy a syncookie-k által igényelt kriptográfiai műveletek megspórolásán nyert processzoridő elegendő-e a RESPIRE futtatására (ráadásul a processzor kontextusváltásainak hatását is figyelembe kellett volna venni); így erre a kérdésre mérések adtak választ.

4 Új tudományos eredmények 4.1

A WANDA (Worm ANomaly Detector Algorithm) algoritmus

Az elmúlt évtizedben a férgek állandó fenyegetést jelentettek a számítógépek számára. A 2000-es évek első felében a legelterjedtebb felhasználói operációs rendszerekben egyik távolról kiaknázható biztonsági hiányosságot tárták fel a másik után; és ha ez nem lett volna elég, a férgek alkotói mindig számíthattak (és ma is számíthatnak) az emberek kíváncsiságára és hiszékenységére.

4

„Egyre kevésbé hatásosak a rosszindulatú kód észlelésére használt hagyományos technológiák – például a víruskeresők”, írja a Check Point Software ([37]), majd így folytatja: „A vírusok által okozott anyagi kár az 1995-ös 500 millió dollárról 2004-re 16,7 milliárd dollárra nőtt.” 2005-re, amikor a WANDÁ-t publikáltam, a férgek elleni védekezés rendkívül fontossá vált. Mint azt megállapítottuk, akkori védekezési módszereink nem voltak képesek a férgek megállítására, amit mi sem bizonyított jobban, mint hogy szinte havonta megjelent egy új, világszerte gépek tízezreit megfertőző (és többmillió dolláros károkat okozó) féreg. A víruskeresők többnyire még ma is főként szignatúrák segítségével ismerik fel a rosszindulatú programokat. Egy új féreg még akkor is képes lenne az Internet jelentős részét megfertőzni, ha a víruskeresők terjesztői percekkel az első fertőzés után megkezdenék egy új féreghez tartozó szignatúrák terjesztését (ami lehetetlen). A Sl@mmer féreg például az összes létező, a fertőzésre fogékony rendszert működése első 10 perce alatt megfertőzött; eleinte 8,5 másodpercenként duplázódott a fertőzött gépek száma [34]. Elképzelhetetlen, hogy egy új féreg szignatúráit ilyen hamar létre lehetne hozni. Mindebből arra kell következtetnünk, hogy a férgek elleni háborút lehetetlen a felhasználók számítógépein megnyerni1; kénytelenek vagyunk tehát magát a hálózatot a férgek elleni védekezésre felkészíteni, mégpedig úgy, hogy ne legyen szükség szignatúrák központi előállítására és terjesztésére. A hálózati védekezés azért is kecsegtet nagyobb sikerrel, mert hálózati eszközből kevesebb van, mint felhasználói végpontból, és mert a hálózati eszközöket általában magasabb színvonalon üzemeltetik, mint a munkaállomásokat. Javaslatot teszek egy WANDA („Worm Anomaly Detector Algorithm”, vagyis féreganomáliaészlelő algoritmus) nevű algoritmusra, amelynek segítségével jelentős mértékben korlátozható az új és ismeretlen pásztázó férgeknek az a képessége, hogy más számítógépeket megfertőzzenek. Noha a közelmúltban nem jelent meg újabb pásztázó féreg, elvileg minden további nélkül megjelenhetne egy akár holnap; így a WANDA potenciálisan ma is hasznos, annak ellenére, hogy az a veszély, amelyet csökkenteni hivatott, most éppen nem tapintható. 1. téziscsoport: kifejlesztettem egy olyan algoritmust, amelynek a segítségével egy autonóm hálózat szignatúrák használata nélkül, pusztán hálózati viselkedésük alapján felismerheti a pásztázó férgeket. Kifejlesztettem ennek az algoritmusnak az elosztott változatát, amelynek a segítségével több önálló (al)hálózat együttműködhet a férgek felismerése érdekében, ezzel javítva a karanténmechanizmus hatásosságát, valamint csökkentve a felismeréshez szükséges időt és az egyes észlelők memóriaigényét. Az algoritmus mindkét változata izolálja és karanténba helyezi a fertőzött végpontokat anélkül, hogy a legitim hálózati forgalmat akadályozná (kivéve, ha a legitim forgalom ugyanazt a szállítási rétegbeli portot használja, mint a féregterjedés), ezáltal megakadályozva a férget a terjedésben. Szimulációk segítségével megmutattam, hogy a WANDA hatásos. A WANDA a férgek elleni harcon túlmenően a portscan-ek és a hálózat-letapogatás felismerésére is alkalmas. 4.1.1

A WANDA autonóm változata

1.1-es tézis: kifejlesztettem a „Worm Anomaly Detector Algorithm”, röviden WANDA algoritmust, amelynek vannak előnyei más, a féregterjedést korlátozó megoldásokkal szemben. Kapcsolódó publikációk: [C6]2[C7][C8]. Az autonóm WANDA fő előnyei az irodalomban szereplő, a disszertációban részletesen tárgyalt más megoldásokkal szemben a következők: autonóm működés (nem igényel elosztottságot; nem függ globális együttműködéstől); nem igényel nagyszámú használaton kívüli IP-címet (ún. darknetet);

5

bevezetése nem igényli a meglevő infrastruktúra nagyarányú megváltoztatását (a legtöbb útválasztó és számos kapcsoló által rendelkezésre bocsátott NetFlow-adatok alapján is képes működni, de kapcsolatkövető tűzfallal is könnyedén integrálható); erőforráshatékonyság; egyszerű megvalósíthatóság. A WANDA működése (kicsit leegyszerűsítve) az alábbi; az algoritmus pszeudokódja megtalálható a disszertáció A függelékében. Maga a terjedés, ill. annak megkísérlése eredményez olyan hálózati forgalmat, amelynek a révén a féreg jelenléte felismerhető [18]. Ezzel kapcsolatos kutatásaim idején a férgek – hálózati szemszögből nézve – két különböző módon terjedhettek aktívan3. Az egyik módszer az, hogy e-mailben elküldik magukat egy sor címzettnek egy központi SMTP-kiszolgáló segítségével. A másik módszer – a pásztázás – lényege az, hogy rengeteg hálózati címre próbálnak kapcsolódni és vagy kiaknázni egy biztonsági hiányosságot a távoli számítógép szoftverében, vagy a távoli gépen futó SMTP-kiszolgáló segítségével kézbesíttetni egy a férget tartalmazó levelet. A pásztázó férgek okozta forgalomra tehát az a jellemző, hogy egy végpont vagy alhálózat rengeteg különböző távoli rendszeren próbál ugyanazon néhány tucat jól ismert port valamelyikére kapcsolódni. Ennek felismeréséhez nyilván kell tartanunk, milyen rátával kapcsolódnak a megfigyelt hálózat végpontjai újabb és újabb címekre minden egyes jól ismert porton. Ezt megtehetjük úgy, hogy a MULTOPS-hoz [35] és a 2. téziscsoportban bemutatott RESPIRE-hez hasonlóan 256-odfokú „számlálófákat” építünk, kihasználva az IP címterének hierarchikus voltát. Az algoritmus egy-egy ilyen fát használ minden megfigyelt célporttal kapcsolatos forgalom vizsgálatára. A fa segítségével követjük nyomon, milyen rátával kapcsolódik a megfigyelt végpontok összessége új célcímekre az adott porton, úgy, hogy ha az A.B.C.D IP-re próbál kapcsolódni egy végpont, akkor létrehozzuk az A→B→C→D levelet a fában (feltéve, hogy még nem létezik). Ezután csak azt kell figyelnünk, milyen rátával jönnek létre a fa levelei. Ha a megfigyelt hálózat „újcélcímrátája” együttesen meghalad egy küszöbértéket valamely p port esetében, a WANDA létrehoz egy-egy új célcímeket számláló fát minden olyan végponthoz, amely a p porton kezdeményez hálózati kapcsolatot. Ezen fák segítségével azonosíthatók azok a konkrét végpontok, amelyek miatt az aggregált forgalom gyanúsnak találtatott. (Az algoritmus részletesebb leírását l. a disszertációban.) Ha egy végpont újcélcím-rátája meghalad egy küszöbértéket, fertőzöttnek tekintjük és lehetőleg a hozzá legközelebbi hálózati kapcsolónál kiszűrjük a tőle származó, a p portra irányuló csomagokat. Ezen a módon a leghatásosabban a megfigyelt hálózaton belüli férgekkel szemben tudunk fellépni; megakadályozhatjuk, hogy más belső vagy külső végpontokat fertőzzenek meg. Nagyon hasonlóan járhatunk el, ha a hálózatunkon kívülről érkező fertőzési kísérleteket szeretnénk észlelni és meghiúsítani. Az imént bemutatott módszerrel figyeljük, időegységenként hány új belső címre irányuló kapcsolatfelépítési kísérlet történik az Internet egésze részéről a megfigyelt portok valamelyikén4; valamint azt, időegységenként hány új forráscím kísérel meg kapcsolatot felépíteni ezen portok valamelyikével bármelyik belső végponton. Ha a két ráta bármelyike túllép egy küszöbértéket (amelyet az ismert trendek és szezonális hatások figyelembevételével kell megállapítani), alapos okunk van arra gyanakodni, hogy az Interneten féregjárvány van kitörőben. A fő különbség a hálózatunkon belül és kívül észlelt féreg között az, hogy az utóbbi esetben értelmetlen a konkrét fertőzött forráscímek azonosítására törekedni. Elegendő megállapítani, mely C osztályú címtartományokból érkeznek a fertőzést megkísérlő csomagok (így az erre a célra létrehozott fában három hierarchiaszint is elegendő). Ha fertőzöttnek vélt forrás-hálózatot találtunk, megtehetjük,

6

hogy az innen a fertőzésterjesztéssel összefüggő portra irányuló kapcsolatkéréseket elutasítjuk (vagy akár a teljes, az adott alhálózatokból érkező forgalmat kiszűrjük). Ha azonban a kérdéses port valamely fontos nyilvános szolgáltatásé (pl. a 80-as TCP port), mérlegelnünk kell, a szolgáltatás rendelkezésre állását fontosabbnak tekintjük-e, mint a fertőzés veszélyének csökkentését. Mindenképpen értesíteni kell az üzembentartókat, hogy az automatika által hozott döntést felülbírálhassák, ha szükséges. 4.1.2

Elosztott működés

1.2-es tézis: Megalkottam a WANDA elosztott változatát, és szimulációk segítségével megmutattam, hogy reakcióideje alacsonyabb az autonóm változatnál. Az egy WANDÁ-t futtató észlelőre jutó memóriaigény az elosztott esetben szintén alacsonyabb, mint ha ugyanazt a hálózati forgalmat egyetlen autonóm észlelő elemezné. Kapcsolódó publikációk: [C7][C8]. A WANDÁ-ban fontos szerepe van egy önkényesen megválasztott gyanúküszöbnek (amely azt adja meg, legfeljebb mekkora rátával kapcsolódhatnak új célcímekre a megfigyelt hálózat végpontjai). A küszöbérték megfelelő megválasztása nem egyszerű feladat. Gondot okozhat továbbá, hogy nagy forgalmú, több ezer végpontot számláló hálózatok megfigyelésekor az algoritmus által használt adatszerkezetek mérete viszonylag nagyra nőhet (több tíz, vagy akár több száz megabájtnyira). Mindkét problémát enyhíthetjük úgy, hogy számos észlelőt használunk, amelyek a teljes forgalomnak csak bizonyos részeit elemzik. Ha a megfigyelt hálózat hierarchikus felépítésű, természetes felosztás kínálkozik: minden alhálózatot lássunk el saját észlelővel. Egyéb esetekben az egyes észlelők felelősségi körét tetszőlegesen választhatjuk meg. Az észlelés reakcióidejét javíthatjuk úgy, hogy a gyanúküszöböt „lazítjuk”: lényegében két, saját küszöbértékkel rendelkező gyanakvási szintet vezetünk be. A magasabb küszöbértéket nevezhetjük vörös riasztási küszöbnek; ennek valahányad része a sárga riasztási küszöb. Ha valamely észlelő sárga riasztást ad ki, megszavaztatja5 a többi észlelőt, legyen-e vörös riasztás; ha egy előre megadott számú észlelő már kiadott sárga riasztást az adott portra, az egész elosztott észlelőhálózat azonnal kiadja a vörös riasztást akkor is, ha az ahhoz tartozó küszöbértéket még sehol sem érték el. Itt feltételezzük, hogy a féregjárványok kitörése többnyire nem elszigetelten történik; ha tehát több független alhálózat is ugyanazt az enyhén gyanús viselkedést mutatja, nagyobb magabiztossággal tippelhetünk féregjárványra, mint ha csak egyetlen alhálózat viselkedik furcsán – utóbbit okozhatja akár egyetlen, szokatlan tevékenységet folytató felhasználó vagy hibás alkalmazás is. Sárga riasztás esetén az észlelő már nyomon követi az egyes végpontok kapcsolódási rátáit (nemcsak a teljes alhálózatét); így a fertőzött végpontokat hamarabb azonosíthatjuk, ha elérjük a vörös riasztási küszöböt. Ezen túlmenően, mivel a végpontokhoz tartozó gyanúküszöb gyakran lehet alacsonyabb, mint az alhálózatokhoz tartozó, már most találhatunk gyanúsan viselkedő végpontokat, amelyeknek az adott portra irányuló további forgalmát kiszűrhetjük6. Noha ezt a logikát nem valósítottam meg az alább tárgyalt szimulátorban (csak a kétféle riasztást és a szavazást; a bonyolultabb logika csak a [C8] szimulátorába került bele), könnyen belátható, hogy csökkenti a WANDA reakcióidejét. Mivel egy-egy észlelő a teljes forgalomnak csak valamekkora hányadát vizsgálja, evidens, hogy kevesebb memóriára van szüksége, mint egy olyan észlelőnek, amely a teljes forgalmat analizálja.

7

4.1.3

Szimulációs eredmények

1.3-as tézis: szimulációk segítségével megmutattam, hogy a WANDA autonóm és elosztott változata is alkalmas a pásztázó férgek terjedésének korlátozására. Kapcsolódó publikációk: [C7][C8]. Szimulációk sorát végeztem el, hogy megmutassam: a férgek valóban létrehozzák az elméleti megfontolások alapján jósolt forgalmi anomáliát, és hogy a WANDA képes észlelni azt, majd korlátozni a férgek terjedését. Megjegyzem, hogy nem volt célja a [C7]-ben publikált és itt ismertetett szimulációknak a WANDA teljes paraméterterének aprólékos bejárása: egyetlen olyan tipikus, valószerű helyzetet szimuláltam, amelyben a WANDA dolga különösen nehéz. A szimulációk célja egyrészt az volt, hogy bebizonyítsák az algoritmus hatásosságát, másrészt az, hogy összehasonlítható legyen az autonóm és az elosztott működés teljesítőképessége. Mielőtt a szimulációt ismertetném, szeretném bevezetni a következő jelöléseket: legyen U[x;y] egy egyenletes eloszlású, az [x,y] intervallumba eső valószínűségi változó; legyen továbbá exp(x) egy exponenciális eloszlású, x várható értékű valószínűségi változó. A szimulált hálózat egy néhány ezer végpontot tartalmazó egyetemi hálózatra hasonlított. A szimulált végpontok mindegyike 20 alhálózat valamelyikében kapott helyet; mindegyiküknek volt valamekkora legitim forgalma azon a porton, amelyen a szimulált féreg is terjedt. A legitim forgalom paramétereit úgy állítottam be, hogy a kliensek viszonylag sok különböző szerverhez kapcsolódjanak; így a gyanúküszöbnek is magasnak kellett lennie, ami növelte az algoritmus reakcióidejét. A szimulált hálózat 20 alhálózatából egy 50, egy pedig 200 végpontot tartalmazott; a többi egyenként U[100;240]-et. A csomagtovábbítási idő exp(0,01) másodperc volt. Kizárólag a féreg által is használt TCP portra menő forgalmat szimuláltam. A szimulált topológia lapos volt: minden, az Internet felé tartó adatcsomag pontosan egy észlelőn haladt át, míg a belső alhálózatok közötti kommunikáció mindig két észlelőt érintett. Három esetet szimuláltam: az elsőben az észlelők nem működtek; a másodikban autonóm módon működtek; a harmadikban elosztott módon együttműködtek. A szimuláció kezdetét követő negyedik óra elején egy a Code Red-re hasonlító generikus féreggel fertőztem meg két, különböző alhálózatba tartozó végpontot. A szimulált féreg 10 perces paraméterű Poisson-folyamatként működött. Aktív állapotban U[0;20] véletlenszerűen választott címre próbált terjedni, amelyek mindegyike ugyanabban a véletlenszerűen kiválasztott C osztályú hálózatban volt. Felváltva próbált belső és külső alhálózatokba terjedni (a Code Red 2 és a Nimda viselkedése hasonló volt). Minden megtámadott számítógép 20% eséllyel volt fertőzhető a támadás pillanatában. Ez igen nagyvonalú érték: egyetlen féreg sem fertőzte meg soha az Internet 20%-át. A legitim forgalmat olyan állapotgép szimulálta, amely exp(1) órán át inaktív volt, majd exp(5) percig „dolgozott”; ebben az állapotban U[0;8] különböző távoli szerverhez kapcsolódott egyszerre, majd exp(1) perc szünetet tartott. A szimuláció 8 szimulált óra elteltével ért véget. Az 1. és 2. ábrán egy 200 végpontot tartalmazó alhálózat forgalma látható. Kékkel jelöltem, hány különböző távoli kiszolgálóhoz kapcsolódtak az alhálózatban levő végpontok percenként. A szürke vonal mutatja, hány fertőzött végpont található az alhálózatban. A szaggatott vonalak a normális forgalom alapján automatikusan megállapított riasztási küszöbök értékét mutatják. A küszöbértékek kalibrálására használt forgalom megegyezett, azonban a féreg megjelenése után szemmel láthatóan más történik a két esetben. Az 1. ábrán a szimuláció vége felé is jelentősen meghaladja a normális értéket a forgalom, míg a 2. ábrán nem, mivel kevesebb fertőzés történt. 8

200 Intections IDS counter IDS counter & Infections

160

Threshold

120

80

40

0 0:00

1:00

2:00

3:00

4:00

5:00

6:00

7:00

8:00

7:00

8:00

Simulated time

1. ábra. Autonóm működés 200 Intections

IDS counter

Red alert

Yellow alert

IDS counter & Infections

160

120

80

40

0 0:00

1:00

2:00

3:00

4:00

5:00

6:00

Simulated time

2. ábra. Elosztott működés

A 3. ábráról leolvasható, hány végpont fertőződött meg az egyes alhálózatokban a szimuláció végére. Az elosztott esetben a legalacsonyabb a fertőzések száma. A WANDA nélküli esetben mind a 3598 szimulált végpont megfertőződött7; az autonóm WANDA esetében 370 fertőzés történt; az elosztott esetben pedig 238, vagyis az összes végpont kevesebb, mint 7%-a fertőzödött meg. Téves szűrés (nem fertőzött csomópont kiszűrése) nem volt, mivel a küszöbértékeket úgy állítottam be, hogy a normális forgalom ne érje el a szűréshez szükséges szintet. Ehhez nem kellett sokat állítgatni a paramétereket: az első, a józan észen alapuló becslés is megfelelőnek bizonyult. 300 No IDS Standalone IDS

Worm infections

250

Distibuted IDS

200

150

100

50

0 1

2

3

4

5

6

7

8

9

10 11

12 13

14 15 16

17 18

19 20

Subnet

3. ábra. Az egyes alhálózatokban történt fertőzések száma

9

4.1.4

A portscan-ek észlelése

4.1-es tézis: Megmutattam, hogy a WANDA csekély módosításokkal használható portscan-ek és a hálózat-letapogatás felismerésére is. Kapcsolódó publikáció: [C7]. Az imént ismertetett, a WANDA által felismert forgalmi anomália lényegében megegyezik azzal, amelyet a portscan vált ki. A féreg tevékenysége valójában egy elfajult portscan: ahelyett, hogy ugyanahhoz az IP-hez próbálna kapcsolódni számos különböző porton, számos különböző IP-hez kapcsolódik ugyanazon a porton. A felismerőalgoritmus módosítható úgy, hogy a férgek mellett a portscaneket is felismerje8, azon az áron, hogy a memóriaigénye megnő9. Az Internet felől a belső hálózatba érkező portscanek felismerése érdekében tárolnunk kell minden olyan új bejövő kapcsolat {célIP, célport}10 párosát, amely nem tartozik egy már létező hálózati kapcsolathoz (tehát pl. az FTP adatcsatornák felépülésével nem törődünk). Mérjük, milyen rátával érkeznek új ilyen párosok. Ha a ráta túllép egy küszöbértéket, valószínűleg portscan áldozatai vagyunk. Az {IP, port} párosokat tároló adatszerkezet mérete korlátos, hiszen a gyanúküszöb elérése után felhagyhatunk a további számolással. Az adatszerkezet lehet a már látott fa, azzal a különbséggel, hogy a levelekben elhelyezünk egy-egy bitmezőt, amelyben minden porthoz tartozik egy bit. Azok a forráshálózatok, amelyek kevés porthoz és kevés célcímhez próbálnak kapcsolódni, feltehetően legitimek; azok, amelyek kevés portot, de sok IP-t címeznek meg, a hálózatot tapogatják le; azok, amelyek sok porthoz kapcsolódnak kevés IP-n, klasszikus portscannel próbálkoznak; azok pedig, amelyek sok porthoz kapcsolódnak sok IP-n, vélhetően több célpont egyidejű portscanjét végzik el. Az algoritmus memóriaigényét korlátozhatjuk úgy, hogy először csak a B (vagy akár az A) osztályú hálózatok szintjén különböztetjük meg a távoli forrásokat, és csak akkor foglalkozunk C osztályú alhálózatokkal, ha a szülőjükhöz tartozó ráta túllép egy gyanúküszöböt. Természetesen a bejövő portscanek felismerése a legtöbb esetben sehová sem vezet, hiszen semmilyen hasznos válaszlépést nem tudunk tenni (még a riasztás haszna is kétséges). A saját hálózatunkból kifelé irányuló portscanek felismerése értelmesebbnek tűnik, mivel ilyenkor van reális esélyünk a tettes kézrekerítésére – főként, ha a hálózaton belül megakadályoztuk a forráscímek hamisítását. Az algoritmus ebben az esetben is ugyanaz, mint az imént, azzal a különbséggel, hogy most az új {külső IP, külső port} párosok megjelenésének rátáját kell figyelnünk. 4.1.5

A téves riasztásokról

Téves riasztáshoz (és szűréshez) vezethet, ha egy szolgáltatás felhasználása hirtelen a korábbihoz képest extrém mértékben megváltozik: például, ha egy felhasználónk úgy dönt, hogy világméretű felmérést készít arról, milyen szoftver fut az egyes névszervereken, a WANDA kiszűrheti a felhasználó DNS-forgalmát. Erre a problémára nincs jó megoldás: a felhasználó jobban teszi, ha előre szól a hálózat üzemeltetőinek. Fontos megjegyezni, hogy itt a felhasználó tevékenysége valóban extrém; így téves féregnek nézése nem ugyanakkora hiba, amekkora például egy web-böngésző féregként történő azonosítása lenne. Szintén okozhatnak téves riasztást a peer-to-peer fájlcserélők, ha egy jól ismert porton működnek (például abból a célból, hogy kijátsszanak egy csomagszűrőt).

10

4.1.6

További (gondolat)kísérletek

A szimulációs eredmények és az algoritmus ismeretében megjósolható, mi lenne a hatása a szimulációs paraméterek megváltoztatásának. Például a reakcióidő (és így a karanténfunkció hatékonysága) javulna, ha a gyanúküszöb alacsonyabb lenne. A 80-as TCP port esetében ugyan nem tudjuk csökkenteni a küszöböt, de más protokollok, pl. az SMTP, a POP3, a SOCKS, a „távoli asztal” (RDP) vagy az SSH tipikus felhasználásai esetén a küszöbérték minden bizonnyal sokkal alacsonyabb is lehetne. Ha nem lett volna ennyire irreálisan magas a sikeres fertőzés esélye, a féreg még kevesebb végpontot fertőzhetett volna meg, mielőtt a WANDA kiszűri a forgalmát. Könnyen belátható, hogy a megfigyelt hálózatok mérete elsősorban akkor számít a WANDA hatásossága szempontjából, ha az alhálózat minden végpontja hajlamos különböző távoli kiszolgálókkal kommunikálni. Ha ugyanis ez a helyzet, és az alhálózat sok végpontot tartalmaz, kisszámú lassan pásztázó féregpéldány forgalma könnyebben észrevétlen maradhat az aggregált forgalomban, mint ha kisebb alhálózatokban vizsgálódnánk. Érdemes lenne kifinomultabb szimulációkat végezni, amelyekben a féreg pásztázó-fertőző viselkedése ismert valódi férgekét mintázza; így egyszerűbbé válna a WANDA és más féregdetektorok összevetése. Ebbe az irányba mutató eredményeket publikáltam a [C8]-ban. A paraméterteret be lehetne járni mind kísérleti, mind analitikus úton (a [19]-ben vagy [34]-ben láthatóhoz hasonló módon) – az ezzel kapcsolatos munka 2006-ban elkezdődött, de erőforrások hiányában fel kellett hagynom vele. Végezetül pedig természetesen előnyös lenne a WANDÁ-t valódi hálózatokban is kipróbálni. Érdekes további kutatásra adna lehetőséget annak vizsgálata, lehetséges lenne-e a WANDÁ-t az egész Internetre kiterjeszteni oly módon, hogy az egyes autonóm hálózatok önként vegyenek részt a közös féregfelismerésben; ne legyen központi elem, hanem „friend-to-friend” elven szerveződő overlayhálózatot alkossanak az elosztott üzemmódban működő észlelők. Ezen a hálózaton (amely várhatóan skálafüggetlen lenne) hatékonyan lehetne terjeszteni az állapotváltozásokat és a felismert fertőzési portokra vonatkozó adatokat.

4.2 A RESPIRE (Resource Efficient Synflood Protection for Internet Routers and End-systems) algoritmus A SYN-elárasztás (SYN flood) elnevezésű támadást, amely régi és jól ismert, gyakran alkalmazzák napjainkban is (l. pl. a [38]-as forrást – egy-egy nagyobb szabású ilyen támadás még néhány évvel ezelőtt is újsághír tudott lenni). Olyan szolgáltatás-megtagadásos (DoS, Denial of Service) támadásról van szó, amely az áldozat TCP-implementációja ellen irányul. Mivel a TCP háromutas kézfogást használ, a félig már felépült, ún. félig nyitott kapcsolatokat is nyilván kell tartani. Erre a célra egy külön puffer, az ún. TCP backlog queue szolgál, amelynek mérete természetesen véges. Ha a támadó el tudja érni, hogy megteljen, az áldozat nem képes fogadni a legitim kliensek kapcsolatait. 2. téziscsoport: Javaslatot teszek egy olyan algoritmusra, amelynek segítségével egy kapcsolatkövető tűzfal saját magát vagy egy hálózattopológiai értelemben „mögötte” található szolgáltatást vagy hálózatot tud hatásosan védeni a SYN-elárasztás (SYN flooding) néven ismert támadás ellen olyan módon, hogy automatikusan azonosítja a támadás forrásait és kiszűri a támadó csomagokat. A védett kiszolgáló(k) a többi (nem támadó) hálózatból továbbra is elérhető(k) marad(nak), amennyiben a támadás nem használja el az áldozat teljes sávszélességét. Szimuláció segítségével megmutattam, hogy az általam javasolt RESPIRE algoritmus gyorsan és hatásosan 11

azonosítja a támadás forrásait és anélkül szűri ki a támadáshoz tartozó adatcsomagokat, hogy szignifikáns mértékben akadályozná a legitim forgalmat. Analitikusan meghatároztam a RESPIRE reakcióidejét és memóriaigényét (bizonyos implementációs paraméterek függvényeként). Az általam javasolt RESPIRE algoritmus kiküszöböli a syncookie algoritmus bizonyos hátrányait. Megmértem a RESPIRE és a syncookie algoritmus processzoridőben mért költségét. 2.1-es tézis: Megalkottam a RESPIRE algoritmust, mint a syncookie algoritmust kiegészítő, feljavító védelmet. Kapcsolódó publikációk: [B1][J3][J4][C1][C2][C3][C4][C5]. Egy kiszolgálónak sok olyan adat áll rendelkezésére, amelyeknek a segítségével eldöntheti, éppen SYN-támadás áldozata-e. Ha például az alábbiak bármelyike teljesül, gyanakodhatunk SYNtámadásra: • a SYN csomagok érkezési rátája túllép egy küszöbértéket (ez legitim forgalmi tüskék esetén is bekövetkezhet); • valamely port TCP backlogja megtelik, és a kiszolgáló syncookie-k küldésére kényszerül (ez legitim forgalmi tüskék esetén is bekövetkezhet); • a félig nyitott kapcsolatok száma meghalad egy küszöbértéket (ez legitim forgalmi tüskék esetén is bekövetkezhet); • a félig nyitott kapcsolatok átlagéletkora meghalad egy küszöbértéket (ez csomagvesztés esetén is bekövetkezhet); • eltolódik a kiküldött SYN ACK és a bejövő kapcsolatfelépítést befejező ACK csomagok rátája közötti arány. A RESPIRE ezt az indikátort használja. Az algoritmus pszeudokódja a disszertáció B függelékében található meg; az alábbiakban egy szöveges összefoglalót közlök. Ha úgy döntöttünk, támadás alatt állunk, azonosítanunk kell a támadás forrásait. Míg korábban az Interneten szinte bármilyen forráscím hamisítására lehetőség volt, mára sok hálózat nem enged ki olyan csomagot, amelynek az állítólagos feladója nem belső cím; így a támadó általában csak egy vagy néhány C osztályú hálózat címeit használhatja forráscímként (ha ez a feltételezés nem teljesül, a RESPIRE nem működik helyesen). Napjainkban egy tipikus támadás úgy zajlik, hogy a támadó számos, korábban az ellenőrzése alá vont számítógépet egyszerre utasít arra, hogy árasszák el csomagokkal az áldozatot. A támadás szűrését megnehezítendő ezek a végpontok hamis forráscímeket helyeznek el az általuk küldött csomagokban, azonban a hamis címek ugyanabba az alhálózatba tartoznak, mint az adott végpont valódi címe. Ha ez nem így lenne, fennállna a veszélye annak, hogy a csomagok az előző bekezdésben említett szűrés miatt el sem jutnak az áldozatig. Egy ilyen támadás káros hatásait enyhíthetjük, ha a támadó alhálózatokból érkező SYN csomagokat nem vesszük figyelembe vagy nem továbbítjuk. Egy SYN támadás során a kimenő SYN ACK csomagok rátája sokkal nagyobb lesz, mint a bejövő kapcsolatfelépítést véglegesítő ACK csomagoké. A legtöbb olyan SYN ACK csomagot, amelyre nem érkezik válasz, a támadók felé küldjük; így tehát a támadók azonosításához azokat az alhálózatokat kell megkeresnünk, amelyekkel kapcsolatos forgalmunkban a legtöbb kimenő SYN ACK csomag jut egy bejövő kapcsolat-véglegesítő ACK csomagra. Erre használhatunk olyan dinamikus adatszerkezetet, amely kihasználja az IP-címtér hierarchikus voltát: egy 256-odfokú fát11 [35]. A fa gyökere 256 mutatót és két számlálót tartalmaz. Az ο számláló a kiküldött SYN ACK csomagokat, míg az ι a beérkező kapcsolat-véglegesítő ACK csomagokat számolja12. Ha ο és ι aránya meghaladja a ρ paraméter értékét, feltételezzük, hogy

12

támadás áldozatai vagyunk és elkezdjük bővíteni a fát. ρ-t úgy kell megválasztani, hogy normális esetben erre ne kerüljön sor. Ha az A→B→C levél létezik, a vele kapcsolatos csomagok száma meghalad egy minimumot és számlálóinak aránya meghaladja ρ-t, az A.B.C.0/24-et támadó alhálózatnak tekintjük és δ másodpercen át nem fogadunk el tőle további SYN csomagokat. δ-t úgy érdemes megválasztani, hogy kicsit hosszabb legyen, mint amilyen hosszú támadásokra számítunk. τ másodpercenként ellenőrizzük, hogy a fa tartalmaz-e gyanús csomópontot (olyat, amelyben a számlálók aránya nagyobb, mint ρ). Ha igen, nullázzuk a számlálóikat. Minden más csomópontot törlünk (a gyökér kivételével). A RESPIRE és a syncookie összehasonlítása Daniel J. Bernstein syncookie algoritmusával [39] részben megoldotta a SYN-támadások problémáját. A syncookie lényege az, hogy a kiszolgáló úgy választja meg a saját kezdeti szekvenciaszámát, hogy a visszajövő ACK csomagból (amely ezt a számot is tartalmazza) minden olyan adatot ki tudjon nyerni, amelyet különben félig nyitott kapcsolat formájában a TCP backlogban kellett volna tárolnia. Így a kiszolgáló oldalán semmit sem kell tárolni, amíg az ACK csomag meg nem érkezik. Ennek köszönhetően a kiszolgáló minden bejövő SYN csomagra képes SYN ACK csomaggal válaszolni; ebben csak a processzor teljesítőképessége és a fel-irányú (upstream) sávszélesség korlátozza. A syncookie algoritmusnak vannak hátrányai, amelyeknek mindegyikét csökkenthetjük vagy elkerülhetjük, ha a syncookie-kat a RESPIRE-rel együtt használjuk. 1. Ha syncookie-t használunk, és másodpercenként SYN csomagok ezreit kapjuk, ugyanennyi SYN ACK csomagot küldünk ki – egy esetleg mit sem sejtő harmadik fél részére, akinek a címe (hamisított) forráscímként szerepelt a SYN csomagokban. Ha a SYN-áradat áldozatának sávszélessége aszimmetrikus, és a fel-irányú sávszélesség sokkal kisebb, mint a le-irányú, az áldozat maga fogja elhasználni saját fel-irányú sávszélességét az általa küldött SYN ACK csomagokkal. Az elterjedt forgalomformálók általában csak rontanak a helyzeten, mivel a nyugtacsomagokat (a SYN ACK-okat is beleértve) többnyire nagyobb prioritásúnak tekintik, mint a többi csomagot. A RESPIRE azonosítja a támadó alhálózatokat és kiszűri a tőlük érkező SYN-eket, így az ő részükre a továbbiakban nem küldünk SYN ACK csomagokat. 2. Gondot okozhat a kapcsolat-véglegesítő ACK csomag elvesztése. Normális esetben a kiszolgáló újraküldené a SYN ACK csomagot, amitől a kliens újraküldené az ACK-ot; ha azonban a kiszolgáló syncookie-t használ, nem tartja nyilván a félig nyitott kapcsolatot és így a SYN ACK újraküldésére sincs lehetőség. Ez ahhoz vezethet, hogy a kliens azt hiszi, érvényes TCP-kapcsolat áll fenn közte és a szerver között, míg a szerver erről nem tud semmit. Ha az alkalmazásszintű protokoll szerint először a szervernek kellene valamit küldenie (ilyen például az SMTP), a kliens általában sokáig fog várni a szerver első üzenetére, mielőtt időtúllépés miatt lebontaná a kapcsolatot és újból megpróbálkozna a felépítésével. 3. Syncookie segítségével felépített TCP-kapcsolat nem használhat nagy csúszóablakot és a maximális szegmensméret (MSS) sem tetszőleges. 4. A syncookie-k kiszámítása időigényes feladat: Bernstein a Rijndael titkosítóalgoritmust javasolja, amelynek a másodpercenként sokezerszeri futtatása túl költséges lehet. Ha a támadók hamisított ACK csomagokat is küldenek, az tovább költséget jelent, mert ezek hitelességéről (ill. annak hiányáról) is csak kriptográfiai műveletek segítségével tud meggyőződni az áldozat.

13

Miután a RESPIRE kiszűrte a támadó csomagokat, a syncookie-k küldésével felhagyhatunk, így a 2., 3. és 4. probléma nem lép fel. 4.2.1

RESPIRE: szimulációs eredmények

2.2-es tézis: Szimulációk segítségével megmutattam, hogy a RESPIRE gyorsan és hatásosan azonosítja a SYN-áradatok forrásait és kiszűri a forgalmukat; a téves szűrés lényegében kizárt. Kapcsolódó publikációk: [B1][J4][C1][C5]. A szimuláció paramétereit részletesen a disszertáció ismerteti: itt csak röviden összefoglalom őket. Olyan SMTP-kiszolgálót szimuláltam, amely a világ minden tájáról érkező kliensek kapcsolatait fogadja. Feltételeztem, hogy a kiszolgáló syncookie-k segítségével védekezik a SYN-támadások ellen. A szervernek átlagosan 62,8 aktív kapcsolata volt és másodpercenként átlagosan 12,6 új legitim kliens kezdeményezett vele kapcsolatot. Nyolc támadót szimuláltam, akik elosztott SYN-támadásokat indítottak a kiszolgáló ellen. Mindegyiküknek egy 16 és 24 bit közötti (véletlenszerű) prefixhosszú alhálózat állt rendelkezésére; az általuk küldött SYN-csomagok forráscímei az adott alhálózaton belüli véletlen címek voltak. A támadók 160 és 100.000 db közötti csomagot küldtek másodpercenként; ez véleményem szerint reális13. Az 1. táblázat a támadók tevékenységét foglalja össze. Az első oszlopban a szimuláció kezdetétől a támadás kezdetéig másodpercben mért idő; a másodikban a támadás végének időpontja; a harmadikban támadó által használt forráscímek; a negyedikben pedig a támadás csomagrátája (csomag/s) látható. A 4. ábrán azt ábrázoltam, másodpercenként hány SYN csomag jutott el a kiszolgáló TCP verméig (tehát hány miatt keletkezett félig nyitott kapcsolat vagy syncookie-s SYN ACK csomag); az 5. ábrán pedig azt, másodpercenként hány SYN csomagot szűr ki a tűzfal (figyelem! a két ábra léptéke eltér!). Az ábrákról leolvasható, hogy a támadások csak nagyon rövid ideig sikeresek; a RESPIRE szinte azonnal felismeri és kiszűri őket (vegyük észre, hogy a 4. ábrán nincsenek vízszintes szakaszok). Az 5. ábra azt is bizonyítja, hogy a RESPIRE nagy (140.000 csomag/s-ot meghaladó) csomagrátájú támadások ellen is hatásos. Első csomag Utolsó csomag Alhálózat Csomagráta 80,780 239,046 764,754 890,803 1229,573 2039,08 4060,253 4729,277

357,949 254,177 903,272 2009,153 2498,843 3568,49 4310,985 4975,907

171.85.128.0/17 92.221.110.0/23 96.0.112.0/20 191.81.250.0/23 90.143.64.0/18 210.183.128.0/19 181.255.128.0/17 219.152.14.0/23

1. táblázat. A támadók tevékenysége

14

41274 91938 58563 82013 39586 40932 88895 31267

25,000 SYN Rate - Unfiltered

Rate (SYNs/s)

20,000

15,000

10,000

5,000

0 0

1000

2000

3000

4000

5000

6000

Time (s)

4. ábra. Ki nem szűrt SYN csomagok rátája az idő függvényében

A 4. ábrán csak a SYN csomagok összesített rátája látható; a 2. táblázatban található meg az egyes SYN-támadások által sikeresen kézbesített támadó csomagok száma és a támadás kiszűréséhez szükséges idő. Az idők mindenhol másodpercben vannak megadva. Első csomag Utolsó csomag Átjutott csomagok Reakcióidő 80,780 81,409 22191 0,629 239,046 239,057 505 0,011 764,754 764,799 1920 0,045 890,803 890,814 505 0,011 1229,573 1229,817 6766 0,244 1790,814 1790,82 505 0,06 2039,08 2039.189 3535 0,101 2129,699 2129,864 6767 0,165 2939,157 2939,270 3535 0,113 4060,253 4060,446 13231 0,193 4729,277 4729,298 505 0,021 2. táblázat. A RESPIRE reakcióideje 150,000 SYN Rate - Blocked

Rate (SYNs/s)

125,000 100,000 75,000 50,000 25,000 0 0

1000

2000

3000

4000

5000

6000

Time (s)

5. ábra. Kiszűrt SYN-csomagok rátája az idő függvényében

Ezek az adatok igazolják, hogy az általam javasolt védelmi mechanizmusnak még igen elosztott, 17 bites prefixhosszú hálózatból érkező támadások esetén is jó a reakcióideje (1. és 10. sor). A szimuláció során a RESPIRE erőforrásigényét is vizsgáltam. A 6. ábrán látható a RESPIRE által használt adatszerkezet csomópontjainak száma az idő függvényében. 11 tüskét figyelhetünk meg, amelyek a támadások kezdőidőpontjaira esnek. Ekkor allokálta a RESPIRE azokat a csomópontokat, amelyeknek a segítségével a támadókat azonosította. A támadások kiszűrése után ezek felszabadultak és csak a fa gyökere maradt meg. Még a /17-es hálózatból érkező támadások esetén sem volt szükség 166-nál több csomópontra; ez nem jelentős mennyiség.

15

200 Tree nodes 160

120

80

40

0 0

1000

2000

3000

4000

5000

6000

Time (s)

6. ábra. A RESPIRE fájának mérete (a csomópontok száma) az idő függvényében

Azt is megvizsgáltam, hány tűzfalszabály szükséges a támadások kiszűréséhez; az eredmény a 7. ábrán látható. 160 Blocking rules 120

80

40

0 0

1000

2000

3000

4000

5000

6000

Time (s)

7. ábra. A tűzfalszabályok számának alakulása

Természetesen a szükséges tűzfalszabályok száma csak a támadó által használt alhálózatok számától és méretétől függ; attól nem, hogy milyen módszerrel találjuk meg a kiszűrendő alhálózatokat, feltéve, hogy valamennyit megtaláljuk. Azonban mivel itt tudjuk, hány alhálózatból érkeztek a támadó csomagok valójában, az ábráról leolvashatjuk, hogy az algoritmus nem szűrt ki ennél több alhálózatot. 4.2.2

A RESPIRE erőforrásigénye

2.3-as tézis: Matematikai módszerrel meghatároztam a RESPIRE erőforrásigényét és becslést adtam reakcióidejére (választható ill. a támadásra jellemző paraméterek függvényében). Kapcsolódó publikációk: [B1][J3][C2][C3][C4]. Annak érdekében, hogy a RESPIRE ellen a memória elfogyasztására irányuló eredményes támadást ne lehessen indítani, a fa-csomópontok számát korlátozni kell. Egy csomópont kb. 2kB memóriát igényel 64 bites és kb. 1kB-ot 32 bites architektúra esetén. A csomópontok számára felső becslést a ad az IPv4-es címtér mérete; ha az egészet le akarnánk fedni csomópontokkal, 256 + 65536 + 16777216 darab csomópontra lenne szükség. Ennyi adat tárolásához kb. 32,5 GB memóriára lenne szükség; egy tűzfalon nem áll rendelkezésre ekkora tár. A ténylegesen létrejövő csomópontok száma attól függ, hány alhálózat viselkedik gyanúsan, vagyis hogy hányban található támadó által ellenőrzött végpont. A valóságban a 200 különböző C osztályú hálózatot használó támadások rendkívül ritkák; az, hogy ezek mindegyike különböző A osztályú hálózatban legyen, már csak a különleges célokra fenntartott A osztályú hálózatok miatt is szinte kizárt. Ebben a valószínűtlen esetben 600 csomópontra lenne szükségünk, ami alig több, mint 1

16

MB memória lefoglalását jelenti. Ezzel együtt érdemes mesterségesen is korlátozni a fa méretét; egy lehetséges megoldást bemutatok a disszertációban. Könnyen belátható, hogy ha a támadás intenzitása nő, az algoritmus reakcióideje csökken. Legyen Δt az az idő, amennyivel egy számláló-inicializálás után a támadás megkezdődik. Ha a bejövő SYN-áradatot ψ paraméterű Poisson-folyamattal modellezzük14, a legitim forgalmat pedig λ paraméterűvel, akkor a támadás felismeréséhez a következő két feltételnek kell teljesülnie: ∆t (λ + ψ ) ≥ ρ és ∆t (λ + ψ ) ≥ µ . ∆tλ Az első egyenlőtlenség független Δt-től15, így a támadást felismerjük, ha már legalább μ SYN ACK csomagot kiküldtünk, ahol μ a RESPIRE-nak az a paramétere, amely megadja, legalább hány SYN ACK csomagot kell küldeni egy alhálózat felé azelőtt, hogy kiszűrhetnénk az adott hálózat forgalmát. Így a támadó alhálózat megtalálásához a fa valamely szintjén szükséges idő a következőképpen írható fel: µ ∆t szint = λszint + ψ Ahol λszint a legitim forgalomnak a fa adott szintjén megjelenő intenzitása (tehát az a legitim forgalom, amely a támadó alhálózatból érkezik). Látható, hogy a reakicóidő annál kisebb, minél nagyobb a támadás intenzitása. 4.2.3

RESPIRE: mérési eredmények

2.4-es tézis: Mérések segítségével összehasonlítottam a RESPIRE és a synookie algoritmus erőforrásigényét. Kapcsolódó publikáció: [B1]. A RESPIRE linuxos implementációját felhasználva összehasonlítottam a RESPIRE ill. a syncookie algoritmus használata által okozott processzor-terhelést úgy, hogy megmértem, mennyi időt tölt a CPU az ún. „softIRQ” állapotban SYN-támadás alatt, ha a) semmilyen védelem nem aktív; b) csak a RESPIRE aktív; c) csak a syncookie aktív; és d) ha mindkettő aktív. A „softIRQ”-ban töltött időbe beleszámít a beérkező csomagok feldolgozásának ideje, és a Linux kernel eleve exportálja ezt a statisztikát, így kézenfekvő volt a mérésnek ez a módja. A 3. táblázat röviden összegzi a mérési eredményeket; ebben a kísérletben a támadás intenzitása kb. 16 Mbps volt (ami kb. 32 kpps-nek – 32.000 csomag/s-nak – felel meg). A támadó C osztályú alhálózatok száma 500 volt. Amíg nincs jelentős forgalom, a kernel másodpercenként alig 10ms-ot tölt csomagok feldolgozásával. A támadás alatt, védelem nélkül, kb. 45-75ms telt el másodpercenként a backlog karbantartásával. A RESPIRE bekapcsolása után egy rövid kb. 50ms/s-os softIRQ-tüskét mértem (ez a fa felépítésével kapcsolatos teendők időigénye). Rövid idővel ezután az első támadókat kiszűri az algoritmus, de nem az összeset, mivel syncookie-k híján nem tudtunk mindegyiknek elegendő SYN ACK csomagot küldeni. Ezt követően a softIRQ állapotban eltöltött idő kb. 20-25ms/s körül stabilizálódik a támadás hátralevő része alatt; a megtakarítást az magyarázza, hogy a bejövő SYN csomagokra nem kell válaszolni. Ha csak syncookie-kkal védekezünk, kb. 10ms-ot takarítunk meg másodpercenként a védelem nélküli esethez viszonyítva; ez az eredmény némileg meglepő, mert arra enged következtetni, hogy a cookie-k előállítása kevesebb CPU-időbe kerül, mint a backlog karbantartása (amire most nem kerül sor).

17

Mindkét védelmi mechanizmus aktiválása esetén a softIRQ-ban töltött idő 20ms/s köré csökken, ami közelebb van a támadás nélkül mért 8 ms/s-os alapértékhez, mint ahhoz a 45ms/s-hoz, amibe a támadás védelem nélküli átvészelése kerül. védelem nélkül, támadás alatt 45-75 ms syncookie-val, támadás alatt

35-75 ms

RESPIRE-rel, támadás alatt

25-50 ms

syncookie-val és RESPIRE-rel, támadás alatt

20 ms

védelem és támadás nélkül

8 ms

3. táblázat. “Soft IRQ” állapotban töltött idő másodpercenként

Az érdeklődő Olvasó a disszertációban további részleteket és grafikonokat talál. Megvizsgáltam azt is, hogyan változnak ezek a számok a támadás intenzitásának függvényében. Ebben a kísérletben az áldozat TCP-vel kapcsolatos beállításai a Linux alapbeállításai voltak (az első kísérletben az áldozat beállításait úgy módosítottam, hogy jobban megbirkózzon a támadással: pl. kevesebbszer ismételje meg a SYN ACK csomagot). A kísérlet eredményeit a 8-11-es ábrákon ábrázoltam. A támadás sávszélességét 8Mbps-ról 16, majd 32Mbps-ra emeltem (ez rendre kb. 16, 32 ill. 64 kpps-nek felel meg). A grafikonokon a softIRQ-ban töltött időn kívül a CPU tétlenül töltött idejét is ábrázoltam (százalékban). A 4. táblázatból a softIRQ-ban töltött idők numerikusan is kiolvashatók (ms/s-ban). 16kpps 32kpps 64kpps RESPIRE+syncookie

14

29

100

RESPIRE

18

34

119

syncookie

38

44

190

nincs védelem

36

60

200

4. táblázat. SoftIRQ-ban töltött idő (ms/s) különböző intenzitású támadások alatt

8. ábra. CPU-terhelés támadás esetén, védelem nélkül. Átlagos terhelés: 36ms, 60ms ill. 200ms.

18

9. ábra. Aktív syncookies, inaktív RESPIRE. Átlagos terhelés: 38ms, 44ms ill. 190ms.

10. ábra. Aktív RESPIRE, inaktív syncookie. Átlagos terhelés: 18ms, 34ms ill. 119ms.

11. ábra. Aktív RESPIRE és syncookie. Átlagos terhelés: 14ms, 29ms ill. 100ms.

•

•

•

A mérések eredményeiből a következő következtetések adódnak: Talán némileg váratlan, de akkor használjuk a legtöbb CPU-időt, ha sehogyan nem védekezünk a SYN-támadás ellen. Ilyenkor természetesen a megtámadott TCP szolgáltatás is elérhetetlenné válik. A RESPIRE jól skálázódott. Bekapcsolása után a stacionárius állapotban (amikor a támadást már kiszűrte) jelentősen csökkent a CPU terhelése. A szolgáltatás 10-20 másodperc után ismét elérhető volt. A syncookie algoritmus szavatolja a szolgáltatás elérhetőségét akkor is, ha SYN-támadás van folyamatban, ám ez a kriptográfiai műveletek miatt viszonylag sok processzoridőbe kerül. A 19

•

kísérletben felhasznált áldozat syncookie használata esetén legfeljebb kb. 33Mbps-os támadást volt képes átvészelni; ez az érték RESPIRE használata esetén 38Mbps volt. A processzor terhelése akkor volt a legalacsonyabb, ha mind a syncookie, mind a RESPIRE egyidejűleg volt aktív. Ilyenkor a szolgáltatás is elérhető maradt, ráadásul megszűnt a SYN ACK csomagokból álló kifelé irányuló áradat is.

4.2.4

Újabb eredmények

2004. óta, amikor először publikáltam a RESPIRE algoritmust, többen javasoltak más módszereket a SYN áradatok kezelésére. Ezeket részletesebben a disszertációban mutatom be; itt csak néhány szót ejtek róluk. Kompella et al. [56] (alig néhány hónappal a RESPIRE [C1] megjelenése után) javít az [52]-es forrásban leírt, a SYN és FIN csomagok arányát figyelő ötleten. Cikkükben egy „partial completion filter” elnevezésű algoritmust javasolnak, amely a RESPIRE-hez hasonlóan lehetővé teszi több forráscím SYN/FIN arányának aggregált nyilvántartását, de kapcsolatkövetés nélkül (így skálázhatóbban). Emiatt azonban a téves pozitív azonosítás esélye megnő. Al-Duwairi és Manimaran azt javasolja, alkalmazzuk az SMTP-ben a spam elleni harcban használt „szürkelistázást” (greylisting) a TCP-re [55]. Ötletük azon a tényen alapul, hogy a legitim kliensek, ha az első kapcsolódási kísérletük sikertelen, egy idő után újrapróbálkoznak; így elvileg elegendő támadás észlelése esetén minden kapcsolat első SYN-csomagját eldobni és megnézni, mennyi idő múlva érkezik a következő. Nandivada és Palsberg [57] cikkében olyan időzített automatán alapuló absztrakciót mutat be, amelynek a segítségével a SYN ellen védő mechanizmusok félformálisan validálhatók; a segítségével megállapítható, hogy a SYN-áradat (amelyet szintén időzített automatával modelleznek) képes lehet-e arra, hogy a TCP-implementációt reprezentáló automatát „rossz” állapotba vigye (olyanba, amelyben legitim kapcsolatokat veszít el).

4.3

A lobbi-index – egy új centralitásmérce gráfok számára

Az összetett gráfok (hálózatok) topológiájának jobb megértése elengedhetetlen, ha hatékonyan akarunk velük kapcsolatos feladatokat megoldani. Számos alkalmazásnál merülnek fel a topológiával kapcsolatos kérdések: például hálózati csomópontok fertőzéssel szembeni immunizálása [20] esetén az a sorrend, amelyben az immunizálásra sor kerül, döntően befolyásolhatja egy járvány lefolyását [21]. A véletlen gráfoknak különösen érdekes részhalmaza a skálafüggetlen gráfoké, mivel számos, a valóságban létrejövő gráf skálafüggetlen (ilyenek pl. az emberek közötti ismeretségi hálózatok; az Internet AS-szintű gráfja; a weboldalak egymásra mutató hivatkozásai által kifeszített gráf; az egymással e-mailt váltó emberek által kifeszített gráf; vagy a kutatói közösségek társszerzői gráfja). A skálafüggetlen gráfok immunizálásával kapcsolatos korábbi irodalom főként a fizikai immunizálásra összpontosított (l. pl. [20] ill. [21]): arra az esetre, amikor pl. orvosok adnak be vakcinát embereknek egy járvány megfékezése érdekében. Mivel a fertőzéseket gyakran szociális érintkezés közben ragasztjuk egymásra, az immunizálás során érdemes a sok más emberrel érintkező személyeket hamar beoltani. A probléma némileg megváltozik, ha informatikai vonatkozású skálafüggetlen hálózatokat vizsgálunk (például F2F – friend-to-friend – fájlcserélőt16). Az immunizáló ágens ilyenkor nem egy orvos, hanem egy tetszőlegesen sok példányban lemásolható szoftver, amely végigterjedhet az egész

20

hálózaton. Mely csomópontok minél hamarabbi immunizálására törekedjünk? Ezeknek mely szomszédait immunizáljuk elsőként? Ha feltesszük, hogy a kezdeti immunizációnak van egy csomópontonként jelentkező fix költsége, ígéretesnek tűnik elsőként a „nagy befolyással” bíró csomópontokat immunizálni: azokat, amelyeknek sok nagy fokszámú szomszédja van. Hány ilyen csomópont van egy hálózatban, és hogyan ragadhatnánk meg a „nagy befolyás” fogalmát? Olyan centralitásmércét szerettem volna találni, amelynek a kiszámításához nem szükséges az egész gráfot ismerni, mégis alkalmas arra, hogy kvantitatívan megítéljük egy-egy csomópont „befolyásosságát”. Reményeim szerint egy ilyen mérce segíteni fog a skálafüggetlen hálózatok önreplikáló ágens általi immunizációjának hatékonyabbá tételében. A lobbi-index megalkotását részben Borgatti [36] cikke motiválta, aki megjegyzi, hogy „nem ismert olyan centralitásmérce, amely releváns lenne a fertőzés- és pletykaterjedés szempontjából, amit azonban rendkívül fontosnak tartanék”. 3. téziscsoport. Definiáltam egy új, gráfokban használható centralitásmércét, a lobbi-indexet: egy csomópont lobb-indexe a legnagyobb olyan l, amelyre igaz, hogy a csomópontnak legalább l darab legalább l-edfokú szomszédja van. Meghatároztam a lobbi-index eloszlását generált skálafüggetlen gráfokban, valamint egy valós skálafüggetlen gráfon, az Internet AS-szintű gráfján. Meghatároztam a Spearman-féle rangkorrelációs együtthatót a lobbi-index és három széles körben használt centralitásmérce között. Megmutattam, hogy ha egy gráf csomópontjainak fokszámai függetlenek és P(deg( x ) ≥ k ) ≈ k −α minden x csomópontra (ez a Barabási-Albert típusú gráfokban teljesül), akkor 2

P( l( x ) ≥ k ) ≈ k −α .

3.1-es tézis: Definiáltam a lobbi-indexet és meghatároztam, milyen eloszlást követ BarabásiAlbert típusú skálafüggetlen gráfokban. Kapcsolódó publikációk: [J1][J2]. Definíció. Az x csomópont lobbi-indexe az a legnagyobb l egész, amelyre igaz, hogy a csomópontnak legalább l darab legalább l-edfokú szomszédja van. Tétel. Ha a csomópontok fokszámai függetlenek és P(deg( x ) ≥ k ) ≈ k −α minden x csomópontra 2

(mint például a Barabási-Albert típusú gráfokban), akkor P( l( x ) ≥ k ) ≈ k −α . Bizonyítás. Használjuk az l-index eloszlására a következő jelölést: lk=P(l(x)=k). Legyen továbbá Gk=P(deg(x)≥k)=1-Fk, c pedig egy tetszőleges pozitív konstans. lk =

∞

∑ P (l( x ) ≥ k ,

l =0

deg( x ) = k + l ) =

∞

∑ P (l( x ) = k deg( x ) = k + l )P (deg( x ) = k + l ) l =0

(Egységfelbontás; feltételes valószínűség.) Most azt kell megvizsgálnunk, mekkora a valószínűsége annak, hogy egy csomópontnak k szomszédja van úgy, hogy ezen szomszédok fokszáma ≥ k és l további olyan szomszédja, amelyek fokszáma
(

Becsüljük lk-t 1 − c1k −α ≈ e −c 1k

−α

)

k + l  l k  ≥ és  felhasználásával:  k  k!

21

lk ≥ c =

c1k k −αk k!

∞

∑ l k − (α +1)e

−

c1l

≥c

kα

l =0

2 Γ (k −α ) ck −α k!

≥ ck

c1k k −αk k!

(k − α )k −α −

−α 2

1 2

e

∞

k −( α + 1) e ∫x

−

c1l

kα

dx ≥ cc1k k −αk

0

Θ( k −α + 12 k −α )

( )

Γ (k − (α +1)+ 1) k α k − (α + 1)+ 1 k! c1

=

≥ ck −α (α + 1)−1

Θ k + 12 k + 12 k

k e Γ(k − α ) -t ill. k!-t a Stirling-formula segítségével becsültük; 0 < Θ < 1.

Felső becslés: ∞ k + l  c k k −αk (Fk + 1 )l ≤ c 1 lk = (Gk )k ∑ (k + l )− (α +1)  k!  l  l =0

≤c =c

c1k k −αk k! c1k k −αk k!

c k k −αk ≤c 1 k!

∞

∑ (k + l )k −(α +1)e

−

( )

c1l k α kα k + 1

=c

l =0 ∞

∑ l k −(α +1)e

−

l =k

∞

∫x 0

k − (α +1)

e

( )

c1l k α kα k + 1

−

(k k+ 1 )α c1x kα

≤c

c1k k −αk k!

c1k k −αk k!

∞

∑ (k + l )k −(α +1)e

−

c1l

(k + 1 )α

≤

l =0

∞

∑ l k −(α +1)e

−

( )

c1 (l − k ) k α k +1 kα

=

l =k

∞

∑ l k −(α +1)e

−

( )

c1l k α kα k + 1

≤

l =0

dx .

Új változót bevezetve: α c k k −αk  (k k+ 1 ) c1    lk ≤ c 1 k!  k α    2 ck −α Γ (kk−! α )

(1 + )

−k +α

∞

∫y 0

k − (α + 1)

e

−y

(k − α )k −α −

dy = cc1k k −αk Γ (k − (αk !+ 1)+ 1) 1 2

e

Θ (k −α ) k −α + 12

( ) [( ) ] kα c1

k −α

k −α k +1 α k

≤

≤ ck −α (α + 1)− 1 k+1 k+ Θk k 2 e 12 szintén a Stirling-formulát alkalmazva. 3.2-es tézis: Meghatároztam a lobbi-index eloszlását különböző algoritmusokkal generált skálafüggetlen gráfokban, valamint az Internet AS-szintű gráfjában. Meghatároztam a Spearman-féle rangkorrelációs együtthatót a lobbi-index által előállított csomópontsorrend és az elterjedt centralitásmércék által definiált sorrendek között. Kapcsolódó publikációk: [J2]. A lobbi-index viselkedése generált skála-független hálózatokban. Ötven, egyenként 20.000 csomópontot tartalmazó Barabási-Albert (BA) típusú gráfot [22] generáltam, minden iterációban 1010 új csomópontot hozzáadva, 10 csúcsú teljes gráfból indulva. A fokszámeloszlás megfelelt a modellnek; α, a farokexponens értéke 1,96 volt. A 12. ábrán látható a lobbi-index tapasztalati eloszlása; ηˆ = 5,14 , míg az elméleti érték η = 5,76. ≤

1 k k

≤ ck

−α 2

22

12. ábra. A lobbi-index eloszlása BA típusú gráfban (log-log)

Az általánosított BA modell (GBA; l. [23]) segítségével tetszőleges α > 1 beállítható. Ötven, egyenként 10.000 csomópontból álló GBA-gráfot generáltam; ezekben α átlagosan 1,9186 volt, amelyből 5,60-as η következett volna; a tapasztalati érték 5,28. 0

-1 -2 -3

2.5

3.5

3

y = -5.2813x + 11.451 2 R = 0.9975

-4 -5 -6 -7 -8 -9 -10

13. ábra. A lobbi-index eloszlása általánosított BA (GBA) gráfban (log-log)

23

-2.8 -3.8

1.5

2

2.5

3

3.5

4

-4.8 -5.8 -6.8

y = -2.497x + 0.9611 2 R = 0.9243

-7.8 -8.8 -9.8

14. ábra. A lobbi-index eloszlása az Internet AS-gráfjában (log-log)

A lobbi-index viselkedése az Internet AS-szintű gráfjában. Az Internetet alkotó összekapcsolt autonóm rendszerek (Autonomous System, AS) által kifeszített gráfot sokan igen alaposan megvizsgálták (l. pl. a [24]-es cikket és hivatkozásait). Nemcsak skálafüggetlen, de az ún. „gazdagok klubja” is megtalálható benne: a nagy fokszámú csomópontok egymás közötti kapcsolatai sűrűbbek, mint azt egy BA-gráfban várnánk. Az AS-gráfra vonatkozó adatokat letöltöttem a CAIDA projekt honlapjáról [25], majd megállapítottam, hogy a fokszámeloszlás farokexponense 1,61. ηˆ = 4,14 , míg az elméleti értékre η = α (α + 1) alapján 4,20 adódik. -3

2.5

3

3.5

4

-4 -5 -6 -7

y = -2.6427x + 3.8965 2

R = 0.8485

-8 -9 15. ábra. A lobbi-index eloszlása IG típusú gráfokban (log-log)

A lobbi-index viselkedése IG típusú gráfokban. A Mondragón et al. által javasolt Interactive Growth (IG) algoritmus [24] segítségével olyan skálafüggetlen gráfok konstruálhatók, amelykben van gazdagok klubja. Minden iterációban egy újonnan felvett csomópontot egy vagy két létező csomóponttal kötünk össze. Az első esetben a kiválasztott meglevő csomópontot két további meglevő

24

csomóponttal is összekötjük; a második esetben a két régi csomópont közül csak az egyik (véletlenszerűen kiválasztott) kap új kapcsolatot. Megvalósítottam ezt az algoritmust és ismét meghatároztam az exponenseket a generált gráfokban. A gráfok ezúttal 3.000 csomópontot tartalmaztak; 0,4 eséllyel egy, 0,6 eséllyel két meglevő csomóponttal kötöttem össze az új csomópontokat. A tapasztalati fokszámeloszlás farokexponensére 1,23 adódott; így a lobbi-index eloszlásának elméleti farokexponense 2,74 lett volna. A tapasztalati eloszlásban ηˆ = 2,45 -öt mértem. A lobbi-index helye a többi centralitásmérce között. A lobbi-index valahol a closeness, a betweenness és az eigenvector centrality „között” helyezkedik el. A szomszédok számával való erős korreláció Glänzel megfigyelése17 [26] alapján kizárt: l (x ) ≈ c deg (x )α +1 . 1

l

closeness

betweenness

eigenvector

l

1

0.652

0.768

0.604

closeness

0.652

1

0.500

0.972

betweenness

0.768

0.500

1

0.479

eigenvector

0.604

0.972

0.479

1

5. táblázat. Spearman-féle rangkorrelációs együtthatók a centralitásmércék között

Hogy jobban megértsük a lobbi-index viselkedését, meghatároztam a lobbi-index és a három említett centralitásmérce között a Spearman-féle rangkorrelációs együtthatót az AS gráf adatai alapján. Az 5. táblázatban szereplő korrelációs adatok alapján mondható, hogy a lobbi-index egyfajta kiegyensúlyozott „keveréke” a három másik centralitásmércének: kicsit közelebb van mindhárom „klasszikus” mércéhez, mint amilyen közel azok egymáshoz vannak (a félkövéren szedett együtthatók négyzetes közepe 0,638, míg a dőlten szedetteké 0,678). Biológiai hálózatokban nagy Spearman-korrelációt várunk a closeness és az eigenvector centralitás között [27]; más hálózatokban is nagy Pearson-korrelációt figyeltek meg közöttük [28]. Ilyen módon bizonyos esetekben az egyik centralitásmérce segítségével közelíthető lehet egy másik. Ez az AS-gráf és a lobbi-index esetében ugyan nem igaz, de más hálózatokban igen (l. később). Így potenciálisan rengeteg számítási művelet takarítható meg, mivel a lobbi-index kiszámítása sokkal egyszerűbb, mint a másik háromé.

5 Az eredmények alkalmazhatósága Disszertációmban két új hálózatbiztonsági algoritmusra és egy új centralitásmércére (a lobbi-indexre vagy l-indexre) tettem javaslatot. Az első algoritmus, a WANDA, hatásos védelmet nyújt a pásztázó férgek ellen. Ezek jellegükből adódóan sok különböző távoli számítógéphez próbálnak kapcsolódni, hogy megpróbálják megfertőzni őket; ez az a viselkedés, amelyet a WANDA felismer. Az algoritmus közvetlenül megvalósítható és akár azonnaltól használható a férgek elleni küzdelemben. Egyszerűsége miatt különösen vonzó lehet beágyazott rendszerek, pl. hardveres tűzfalak számára; a disszertációban részletesebben bemutatott lehetséges bonyolultabb változatok is alkalmasak arra, hogy egy átlagos, tűzfalként működő PC futtassa őket. A WANDA vonzó tulajdonsága továbbá, hogy képes a szinte minden közepes vagy nagyobb hálózatban rendelkezésre

25

álló NetFlow (vagy egyéb hasonló) adatok alapján dolgozni; így a WANDA bevezetéséhez nem szükséges újabb eszközt helyezni a forgalom útjába. A létező útválasztók és kapcsolók elláthatnak egy vagy több WANDA-példányt NetFlow-adatokkal, amelyeket a WANDA feldolgoz, majd szükség esetén megfelelő forgalomszűrési szabályokat állít be valamilyen tetszőleges távoli adminisztrációt lehetővé tevő protokoll segítségével, amelyet az adott hálózat eszközei támogatnak. A WANDA elosztott változata elsősorban az olyan campus-méretű hálózatok igényeit elégíti ki, amelyekben a forgalmi adatok központi feldolgozása nehézkes vagy drága lenne; azon túlmenően, hogy ilyen környezetben is lehetővé teszi a WANDA bevetését, az elosztott változat segítségével az is megakadályozható, hogy a különböző alhálózatokban található végpontok egymást fertőzzék meg. A féregjárványok megállításán kívül a WANDA a portscanek felismerésére is alkalmassá tehető. Visszatekintve meg kell állapítanom, hogy sajnos rosszul választottam meg azt a fórumot, ahol a WANDÁt publikáltam. Nagy reményeket fűztem az akkor induló EC2ND konferenciasorozathoz, ám sajnálatos módon nem tudott kitörni az ismeretlenség homályából; ez magyarázhatja, miért születtek a WANDÁhoz hasonló független eredmények anélkül, hogy a WANDÁra hivatkoznának. Például a Cisco olyan anomáliadetektort [60] valósított meg, amelyről ugyan nem lehet eldönteni, hogy a WANDA adatszerkezeteit használja-e, de amely ugyanazt a hálózati anomáliát keresi, mint a WANDA. Hasonlóan, Kamaguchi disszertációjában [61] szintén olyan féregfelismerő algoritmust javasol, amely a kapcsolatok célcímeinek számolásán és faszerkezeteken alapul. A RESPIRE algoritmus úgy segít a kiszolgálóknak és tűzfalaknak a SYN-áradatok elleni védekezésben, hogy azonosítja és kiszűri az áradathoz tartozó csomagokat (a SYN-áradat szolgáltatásmegtagadásos támadás; a segítségével ideiglenesen megbénítható egy TCP-alapú szolgáltatás). A RESPIRE létező linuxos implementációja 2005. és 2007. júniusa között működött sikerrel a hub.irc.hu szerveren, amely akkor Magyarország egyik legforgalmasabb IRC (Internet Relay Chat) szervere volt. Ebből kifolyólag gyakran volt kitéve SYN-támadásoknak; a RESPIRE ezeket felismerte és kiszűrte. A legtöbb különböző forráscímet használó támadást 2007. februárjában naplózta a szerver: ez 70 C osztályú hálózat címtartományát használta forráscímként és másodpercenként kb. 52.000 SYN-csomagból állt. Normális esetben a szerver csak mintegy 150 legitim kapcsolatkérést kapott másodpercenként. A jelzett időszakban egyetlen SYN-támadás sem tette az IRC szolgáltatást elérhetetlenné. 2007-ben kénytelen voltam a RESPIRE-t eltávolítani a szerverről, mivel a létező implementáció nem működik helyesen többprocesszoros rendszeren, és a szerver új CPU-t kapott. Egy jobb implementáció elkészülése egyelőre várat magára. A WANDÁhoz hasonlóan az algoritmus egyszerűsége miatt szinte a legegyszerűbb SOHO útválasztón is futtatható lenne (feltéve, hogy az eszköz képes a TCP-kapcsolatok követésére; ez mára általánosnak mondható). A syncookie algoritmussal kombinálva a RESPIRE a TCP-s kiszolgálókat rendkívül ellenállóvá teszi a SYN-támadásokkal szemben úgy, hogy közben a syncookie-k hátrányai (pl. „lepattintott” áradat; kriptográfia miatti processzor-terhelés) nem jelentkeznek. A független idézetek tekintetében a RESPIRE majdnem ugyanúgy járt, mint a WANDA (legalább részben szintén a rosszul megválasztott publikációs fórumoknak köszönhetően); mindössze két független hivatkozásról tudok. A [C1]-es cikket idézi [58] (bár csak a támadás leírása miatt), valamint [59]. A lobbi-index egy érdekes új módja annak, hogy „különleges” csomópontokat azonosítsunk különösen skálafüggetlen gráfokban. Mérhetővé teszi az egyes csomópontok abban az értelemben vett

26

„fontosságát”, hogy sok más csomópontot képesek könnyen elérni, megszólítani. Legelőnyösebb tulajdonsága az, hogy kizárólag lokális információ szükséges a kiszámításához, míg az elterjedt centralitásmércék meghatározása az egész gráf (vagy legalábbis nagy része) ismeretét és feldolgozását igényli. [J2] publikálása óta más kutatók a lobbi-indexnek már több olyan alkalmazását is felfedezték, amelyre én nem számítottam; a [29] szerzői például arra a megállapításra jutottak, hogy VANETekben (járművekből álló ad-hoc hálózatokban) mind a lobbi-index, mind a betweenness centralitás használható a „minőségi csomópontok” azonosítására (ezeknek a csomópontoknak szánnak speciális szerepeket). A szerzők kiemelik, hogy a lobbi-indexnek nagy előnye kiszámításának egyszerűsége. Loulloudes et al. szerint „geocasting alkalmazások tekintetében a nagy lobbi-indexű csomópontok ideálisak az üzenetek továbbszórásának feladatára, mivel a segítségükkel a lehető legkevesebb újbóli üzenetszórással érhető el a lehető legtöbb címzett” [30]. Az is kiderült, hogy a lobbi-index hasznos lehet a keresési találatok rangsorolásában (úgy a weboldalak, mint – és ez talán meglepő – az élesztőfehérjék esetében) [31]. Fontos eredmény, hogy a lobbi-index bizonyos keresések esetében ugyanolyan jó vagy jobb találat-sorrendet adott, mint az az eigenvector centralitás, amelyen a Google PageRank algoritmusa is alapul és amelynek meghatározása globális információt igényel. A szcientometria területén is találtak alkalmazást (l. pl. [32] és [33]).

6 Köszönetnyilvánítás Köszönetet szeretnék mondani Telcs Andrásnak (a lobbi-index kidolgozásában nyújtott rendkívül értékes segítségéért); Bicskei Alennek (a RESPIRE linuxos implementációjának elkészítéséért, valamint a RESPIRE-t a syncookie-kkal összehasonlító méréssorozat elvégzésében nyújtott segítségéért); Gyimesi Juditnak (a RESPIRE formális analízisében nyújtott segítségéért csakúgy, mint a WANDA elődjének kidolgozásáért); Jukka Koskinennek, a Tamperei Műszaki Egyetem oktatójának (hasznos ötletekért és beszélgetésekért); munkaadómnak, a CAE Engineering Kft-nek (amiért lehetővé tette, hogy munkám mellett továbbra is részt vegyek a kutatásban); az Ericssonnak és az Európai Uniónak (kutatásaim jelentős részének finanszírozásáért); végezetül pedig a BME TMIT kollektívája számos tagjának (segítségükért és bátorításukért; kösz, srácok).

7 Tézisekhez kapcsolódó publikációim Könyvfejezetek [B1] András Korn: Software Mechanisms to Combat SYN Floods, In: Thomas S Clary (ed.), Horizons in Computer Science Research. Volume 1, New York: Nova Science Publishers Inc., 2010. pp. 171-192., ISBN: 978-1-60876-972-8 Folyóiratcikkek [J1] András Schubert, András Korn, András Telcs: Hirsch-type indices for characterizing networks, Scientometrics 78:(2) pp. 375-382. (2009), DOI: 10.1007/s11192-008-2218-1 [J2] A Korn, A Schubert, A Telcs: Lobby index in networks, Physica A - Statistical Mechanics and its Applications 388:(11) pp. 2221-2226. (2009), DOI: 10.1016/j.physa.2009.02.013

27

[J3] András Korn, Judit Gyimesi, Dr. Gábor Fehér: Analysis of RESPIRE, a novel approach to automatically blocking SYN flooding attacks, Híradástechnika Selected Papers 2005/6, pp. 44-50 [J4] Gyimesi Judit, Korn András, Fehér Gábor: SYN-áradatok automatikus szűrése a RESPIRE algoritmussal, Híradástechnika 2004/9, pp.40-47 Konferenciacikkek, poszterek [C1] András Korn, Gábor Fehér: RESPIRE – A Novel Approach to Automatically Blocking SYN Flooding Attacks, Proceedings of Eunice 2004 (Advances in Fixed and Mobile Networks) 10th Open European Summer School and IFIP WG6.3 Workshop, June 14-16, 2004, Tampere, Finland, pp. 181-187 [C2] Gyimesi Judit, Korn András: A SYN-áradat-szűrő RESPIRE algoritmus analízise, HTEBME diákkonferencia, 2004. május 18., Budapest [C3] Gábor Fehér, Judit Gyímesi, András Korn: Analyzing RESPIRE, a Novel Defense against SYN Floods, Ericsson International High Speed Networking Workshop, Budapest, May 1718, 2004, pp. 110-114 [C4] Judit Gyimesi, András Korn: The analysis of RESPIRE, a novel algorithm for Defense against SYN Floods, Polish-Czech-Hungarian Workshop on Circuit Theory, Signal Processing, and Telecommunication Networks, September 20-21, 2004, Budapest, Hungary [C5] Korn András, Dr. Fehér Gábor, Gyimesi Judit, SYN-elárasztás elleni védekezés a RESPIRE algoritmus segítségével, NetWorkShop 2005, Szeged, 2005. március 30 – április 1. [C6] Judit Gyimesi, Gábor Fehér, András Korn: Distributed Intrusion Detection Systems against Worms, Ericsson International High Speed Networking Workshop, Mátraháza, May 23-24, 2005, pp. 59-61 [C7] András Korn, Gábor Fehér: Zero Hour Outbreak Prevention Using Traffic Anomaly Detection, Proceedings of the First European Conference on Computer Network Defence, pp. 219-228, 2005, Springer, ISBN 1-84628-311-6 [C8] Fehér Gábor, Korn András: New Simulation Results for WANDA, the Worm ANomaly Detector Algorithm, poster 91., Ericsson High Speed Networking Workshop, Balatonkenese, May 23-24, 2006. Előadások [L1] András Korn: Statistics based anti-DDoS strategies (meghívott előadás, Tampere Univ. of Tech., csak szóban hangzott el), 2005.

8 Egyéb publikációim [1] Dr. Fehér Gábor, Korn András, Szentgyörgyi Attila, Szűts Péter Lóránt et al.: Biztonságos vezetéknélküli szuperhálózat, Kommunikáció 2005. [2] András Korn, Gábor Fehér, et al.: Implementing a Secure Campus-wide Infrastructure for WiFi Access, Ericsson International High Speed Networking Workshop, Mátraháza, May 2324, 2005, pp. 68-70 [3] A. Korn, Benchmarking Terminology and Methodology for Resource Reservation Capable Routers, Transcom 2001, Žilina, Slovakia, 25-27 June 2001, pp 169-172 28

[4] G. Fehér, A. Korn: Performance Profiling of Resource Reservation Protocols, IFIP 9th Conference on Performance Modelling and Evaluation of ATM & IP Networks 2001, Budapest, Hungary, June 27-29, 2001, pp. 205-217 [5] Fehér G., Korn A., Garantált minőségű hálózati szolgáltatások jelzésrendszereinek analízise, Magyar Távközlés, 2001/2. [6] Attila Szentgyörgyi, András Korn: Outsourcing Security Services for Low Performance Portable Devices, Proceedings of the Second European Conference on Computer Network Defence, December 14-15, 2006, University of Glamorgan, UK, pp. 23-32, Springer, ISBN 184628-749-9 [7] Korn András: Extrém rendszeradminisztráció: djbware és társai, VIII. GNU/Linux szakmai konferencia, 2006. november 24., Budapest, pp. 73-96 (meghívott tutoriál) [8] G. Fehér, I. Cselényi, K. Németh, A. Korn, RFC4483: Benchmarking Terminology for Resource Reservation Capable Routers, July 2007, IETF RFC, http://tools.ietf.org/html/rfc4883 [9] G. Fehér, I. Cselényi, A. Korn, Benchmarking Methodology for Routers Supporting Resource Reservation, Expired January 2002, Internet Draft, http://www.ietf.org/proceedings/02mar/I-D/draft-ietf-bmwg-benchres-method-00.txt [10] Korn András: Unix/Linux kiszolgálók üzemeltetése, az azonos című választható tárgy elektronikus jegyzete; http://unixlinux.tmit.bme.hu/ [11] Korn A., djbdns – DNS, BIND nélkül, Networkshop 2002, Eger (meghívott tutoriál) [12] A. Korn, P. Váry, I. Cselényi, G. Fehér, Benchmarking Methodology for Reservation Capable Routers, Poster, HSN Workshop Spring 2000 [13] G. Fehér, A. Korn, G. Kovács, K. Németh, B. Szabó, I. Cselényi, A Performance Comparison of Boomerang and RSVP on QoS IP Routers, Poster, HSN Workshop Fall 1999 [14] Korn András: Javaslatok az Elender Informatikai Rt. dial-up Internethozzáférés-szolgáltatása biztonságának javítására, az Elender RT által megrendelt tanulmány, 2000., 28 oldal [15] Korn András, Bicskei Alen, Szentgyörgyi Attila, Szüts Péter Lóránt: Kurrens hálózatbiztonsági technológiák, a T-Com PKI által megrendelt tanulmány, 2005. [16] Korn András: Ismerkedés a Snort hálózati behatolásjelző rendszerrel (mérési utasítás, BME TMIT), 2004.

9 Felhasznált irodalom [17] Judit Gyimesi: Opportunities of Distributed Intrusion Detection Systems and Applying Them Against Worms, in: Proc. of Transcom 2005, Žilina, Slovakia. [18] Cliff C. Zou, Weibo Gong, Don Towsley, Lixin Gao: The monitoring and early detection of internet worms, IEEE/ACM Transactions on Networking (TON), v.13 n.5, p.961-974, October 2005; doi:10.1109/TNET.2005.857113 [19] Jiang Wu, Sarma Vangala, Lixin Gao, Kevin Kwiat: An Effective Architecture and Algorithm for Detecting Worms with Various Scan Techniques, In: Proceedings of the Network and Distributed System Security Symposium 2004 (NDSS 2004) (Feb. 2004). [20] Hu, Ke; Tang, Yi: Immunization for scale-free networks by random walker, Chinese Physics, Volume 15, Issue 12, pp. 2782-2787 (2006). 29

[21] Weidong Pei, Zengqiang Chen and Zhuzhi Yuan: Random walk immunization strategy on scale-free networks, Journal of Control Theory and Applications Volume 7, Number 2, 151156, DOI: 10.1007/s11768-009-6187-6 [22] Albert-László Barabási, Réka Albert, Hawoong Jeong: Mean-field theory for scale-free random networks, Physica A 272 (1999) pp. 173-187. [23] P.L. Krapivsky, S. Redner, F. Leyvraz, Physical Review Letters 85 (2000) pp. 4629-4632. [24] Shi Zhou, Raúl J. Mondragón: Accurately modeling the internet topology, Physical Review E 70 (2004) pp. 066108; DOI: 10.1103/PhysRevE.70.066108, arXiv:cs/0402011v4 [25] Skitter AS Links Dataset, http://www.caida.org/data/active/skitter_aslinks_dataset.xml, letöltve: 2008. január [26] Wolfgang Glänzel: On the h-index – A mathematical approach to a new measure of publication activity and citation impact, Scientometrics 67 (2006) pp. 315-321. [27] Dirk Koschützki, Falk Schreiber: Comparison of Centralities for Biological Networks, in: German Conference on Bioinformatics, 2004, pp. 199-206. [28] Chang-Yong Lee: Correlations among centrality measures in complex networks, arXiv:physics/0605220v1 [29] George Pallis, Dimitrios Katsaros, Marios D Dikaiakos, Nicholas Loulloudes, Leandros Tassiulas: On the Structure and Evolution of Vehicular Networks, In: MASCOTS 2009 (17th Annual Meeting of the IEEE International Symposium on Modelling, Analysis and Simulation of Computer and Telecommunication Systems). London, UK, 2009, pp. 1-10. [30] Nicholas Loulloudes, George Pallis, Marios D. Dikaiakos: The Dynamics of Vehicular Networks in Urban Environments, technical report (134p), 2010, arXiv:1007.4106v1 [31] Monica G. Campiteli, Adriano J. Holanda, Paulo R. C. Soles, Leonardo H. D. Soares, Osame Kinouchi: Hirsch index as a network centrality measure, 2010, arXiv:1005.4803v2 [32] Sebastian K. Boell and Concepción S. Wilson: Journal Impact Factors for evaluating scientific performance: use of h-like indicators, Scientometrics 82: (3) 613-626. (2010), DOI: 10.1007/s11192-010-0175-y [33] Lutz Bornmann, Rüdiger Mutz, Sven E. Hug, Hans-Dieter Daniel: A multilevel metaanalysis of studies reporting correlations between the h index and 37 different h index variants, Journal of Informetrics 5 (2011) 346–359, doi: 10.1016/j.joi.2011.01.006 [34] Stuart Staniford: Containment of scanning worms in enterprise networks. Journal of Computer Security, 2003, vol. 85, pp. 99. URL: http://www.its.bth.se/staff/apo/courses/telesystem/literature/paper_f9_1.pdf (letöltve: 2011. augusztus 15.) [35] Thomer M. Gil, Massimiliano Poletto: MULTOPS: a data-structure for bandwidth attack detection, in: Proceedings of the 10th Usenix Security Symposium, August 2001. [36] S. P. Borgatti: Centrality and network flow, Social Networks 27 (2005) pp. 55–71. DOI: 10.1016/j.socnet.2004.11.008 [37] Check Point Software Technologies Ltd: The Impact of Worms and Viruses, URL: http://www.checkpoint.com/securitycafe/readingroom/internal_security/impact_of_worms _viruses.html (letöltve: 2011. augusztus 15.) [38] SPAMFigher News: Attack on Baidu.Com Using Syn Flooding, URL: http://www.spamfighter.com/News-6425-Attack-On-BaiduCom-Using-Syn-Flooding.htm, 29 September 2006 (letöltve: 2011. augusztus 15.)

30

[39] Daniel J. Bernstein, “SYN cookies”, 1996, http://cr.yp.to/syncookies.html (letöltve: 2009. április 6.) [40] Cliff Changchun Zou, Weibo Gong, Don Towsley, Lixin Gao: The monitoring and early detection of internet worms, IEEE/ACM Transactions on Networking (TON), v.13 n.5, p.961-974, October 2005; doi:10.1109/TNET.2005.857113 [41] Michael Vrable, Justin Ma, Jay Chen, David Moore, Erik Vandekieft, Alex C. Snoeren, Geoffrey M. Voelker, Stefan Savage: Scalability, Fidelity, and Containment in the Potemkin Virtual Honeyfarm, In: Proceedings of the 2005 Symposium on Operating Systems Principles, October 2005. [42] Niels Provos: A virtual honeypot framework, in: Proceedings of 13th USENIX Security Symposium, August 2004. [43] Matthew M. Williamson: Throttling Viruses: Restricting Propagation to Defeat Mobile Malicious Code, in: Annual Computer Security Applications Conference, 2002. [44] David Whyte, Evangelos Kranakis, P.C. van Oorschot: DNS-based Detection of Scanning Worms in an Enterprise Network, in: Proc. of 12th Annual Network and Distributed System Security Symposium (NDSS 2005); URL: http://www.isoc.org/isoc/conferences/ndss/05/proceedings/papers/whytednswormv2.pdf (letöltve: 2011. augusztus 15.); DOI: 10.1.1.73.7306 [45] Vincent H. Berk, Robert S. Gray, George Bakos: Using Sensor Networks and Data Fusion for Early Detection of Active Worms, in: Edward M. Carapezza (ed.): Sensors, and Command, Control, Communications, and Intelligence (C31) Technologies for Homeland Defense and Law Enforcement, pp. 92-104, ISBN 0-8194-4930-X, SPIE, 2003 [46] Mariusz Burdach: Hardening the TCP/IP stack to SYN attacks. URL: September http://www.symantec.com/connect/articles/hardening-tcpip-stack-syn-attacks, 10, 2003; updated 2 November 2010 (letöltve: 2011. augusztus 15.) [47] CERT Coordination Center, Denial of Service Attacks, URL: http://www.cert.org/tech_tips/denial_of_service.html, last changed June 4, 2001 (letöltve: 2009. április 6.) [48] Livio Ricciulli, Patrick Lincoln, and Pankaj Kakkar: TCP SYN Flooding Defense, in: Proc. Comm. Net. and Dist. Systems Modeling and Simulation Conf. (CNDS' 99), 1999. [49] T. Darmohray and R. Oliver: Hot spares for DoS attacks, The Magazine of USENIX and SAGE, vol.25, no.4, p.3, July 2000. [50] Christoph L. Schuba, Ivan V. Krsul, Markus G. Kuhn, Eugene H. Spafford, Aurobindo Sundaram, Diego Zamboni: Analysis of a Denial of Service Attack on TCP, in: Proceedings of IEEE Symposium on Security and Privacy, May 1997. [51] Steve Gibson: G.E.N.E.S.I.S., Gibson's ENcryption-Enhanced Spoofing Immunity System, http://www.grc.com/r&d/nomoredos.htm, last updated January 7, 2008 (letöltve: 2009. április 21.) [52] Haining Wang, Danlu Zhang, Kang G. Shin: Detecting SYN Flooding Attacks, in: Proceedings of IEEE InfoCom, 2002, pp. 1530-1539, ISSN: 0743-166X; DOI: 10.1109/INFCOM.2002.1019404 [53] Jelena Mirković: D-WARD: DDoS network attack recognition and defence, Ph.D. thesis, Computer Science Department, University of California, Los Angeles, June 2003.

31

[54] Yuichi Ohsita, Shingo Ata, Masayuki Murata: Detecting Distributed Denial-of-Service Attacks by analyzing TCP SYN packets statistically, in: Proceedings of GlobeCom 2004, Vol. 4, pp. 2043-2049, ISBN: 0-7803-8794-5, DOI: 10.1109/GLOCOM.2004.1378371 [55] Basheer Al-Duwairi, G. Manimaran: Intentional Dropping: A Novel Scheme for SYN Flooding Mitigation, in: Proc. of Infocom 2005, vol. 4, pp. 2820-2824, ISSN: 0743-166X, DOI: 10.1109/INFCOM.2005.1498569 [56] Ramana Rao Kompella, Sumeet Singh, George Varghese: On Scalable Attack Detection in the Network, in: Proc. of IMC’04, October 25–27, 2004, Taormina, Sicily, Italy. [57] V. Krishna Nandivada, Jens Palsberg: Timing Analysis of TCP Servers for Surviving Denialof-Service Attacks, in: Proc. of 11th IEEE Real Time and Embedded Technology and Applications Symposium, 2005 (RTAS 2005), pp. 541 – 549; DOI: 10.1109/RTAS.2005.54 [58] Usman Tariq, ManPyo Hong, Kyung-suk Lhee: A Comprehensive Categorization of DDoS Attack and DDoS Defense Techniques, in: Advanced Data Mining and Applications, Springer, 2006. pp. 1025-1036. (Lecture Notes in Computer Science); ISBN: 978-3-540-370253 [59] Jukka Koskinen (ed.): Palvelunestohyökkäyksen havaitseminen ja torjuminen, university course material of the Technical University of Tampere, Finland, 2006. URL: http://www.cs.tut.fi/kurssit/TLT-3700/dos-seminaari.pdf (letöltve: 2011. augusztus 15.) [60] Cisco Systems, Inc.: Implementing Cisco Intrusion Prevention Systems, Volume 2, Version 6.0, 2007; URL: http://www.scribd.com/doc/55431632/28/Anomaly-Detection-Overview (letöltve: 2011. szeptember 1.) [61] Nobutaka Kawaguchi: Detection of Hit-List Worms based on Propagation Behavior, PhD dissertation, February 2008; URL: http://iroha.scitech.lib.keio.ac.jp:8080/sigma/bitstream/handle/10721/2455/document.pdf (letöltve: 2011. szeptember 1.) [62] David Moore, Colleen Shannon, Jeffrey Brown: Code-Red: a case study on the spread and victims of an internet worm, Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurement, November 06-08, 2002, Marseille, France; DOI: 10.1145/637201.637244 [63] David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford, Nicholas Weaver: Inside the Slammer Worm, IEEE Security and Privacy, v.1 n.4, pp. 33-39, July 2003; DOI: 10.1109/MSECP.2003.1219056 [64] Cliff C. Zou, Don Towsley, Weibo Gong: On the performance of Internet worm scanning strategies. Technical Report TR-03-CSE-07, University of Massachusetts ECE Dept., November 2003. 1

Kivéve, ha például csak egy kriptográfiai módszerrel hitelesített kivétellistán szereplő programokat engedünk futni egyáltalán – ez azonban aligha reális lehetőség. 2 A WANDA a 2. téziscsoportban bemutatott RESPIRE algoritmus ötletén alapul. Elsőként Gyimesi Judit fejlesztett – az én témavezetésem alatt – a RESPIRE-n alapuló féregdetektort [17]; a [C6]-os cikk, amelynek megírásában viszonylag kis részem volt, szintén a [17]-ben szereplő algoritmust mutatja be, és csak az alapötlet közös volta miatt hivatkozom rá itt. A WANDA nem alapul közvetlenül a [17]-ben ill. [C6]-ban bemutatott algoritmuson, noha a közös alapötlet miatt szükségképpen hasonlítanak. A WANDA jelen disszertációban leírt változata először a [C7] cikkben került publikálásra, és saját munkám eredménye.

32

3

Szintén lehetséges – és manapság egyre gyakoribb – a félpasszív terjedés. Ekkor a féreg a sebezhető böngészőn keresztül fertőz, amikor a felhasználó egy fertőzött honlapra látogat vele. Egy ilyen féregnek két „fokozata” van: az egyik honlapokat fertőz meg, a másik kliensgépeket. Ilyen férgekkel nem foglalkoztam, mivel a WANDA publikálása idején ismert különösen kártékony férgek mindegyike (MyDoom, Sasser, Code Red[62], Sl@mmer[63] stb.) pásztázó féreg volt, tehát olyan módon terjedt, hogy automatikusan aknázta ki a megfertőzendő számítógépek szoftvereinek sebezhetőségeit [64]. 4 Ha a megfigyelt hálózatot szigorúan ellenőrizzük, eleve tudjuk, mely portokon létezik egyáltalán elérhető belső szolgáltatás, így a bejövő kapcsolat-felépítési kísérletek közül csak azokat kell figyelembe vennünk, amelyeknek van egyáltalán esélye felépülni; elvégre nem kell különösebben aggódnunk az olyan férgek miatt, amelyek nálunk nem létező szoftverek hibáit kihasználva fertőznek. 5 Érdemes a riasztási állapot megváltozásait üzenetszórással közvetíteni a többi észlelő felé, és helyben tárolni a többi észlelő utolsó ismert állapotát; így a „szavazást” minden észlelő autonóm módon le tudja bonyolítani anélkül, hogy körülfordulási időket kellene megvárni a döntéssel. Ugyanakkor elképzelhető, hogy ez a módszer nem skálázódik jól, ha nagyon sok észlelőnk van és az állapotváltozások gyakoriak. 6 Eleve mindig forrásra lebontva vizsgálni a kapcsolódási rátákat feleslegesen költséges lenne. 7 Azért nem csak a 20%-uk, mert minden egyes fertőzési kísérletnél újabb 20% esélyt kapott a féreg. 8 Jogosan tehető fel az a kérdés, hogy a portscanek felismerésére tett erőfeszítések értelmesek-e. Ideális esetben egy támadó semmivel sem szabad, hogy közelebb legyen a sikeres behatoláshoz egy sikeres portscan után, mint előtte. A portscanek felismerése (főként téves riasztások nélkül) általánosságban elvileg sem lehetséges, mivel a portscan lehet tetszőlegesen elosztott és tetszőlegesen lassú. 9 Az implementációban használt megoldásoktól függően több száz vagy akár több ezer kilobájttal egy C osztályú hálózat megfigyelése esetén. 10 Feltételezzük, hogy a port mező a protokoll azonosítóját is tartalmazza, hogy a TCP- és UDP-portok megkülönböztethetők legyenek. 11 Szóba jönnek más adatszerkezetek is, amelyek a tárhely- és órajelciklus-hatékonyság egy részéért cserébe jobb reakcióidővel vagy nagyobb pontossággal kecsegtetnek; ezek közül egyet röviden ismertetek a disszertációban. A konkrét adatszerkezet megválasztása nem kutatói, hanem mérnöki feladat. 12 Az algoritmust a tézisfüzetben terjedelmi okokból egyszerűsített formában közlöm; a teljes működés a disszertációból ismerhető meg. 13 A RESPIRE-t „éles” környezetben is használtam; az általam megfigyelt legerősebb támadás kb. 70 C osztályú hálózatot használt forrásként és másodpercenként kb. 52.000 csomagból állt. 14 Ezt azért tehetjük meg, mert sok támadó forráscím mindegyike minden pillanatban véletlenszerűen vagy küld csomagot, vagy nem; és ezeket a csomagokat a hálózat egyetlen pontfolyamattá aggregálja. Szélsőséges esetben a SYN-csomagok közvetlenül egymás után is érkezhetnek, vagyis a csomagközi idő eloszlása lehet egyenletes; itt azonban csak azt használjuk fel, hogy a beérkező támadó csomagok száma egyenesen arányos az idővel, úgyhogy ez nem okoz gondot. 15 Ha a legitim forgalom nagysága annyira meghaladja a támadásét, hogy a vizsgált arány nem tudja meghaladni ρ-t, akkor a támadás észrevétlen marad – de ennyire kis intenzitású támadás miatt aggódni sincs okunk. 16 A jelenleg elterjedtebb peer-to-peer hálózatok topológiája is lehet skálafüggetlen. 17 Ennek a képletnek a segítségével becsülhető egy csomópont lobbi-indexe a fokszám ismeretében; segít annak a megítélésében is, hogy egy konkrét lobbi-index nagynak, közepesnek vagy kicsinek számít.

33