Informatika | Hálózatok » Horák György - WLAN hálózatok biztonsági analízise

http://www.doksihu Budapesti Műszaki és Gazdaságtudományi Egyetem WLAN hálózatok biztonsági analízise Diplomaterv Horák György M szaki informatika szak V.évfolyam dyuri@sch.bmehu Konzulens: Schulcz Róbert schulcz@hit.bmehu Budapest, 2004. március 30 http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Tartalomjegyzék TARTALOMJEGYZÉK.2 BEVEZETŐ .3 1. A 80211 SZABVÁNY ÁTTEKINTÉSE5 1.1 VEZETÉK NÉLKÜLI HÁLÓZATOK TÖRTÉNETE5 1.2 A WLAN HÁLÓZATOK FIZIKAI RÉTEGE7 1.3 VEZETÉK NÉLKÜLI HÁLÓZATOK KÖZEGHOZZÁFÉRÉSI MÓDSZEREI11 1.4 WLAN TOPOLÓGIÁK14 1.41 Infrastruktúra hálózat14 1.42 Cellaváltás infrastruktúra hálózatban15 1.43 Ad Hoc üzemmód17 1.44 Vezeték nélküli hidak18 1.5 BIZTONSÁGI KÉRDÉSEK19 1.51 A WEP20 1.52 Az EAP26 1.53 A WPA28 1.54 IEEE 80211i – a jöv 30 1.55 Alternatív biztonsági megoldások30 1.56 IPSec32 2. TANSZÉKI WLAN HÁLÓZAT KIÉPÍTÉSE36 2.1 FIZIKAI KIÉPÍTÉS36 2.2 BIZTONSÁGI

KÉRDÉSEK39 2.21 Gateway funkciók39 2.22 Hálózati címfordítás40 2.23 T zfal beállítása42 2.24 Engedélyezés weben keresztül44 2.25 A WEP beállítása45 2.26 IPSec alkalmazása46
3. EGY SEGÉDPROGRAM ELKÉSZÍTÉSE53 3.1 FAMILIAR L INUX53 3.2 PROGRAM FORDÍTÁSA PDA-RA54 3.3 A PROGRAM ELKÉSZÍTÉSE55 3.31 A pcap használata55 3.32 A GTK+56 3.33 A program m ködése57 3.34 A program használata59
4. A TANSZÉKI WLAN HÁLÓZAT VIZSGÁLATA61 4.1 A MÉRÉS MEGTERVEZÉSE61 4.2 ELS HELYSZÍN: MCL LABOR EL TTI TERÜLET62 4.3 MÁSODIK HELYSZÍN: A TANSZÉK ÉSZAKI FOLYOSÓJA64 4.4 MÉRÉS A TÁVKÖZLÉSI ÉS MÉDIAINFORMATIKAI TANSZÉK HÁLÓZATÁN65   ÖSSZEGZÉS.66 FELHASZNÁLT IRODALOM.67 RÖVIDÍTÉSJEGYZÉK.69 –2– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Bevezető Napjainkban egyre nagyobb igény van számítástechnikai eszközeink hálózatba kapcsolására. Gépeink összekapcsolására alapvet és széles körben

elterjedt módszer az, hogy valamilyen vezetékkel (koaxiális, sodrott érpár stb.) kötjük össze ket Ennek a módszernek a növekv számú Internethez vagy helyi hálózatokhoz csatlakozni kívánó felhasználók miatt sajnos a korlátait elértük, nagyobb irodákban, kollégiumokban végeláthatatlan kábelrendszerekkel, kezelhetetlen patch szekrényekkel találkozunk, melyet egy id után már nagyon nehezen tudunk kordában tartani. Nem is szólva arról, hogy a sok kábel, és a csatlakozók igen nagy hibaforrást jelentenek a hálózat üzemeltetése szempontjából. El fordul, hogy valamilyen okból kábelhálózat kialakítása egyáltalán nem, vagy csak részben lehetséges, esetleg nem praktikus. Ilyenek lehetnek például: m emlék épületek, múzeumok,
tantermek, el adó termek, ideiglenes hálózatok, mozgó terminál. A fenti okok miatt egyre szélesebb körben használnak vezeték nélküli LAN technológiát a globális informatikai és távközl rendszerek

elérésére. A vezeték nélküli megoldások el nye a "hagyományos" vezetékes hálózattokkal szemben, hogy csak részben, illetve egyes esetekben egyáltalán nem igénylik a kábelezés kiépítését. További el ny, hogy az egyes felhasználóknak igen nagymértékben növekedett mobilitása. A Híradástechnikai Tanszék Mobil Távközlési és Informatikai Laboratóriumában (MC2L) folytatott önálló labor gyakorlataim során, sikerült megismerkedtem néhány 802.11 szabvány által definiált vezeték nélküli hálózati eszközzel. A rendelkezésünkre bocsátott, különböz gyártóktól származó eszközök lehet vé tették nekem és társaimnak, hogy összehasonlíthassuk az egyes eszközöket konfigurálhatóság, hatótávolság, kompatibilitás alapján. A Híradástechnikai Tanszék területén mintahálózatot építettünk ki. A részletes és körültekint tervezés, és a szükséges eszközök megvásárlása után végrehajtottuk a rendszer

kivitelezését. A 802.11b eszközök dinamikus terjedése világszerte rámutatott egy nagyon súlyos problémára is. Sajnos a közvélemény a vezeték nélküli LAN-okat biztonsági szempontból sebezhet nek tartja, sajnos nem alaptalanul. A munkám során ezen biztonsági problémák megismerésére, és lehet ség szerint orvosolására helyeztem a hangsúlyt. Üzembe helyeztünk –3– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv egy szervert, ami a WLAN hálózat lelke lett és ehhez kapcsolódóan egy olyan szoftverrendszert és használati szabályozást dolgoztam ki, amely a f ként rosszindulatú betörések, jogosulatlan hálózat használók elleni védekezést segíti el . Dolgozatomban a hálózat kiépítése és a szabvány nyújtotta lehet ségek tanulmányozása során szerzett tapasztalataimat és az általam készített biztonsági megoldást mutatom be. Az els fejezetben 802.11 szabvánnyal kapcsolatos fontosabb tudnivalókat

foglalom össze Írok a vezeték nélküli hálózatok kialakulásának történetér l, ismertetem a ma használatos átviteli módszereket, a szabványosítás lépcs fokait egészen napjainkig, a legfrissebb törekvésekig, majd a rendszer fizikai rétegével kapcsolatos tudnivalókat mutatom be röviden, áttekintem a közeghozzáférés módszereit, a mobilitást biztosító cellaváltási folyamatokat. Bemutatom a kialakítható vezeték nélküli topológiákat, és részletesebben kitérek a biztonsági kérdésekre. Megvizsgálom a 80211-es szabványban el írt biztonsági protokollt és hiányosságait, melyeket alternatív módszerekkel próbálok meg pótolni. A második fejezetben röviden bemutatom a tanszéki mintahálózatot, és vázolom az általunk használt biztonsági megoldásokat. A harmadik fejezetben röviden bemutatom, hogyan készítettem egy segédprogramot, mellyel a hálózaton utazó csomagok bizonyos fokig megfigyelhet ek, illetve a használt WLAN

hálózatról tudhatunk meg hasznos információkat, így fényt deríthetünk akár bizonyos biztonsági hiányosságokra is. Végül a negyedik fejezetben az elkészített program segítségével megvizsgálom a tanszéki

WLAN hálózatunkat. Bemutatom, hogyan lehet egyszer en információkat gy jteni a
hálózatról, illetve hogyan lehet a begy jtött információkból következtetéseket levonni a hálózat biztonságosságáról. –4– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 1. A 80211 szabvány áttekintése 1.1 Vezeték nélküli hálózatok története A vezeték nélküli hálózatok gyökere a II. Világháborúban az Egyesült Államok hadserege által használt rádióadatátviteli eljárásokra vezethet vissza. k fejlesztették ki és használták el ször a rádión keresztüli adatátvitelt. A háború alatt az USA és szövetségei sokat és eredményesen használták ezt a technológiát pont-pont

összeköttetésekben. Ezek az eredmények a Hawaii Egyetemen néhány kutatót arra inspiráltak, hogy kidolgozzák az els nyílt, csomag (packet) alapú rádiós adatátviteli technológiát. 1971-ben elkészítették az els vezeték nélküli hálózatot (WLAN – Wireless Local Area Network). A kés bbi rendszerek mind-mind egyedileg fejlesztett, nem szabványos rendszerek voltak, ezért nem tudtak egymással kommunikálni. Az 1980-as években az Amerikai Szabványügyi Testület (FCC - Federal Communications Commission) a 802.11-es IEEE (Institute of Electrical and Electronics Engineers) szabvány kidolgozását javasolta a helyzet megoldására. A szabvány els dleges célja a fejlesztés összehangolása, az eszközök együttm ködésének
biztosítása volt. A többi 802-es IEEE szabványhoz hasonlóan a 80211 is csak a fizikai réteget és az adatkapcsolati szint közeghozzáférés rétegét definiálja. Három átviteli technológia (két rádiófrekvenciás és egy

infravörös) számára egyetlen közeghozzáférés-vezérlést (Medium Access Control – MAC) határoz meg. A szabványosítás lehet vé teszi az olcsó tömeggyártást, növeli a keresletet és végeredményben elterjeszti a rendszert világszerte. A mai vezeték nélküli hálózatok infravörös, lézeres, mikrohullámú és rádiófrekvenciás technológia segítségével valósíthatják meg az eszközök közötti kapcsolat létrehozását. Az infravörös átvitel gyors, de a kapcsolat bizonytalan lehet, hiszen a nyaláb útjába kerül akadályok az átvitelt meggátolhatják. Ezt a technológiát inkább csak kéziszámítógépek, mobiltelefonok és hordozható eszközök esetében használják, kis (max.5-10m) távolságra Számos ipari környezetben a zavarforrások miatt a rádiós átvitel nem lehetséges, ekkor általában infravörös összeköttetést alkalmaznak. –5– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Lézeres

átvitel alkalmazásakor, minden esetben szükség van a közvetlen rálátásra. Ebben az esetben az akadályok meghiúsítják az átvitelt, ráadásul zavarérzékenysége miatt kültéri felhasználása problémás lehet. A keskeny nyalábú (irányított) mikrohullámú átvitel nem kívánja meg a közvetlen rálátást, bár a nagyobb fémfelületek, teherhordó falak és bizonyos esetben az id járási körülmények átvitelt rontó hatásúak az alkalmazott magas frekvencia miatt (3-20 Ghz). A WLAN rádiófrekvenciás eszközök az úgynevezett ISM (Industrial, Scientific, and
Medicine) sávban m ködnek. Ezek a frekvenciasávok a világ legtöbb országában szabadon használhatók, meghatározott adóteljesítmény-korlátok betartása mellett. Az ISM sávok a rádiófrekvenciás spektrum leggyakrabban használtak a (83,5 MHz sávszélesség) UHF illetve SHF tartományában helyezkednek el. A 902-928 MHz (26 MHz-es sávszélesség), 2,4-2,4835 GHz és

5,725-5,850 GHz (125 MHz sávszélesség) közötti frekvenciasávok, bár megjegyzend , hogy más tartományokban is üzemeltetnek ISM sávokat. A nagyobb frekvenciákra belátható módon a megkívánt nagyobb átviteli sebesség okozta sávszélesség-növekedés miatt van szükség. El nye még a nagyobb frekvenciáknak, hogy kisebb antennákkal és jelfeldolgozó eszközökkel lehet megvalósítani a berendezést és a frekvencia újrafelhasználása is többször lehetséges ugyanakkora területen belül. Az eredeti IEEE 802.11-es szabványt 1997-ben jelentették meg, majd ezt követ en számos alváltozat követte. 1999 szén jelent meg az IEEE 802.11a és a IEEE 80211b Végül megjelent 2001-ben a 802.11g szabvány Az eredeti IEEE 80211 a 2,4 GHz-es sávot határozza meg üzemi frekvenciatartománynak és 1, illetve 2 Mbps-os átviteli sebességet biztosít QAM (Quadrate Amplitude Modulation) és BPSK(Binary Phase Shift Keying) moduláció használatával. Az IEEE 802.11b

ugyancsak a 2,4GHz-es sávban üzemel, de CCK(Complementary Code Keying) moduláció használatával, a maximális fizikai átviteli sebesség 11Mbps lehet. A 802.11a, csak úgy mint a 80211g OFDM (Ortogonal Frequency Division Multiplex) modulációt használ, mindkét hálózat maximális átviteli sebessége 54 Mbps, de az el bbi az
5 GHz-es, az utóbbi a 2,4 GHz-es sávban m ködik. Látható, hogy a sebességet els sorban a modulációs módok megválasztása befolyásolja jelent sen. A nagyobb átviteli sebesség komplexebb modulációs módot jelent, amellyel együtt jár a nagyobb zavarérzékenység és –6– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv kisebb hatótávolság ugyanakkora lesugárzott teljesítmény mellett.
Az újabban használatos 22 Mbps sebesség hálózatok nincsenek külön szabványosítva, az átviteli sebességet az IEEE 802.11b 11 Mbps megduplázásával érik el, megnevezésük IEEE
802.11b+ Ehhez

hasonlóan találkozhatunk 108 Mbps sebesség hálózatokkal, amelyeken az IEEE 802.11g módosított változatát használják Az eddig említett sebességértékeken mindig a fizikai réteg (azaz az eszközök közötti közegbeni – rádióhullám) átviteli sebességét értjük. A hasznos – ennél jóval, 40-45%-kal alacsonyabb – a járulékos fejlécek, az egyes rétegek hozzáadott adatai és a rosszabb átviteli hibaarány miatt. Emiatt egy 11Mbps–os rendszerben az elérhet alkalmazás réteg beli – a futó alkalmazás számára hasznos – maximális adatátviteli sebesség csak 6-8Mbps lehet. A standardizálás után létrejött Wireless Ethernet Compatibility Alliance (WECA) egy non
profit szervezet, mely azt t zte ki célul, hogy hálózati teszteket végez a WLAN termékeken. Mivel nincs el zetes regisztráció vagy vizsgálat a 802.11-es szabványhoz, ezért a szabványnak megfelel és a kompatibilitás elvét betartó termékeket Wi-Fi (Wireless Fidelity)


címkével min síti, ezáltal igazolja az eszközök együttm ködési képességét. Jelenleg kb 90 gyártó több mint 400 terméke kapta meg a Wi-Fi jelzést. A köznapi szóhasználatban a Wi-Fi-t gyakran azonosítják az IEEE 802.11-es család tagjaival illetve leggyakrabban a 80211b-vel, hasonlóan, ahogy a vezetékes hálózatokban az Ethernet kifejezést használjuk a 802.3 helyett [1]. 1.2 A WLAN hálózatok fizikai rétege A következ kben tárgyalt spektrumkiterjesztéses technikák WLAN esetében kizárólag a zavarok és az interferenciák káros hatásait hivatottak csökkenteni. Érdekességük, hogy egészen a 80-as évekig szigorúan katonai titkoknak min sültek az immáron polgári életben is el szeretettel használt eljárások. Az IEEE 802.11 szabvány által meghatározott fizikai réteg, két különböz rádiófrekvencia kiterjesztéses sémát tartalmaz (1. ábra ): –7– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 1.

ábra Szórt spektrumú kódolási módszerek a közvetlen sorrendes szórt spektrumú rádiós összeköttetést (DSSS = Direct Sequence Spread Spectrum) frekvenciaugratásos szórt spektrumú rádiós összeköttetést (FHSS = Frequency Hopping Spread Spectrum) Az FHSS a rendelkezésre álló frekvenciatartományt 7 csatornára osztja. Keskeny sávú hordozóhullámot alkalmaz, amely folyamatosan változik egy 2-4 szintes Gauss-féle frekvenciaváltó kódsorozat (GFSK) alapján. Más szóval, az adatátvitel frekvenciája folyamatosan pszeudovéletlen módon változik, amely szekvenciát mind az adó, mind a vev állomás ismeri. Az eljárás biztonságosnak tekinthet , de megvalósítása bonyolultabb a DSSS-nél. Illetéktelenek valószín leg nem tudhatják, hogy mikor melyik frekvenciára
váltsanak ahhoz, hogy a teljes adatfolyamot megkaphassák. Az FHSS másik el nye, hogy ugyanazon fizikai térben egyszerre több hálózat m ködhet párhuzamosan. Beszélhetünk gyors


FHSS-r l és lassúról. Az els esetben a bemen adat „0” és „1” közötti váltása esetén is lehet frekvenciaváltás, a második esetben a váltás több nagyságrenddel lehet hosszabb id tartamú. A 802.11b szabvány nem írja el FHSS használatát, de ajánlja A DSSS az adatfolyamot, egy nagyobb sebesség digitális kóddal szorozza össze. Minden
egyes adatbitet olyan mintába ágyaz, ami csak az adó- és a kívánt vev állomás által ismert. –8– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Ezt a bitmintázatot chip kódnak nevezik. Ez a kód magas és alacsony jelek álvéletlen sorozata. Ezt a "forgácskódot" invertálva „0”-t kapunk, nem invertálva pedig az adatfolyam „1” értékét kapjuk. Az IEEE 802.11 11 Mchip/s-os kódot alkalmaz A kódolóba betáplált adat sávszélességének tizenegyszerese lesz a kimeneten, ezt követ en a kapott jel sávszélességét modulációs technikákkal le lehet

csökkenteni, a különböz modulációk különböz átviteli sebességeket tesznek lehet vé. Ilyenek 1 Mbps esetén a DBPSK (Differential Binary Phase Shift Keying), 2 Mbps esetén a DQPSK (Differential Quadrature Phase Shift Keying) és 5,5 illetve 11 Mbps esetén a CCK(Complementary Code Keying). Az IEEE 802.11b eszközök a 2,4 GHz-es ISM frekvenciasávot használják kommunikációra, azon belül pedig szabvány szerint 14 csatorna van kiosztva, 5 Mhz-es távolságra egymástól. A csatornák száma és kiosztása azért fontos, mivel országonként, illetve régiónként eltér számú csatornák használhatók. Amerikában az 1-11, Európában az 1-13, Japánban egyedül a 14. csatorna engedélyezett A 802.11b eszközök rádiófrekvenciás spektruma
kb. 22 Mhz sávszélesség Ebb l következik, hogy az egyes csatornák között átfedés jön létre, de az alkalmazott DSSS technika miatt ez nem jelent hátrányt. Létezik átlapolódás-mentes kiosztás is, ekkor

mindössze 3 csatorna (ált. 1,6,11) osztható ki a frekvenciasávban A csatornák kiosztása függ a WLAN topológiától. Infrastruktúra hálózatban manuálisan kell beállítani (vagy ha nem állítjuk be, a gyárilag beállított lesz érvényes) a használt frekvenciát minden egyes AP-on. Ad-Hoc esetben minden 802.11 eszköz ugyanazon (a beállított, vagy amelyen másik eszközt talál) a csatornán kommunikál. Az IEEE 802.11g rendszerben ortogonális frekvenciaosztásos multiplexálást (Orthogonal Frequency Division Multiplexing - OFDM) használnak. Ennek is létezik több válfaja: BPSK-OFDM, QPSK-OFDM, 16QAM-OFDM, 64QAM-OFDM. Ez egy összetett modulációs módszer, egyfajta többviv s átviteli rendszer, melyben a rendelkezésre álló frekvenciasáv gazdaságos kihasználása érdekében az egyes viv k ortogonálisak (fázisuk 90°os egymásra). Ezzel a fizikai rétegben a bitsebesség a frekvenciák számának megfelel en ned részére csökken (ahol n a

használt frekvenciák száma) Ez biztosítja fading-gel terhelt csatornában a rendszer jó teljesít képességét, a többutas terjedésb l fakadó hibák elleni –9– http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv védelmet. A 802.11b szabványú hálózatokban Direkt Szekvenciális Szórt Spektrumú átvitelt alkalmaznak. A szórt spektrumú átvitel f célja itt a zajvédelem, ami az ISM sáv miatt különösen fontos, mert itt több zavarforrás is található – mikrohullámú-süt , Bluetooth eszközök, rádióamat rök, stb. Mivel minden 802.11b eszköz ugyanazzal a chip kóddal dolgozik, az azonos csatornát használók fizikailag „hallják” ugyan egymást, de a nem nekik címzett csomagokat eldobják, nem továbbítják a fels bb rétegek felé. Ilyen, közös csatornát használó rendszerekben a rendelkezésre álló sávszélesség megoszlik a felhasználók között. Biztonsági szempontból sem el nyös, hogy a kártyára van

bízva a csomagok szelektálása, hiszen megfelel firmware módosítással megszerezhet k, és egy speciális programmal feldolgozhatók a másnak címzett csomagok. Ez egy komoly biztonsági rés a rendszeren, melyet mindig ki is használnak a hálózatba illetéktelenül bejutni szándékozók. A DSSS nem nyújt megfelel védelmet a fading ellen (mivel egy viv van), ezért többutas terjedés okozta fading ellen Rake-vev alkalmazásával védekezik a berendezés. Nem egy vev t, hanem több, fázisban eltolt vev t valósít meg (külön-külön korrelátorokkal), illetve diversity-vétellel, azaz kett vagy több térben különálló vev antennával. Emiatt található általában kett antenna az AP (Access Point)-ok és a hálózati kártyák többségén. A WLAN eszközök esetében – mivel általában mobil alkalmazásról van szó, közel van az emberi testhez az antenna – felmerül a kérdés, hogy milyen biológiai hatásai lehetnek. Mivel ez folyamatosan sugároz, szemben

egy GSM telefonnal, ami csak bizonyos id közönként
m ködik adóvev ként. A szórt spektrumú sugárzás és a használt néhányszor 10-100mW-os teljesítmények miatt a magas frekvencia élettani és biológia hatásai – egyes irodalmak szerint – eliminálódnak, ugyanis a spektrum elken dik, mintegy belesimul a háttérzajba. Maximális teljesítményszintek (általában földrészenként változó): USA: 1W Európa:100mW – (Magyarország: nem tisztázott) Japán: 10mW. – 10 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Az IEEE 802.11 szabványcsalád tagjainak összehasonlítását az 1 táblázatban láthatjuk: Szabvány IEEE 802.11 IEEE 802.11a IEEE 802.11b Adatsebesség, frekvenciasáv Maximum 2 Mbps, 2,4 GHz-es sávban Maximum 54 Mbps, 5 GHz-es sávban Maximum 11 Mbps, 2,4GHz-es sávban IEEE 802.11g Maximum 54 Mbps, 2,4GHz-es sávban Összeköttetés FHSS vagy DSSS OFDM DSSS és CCK OFDM 20 Mbps felett, alatta DSSS és CCK

1. táblázat Az IEEE 80211 család 1.3 Vezeték nélküli hálózatok közeghozzáférési módszerei WLAN rendszerben kétféle közeghozzáférési módszer létezik.
Az egyik a Distributed Coordination Function (DCF): elosztott rendszerben m ködik, a terminálok ugyanazon szabályok szerint, egymással versengve férnek hozzá a csatornához, nincs központi dönt bíró. A másik a Point Coordination Function (PCF): olyan centralizált rendszer ahol a terminálok igényei alapján az AP dönt a csatorna felhasználásáról. A közeghozzáférés vezérlése általában a következ képpen történik. Az adni kívánó állomás figyeli a közeget (belehallgat) – ha az foglalt, akkor kés bbre halasztja az adást, ha szabadnak érzékelte, akkor megkezdi az adást. El fordulhat, hogy egyszerre több állomás is szabadnak érzékeli a közeget, és ezért egyszerre kezdenek el adni. Ilyenkor ütközés lép fel Az ütközést fel kell tudni ismerni, a csomagokat pedig

újra meg kell próbálni elküldeni. Nem szabad hagyni, hogy a fels bb rétegnek kelljen a hibát kezelnie, mivel ez lassuláshoz vezetne. Vezetékes hálózatokban az adóállomás ismeri fel az ütközést azáltal, hogy adás közben hallgatja a csatornát, és ha nem ugyanazt hallja vissza, mint amit beküldött, akkor ütközés lépett fel. Ha ütközés volt, vagy foglalt volt a csatorna, akkor az állomás újraadási fázisba lép át, ahol az exponential random backoff algoritmust használja arra, hogy álvéletlen id közönként újra próbálja adni a csomagját. Ezt az eljárást, pl Ethernet hálózat esetén, CSMA/CD (Carrier Sense Medium Access/Collision Detection)-nek hívják.
WLAN-oknál a CD (Collision Detection) megvalósítása nem célszer , mert egyrészt ehhez – 11 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv full duplex rádiós képesség kellene (egyszerre kellene rádiófrekvencián venni és adni az eszköznek).

Ez gyakorlatilag megvalósítható lenne, de az alkalmazott technológia miatt megoldása drága és bonyolult, ezért nem használják. Másrészt szembe kerülünk az úgynevezett rejtett terminál problémával (2. ábra), hiszen az adó nem mindig tudja érzékelni, hogy a vev nél ütközés lépett fel. Tegyük fel, hogy két

állomás (A és C jel ) kíván egyszerre adni egy harmadik (B jel ) állomás felé. Viszont A és C állomás egymás jeleit nem képesek venni a köztük lév távolság miatt. 2. ábra A rejtett terminál probléma Ilyenkor mindkét (A,C) állomás szabadnak érzékeli a csatornát, és adni kezd, ami viszont a vev állomásnál (B) csomagütközéshez vezet. Ez lehetetlenné teszi a kommunikációt, a CD technika pedig ennek a feloldására nem képes. Ezért a WLAN-oknál CD helyett CA-t (Collision Avoidance) használnak. CSMA/CA esetén az állomások figyelik a közeget, ha az foglalt, akkor várnak egy álvéletlen generátorral sorsolt

ideig. Ezután megvizsgálják ismét a csatornát, ha ezt szabadnak érzékelték egy bizonyos ideig, akkor a terminálok elkezdik a véletlenszer késleltetési id csökkentését.
Adást akkor kezdhetnek, ha késleltetési idejük 0-ra csökken. Amennyiben szabadnak érzékelték ugyan a csatornát, elkezdtek adni, de ez egy másik állomással egyid ben történt – azaz nem érkezett nyugta –, ismét várniuk kell egy véletlenszer késleltetési ideig. Ennek az
id nek a csökkentése is hasonlóképpen történik, mint foglalt csatorna esetén. Az el z ekben említett rejtett terminál probléma kiküszöbölhet , valamint az ütközések száma tovább csökkenthet az RTS és CTS (Request to Send és Clear to Send) vezérl – 12 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv keretek alkalmazásával.
Az adó állomás el ször egy RTS üzenettel jelzi, hogy adni kíván, erre egy véletlenszer en sorsolt id (SIFS) eltelte után

egy CTS üzenetet kap válaszul, ami azt jelenti hogy elkezdheti
az adást. Ha nem kap ilyet, akkor vár egy véletlenszer ideig (DIFS) és újra küld egy RTS-t A sikeres adatküldés után a vev egy nyugtázó ACK (Acknowledgement) üzenettel jelzi, hogy megkapta az adatot. Amennyiben az adóállomás nem kap nyugtát, újra kell adnia a keretet. Ekkor ismét alá kell vetnie magát a közeghozzáférésért folytatott versenynek Az RTS és CTS cseréjét virtuális viv érzékeléses mechanizmusnak (3. ábra), vagy másnéven „négyutas kézfogás”-nak (Four Way Handshaking) is nevezik. [2] 3. ábra A rejtett terminál probléma – 13 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 1.4 WLAN topológiák Alapvet en két féle WLAN hálózati topológiát különböztethetünk meg: Infrastruktúra hálózat (4. ábra) Ad-Hoc üzemmód. A továbbiakban áttekintjük az említett hálózat kialakítási lehet ségeket. 1.41 Infrastruktúra

hálózat 4. ábra Infrastruktúra hálózati topológia A WLAN hálózat alapjául egy úgynevezett access point, másnéven hozzáférési pont szolgál. Ez egy olyan hálózati aktív eszköz, mely hasonlóan m ködik, mint egy switch. Rendelkezik
egy UTP aljzattal, amin keresztül vezetékes hálózathoz csatlakoztatható. A beérkez csomagokat elosztja és szórja a kliensek felé, illetve ellenkez irányban a kliensek forgalmát továbbítja a vezetékes vagy vezeték nélküli hálózati eszközökhöz. E mellett a forgalom felügyeletéhez szükséges beállítási lehet ségeket is a rendelkezésünkre bocsát. A WLAN hálózatban az egyes cellákat Basic Service Set-nek (BSS) nevezik, ezeket a bázisállomások irányítják, melyeket hozzáférési pontnak (Access Point - AP) neveznek. – 14 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv A kliens általában egy vezeték nélküli hálózati csatolóval ellátott számítógép.

Elméletileg egyetlen cellával is kialakítható vezeték nélküli hálózat, leggyakrabban mégis több cellából álló rendszereket valósítanak meg, ahol a hozzáférési pontok valamilyen (általában vezetékes) gerinchálózaton, elosztórendszeren (Distribution System - DS) keresztül kapcsolódnak egymáshoz, azaz egyben hídként is funkcionálnak a vezetékes hálózat felé. Logikailag (és általában fizikailag is) elkülönül a BSS-en belül használt átviteli közeg az elosztórendszer átviteli közegét l. A teljes összekapcsolt WLAN – beleértve a különböz cellákat, a hozzájuk tartozó hozzáférési pontokat és az elosztórendszert – a fels bb rétegek
számára egy egyszer Ethernet hálózatnak látszik és Extended Service Set-nek (ESS) nevezik. Korábban a hozzáférési pontoknak egyetlen üzemmódjuk volt, ami arra szolgált, hogy az infrastruktúra üzemmódban dolgozó klienseszközök, access pointokon keresztül kapcsolódhassanak

a vezetékes hálózatra. A gyártók 2001-t l elkezdtek új szolgáltatásokat építeni AP-ikbe: ilyen volt például a bridge (híd) funkció. Ennek segítségével egy hozzáférési pont (AP) csatlakozhatott egy másik AP
hez, s így valós vezeték nélküli hídként (bridge) m ködtek. A ma megvásárolható AP-k közül a legtöbb gyártó eszköze képes az AP és a Híd funkció együttes megvalósítására, ezért ezen eszközök új nevének az „AP/Híd” nevet kellene inkább választani, ugyanis sok felhasználó nincs igazán tisztában azzal, hogy milyen lehet ségeket nyújt a készülék. 1.42 Cellaváltás infrastruktúra hálózatban Mikor egy 802.11 eszköz mozog és elhagyja a lefedett területet, új kapcsolatot kezd keresni Míg egy beszédátviteli rendszerben egy pillanatnyi kapcsolatszakadás nem befolyásolja jelent sen a beszéd érthet ségét (hála az emberi agy csodálatos hibajavító képességének), addig egy csomagkapcsolt környezetben a

fels bb rétegbeli-protokollok hiba miatti újraadás kérése komolyan lecsökkentheti az adatátviteli teljesítményt. A 802.11 szabvány nem határozza meg, hogyan kell egy cellaváltási folyamatnak (handovernek) lejátszódnia, bár leír néhány alapelvet. Definiálja az aktív, illetve a passzív cellaváltást illetve az újraasszociálás folyamatát, amikor a mobil állomás az egyik hozzáférési ponttól átjelentkezik a másikhoz. – 15 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Megkülönböztetünk soft-handovert és hard-handovert. Az els esetben csomagvesztés és észrevehet teljesítménycsökkenés nélkül megy végbe a handover. A második esetben ennek ellenkez je jön létre. Természetesen nagy hangsúlyt fektetnek a soft módszer kidolgozására és megvalósítására mind a gyártók és szabványtervez k egyaránt.
A WLAN hálózatokban többek közt a soft-handover, az egyidej frekvenciaugratás illetve a


teljesítménykímél m ködés miatt is nagyon fontos a szinkronizáció megtartása. Ennek érdekében az AP rendszeresen, egy úgynevezett Beacon-keretet küld a mobil állomások felé. A Beacon-keret egy olyan speciális keret, amelyet a hozzáférési pontok sugároznak periodikusan és szinkronizációs információt, valamint rendszerinformációkat tartalmaznak. Infrastruktúra hálózatokban az állomások szinkronban maradását úgy érik el, hogy az összes mobil állomás periodikusan hozzáállítja óráját az AP órájához a Beacon keretek id információja alapján. A szabványban ezért definiáltak egy komplett mechanizmust, mely lehet vé teszi az állomások számára, hogy hosszabb id szakokra alvó (sleep) módba kerüljenek, anélkül, hogy információt veszítenének. A hozzáférési pont átmenetileg eltárolja (puffereli) az állomásokhoz érkez forgalmat, amíg az egyes állomások le nem kérik csomagjaikat egy Polling Request (lekérdezés)

révén, vagy míg meg nem változtatják
m ködési módjukat. Mint említettem, a szabvány a cellaváltásra két módszert definiált. Passzív esetben a kliens vár, hogy kapjon egy Beacon-keretet a hozzáférési ponttól, és ez után történik a handover. Aktív cellaváltáskor pedig a kliens megpróbál egy hozzáférési pontot találni egy ún. Probe Request keret küldésével, amelyre válaszként egy Probe Response-ot vár egy közeli AP-tól. A teljesítményfelvétel és az adatátviteli teljesítmény optimalizálásának érdekében mindkét módszer használható. – 16 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 1.43 Ad Hoc üzemmód 5. ábra Ad Hoc topológia Ilyen üzemmódja minden WLAN kártyának létezik, arra az esetre, ha nem talál infrastruktúra hálózatot, ekkor önszervez d módon az egyes kliensek Ad Hoc (5. ábra) alakítanak ki egy topológiát. Ad Hoc esetben az összes állomás aktív módszerrel

(DCF) verseng a használt csatorna használati jogáért, és próbálja elküldeni csomagját a címzettnek. Ebben az esetben nincs egy kitüntetett, a forgalmat szabályozó eszköz (mint infrastruktúra esetbe az AP), ezért csomagütközésre is gyakrabban kerül sor. Csatornaváltásra az Ad Hoc hálózat szerepl i önállóan nem képesek, a manuálisan beállítottat (vagy amin a hálózatot megtalálták) használják. Az Ad Hoc módszer el nyei: Egyszer en és gyorsan kialakítható vezeték nélküli kapcsolat.
Több, különböz eszköz (PCMCIA kártya, vezeték nélküli híd, PCI kártya, stb.) képes egymáshoz kapcsolódni. Természetesen az Ad Hoc módszernek, vannak hátrányai is: Az infrastruktúra üzemmódot használó kliensek nem csatlakozhatnak. – 17 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Valamennyi állomást ugyanarra az SSID-re (Service Set Indentifier), illetve csatornára kell hangolni. Az els negatívum nem

jelent igazi hátrányt. Ugyanis ha valaki csupán egy kis hálózatot akar létrehozni, abban könnyen ellen rizhet , hogy a felhasználók miként konfigurálják a klienseket, és könnyedén alkalmazhatók az új beállítások minden kliensen. Azonban ha valaki „HotSpot”-ot (vezeték nélküli internet hozzáférési lehet ség – általában nyilvános), vagy
nagyobb kiterjedés nem nyilvános WLAN hálózatot felhasználó kapcsolódhat, szüksége lesz az infrastruktúra akar kiépíteni, amelyhez sok módra, mivel így könnyebb a konfigurálhatóság, nem kell mindig felhívni a figyelmet az Ad Hoc módba kapcsolásra, stb. A második negatívum abban az esetben lényeges, ha a felhasználók száma nincs korlátozva
illetve nagyobb kiterjedés a hálózat. Mivel minden vezeték nélküli kliens kénytelen ugyanazt a csatornát használni a sávszélesség megoszlik a kliensek közt, amely több felhasználó esetén nagyságrendekkel visszavetheti a hálózat

átereszt képességét. 1.44 Vezeték nélküli hidak A vezeték nélküli hidak (WEB – Wireless Ethernet Bridge ) segítségével Ethernet hálózatokat
köthetünk össze nagyon egyszer en és gyorsan (6. ábra) Ezen WLAN eszközök legfontosabb
tulajdonsága, hogy nem tudnak AP-ként m ködni. Tehát nem rendelkeznek olyan beállítási lehet séggel, mellyel az infrastruktúra üzemmódba kapcsolhatóak lennének, és klienseket tudnának kiszolgálni. Egyetlen kapcsolatteremt képességük van, az Ad Hoc üzemmód A WEB-ek hasonlóan az AP/hidakhoz képesek Pont-Pont, illetve Pont-Multipont kapcsolatokat létrehozni. Az Ad Hoc kapcsolat segítségével a WEB-ek képesek arra, hogy egyszerre szolgáljanak ki egy másik WEB-et, azon keresztül egy másik, ugyancsak WLAN kliens eszközt, egyszerre képesek kapcsolódni WEB-hez és klienshez egyaránt. Ezt az elrendezést az Ad Hoc módszert nem használó AP/hidak nem képesek létrehozni. A WEBeknek további el nye az

AP/hidakhoz képest, hogy infrastruktúra elrendezésben (nem APként, Ad Hoc üzemmódban) elméletileg akármilyen gyártótól származó 80211b típusú APvel, vagy vezeték nélküli routerrel képesek hidat képezni, nem csak egy megegyez vel Ilyen elrendezés létrehozásához általában az szükségeltetik, hogy mindegyik WEB-nek megadjuk a másik hidat képez eszköz fizikai (MAC) címét. – 18 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 6. ábra Vezeték nélküli hidak 1.5 Biztonsági kérdések Mivel a vezeték nélküli hálózatok az információt rádiós úton továbbítják, ha nem alkalmazunk valami speciális védelmet, akkor könnyen lehallgathatóak, ezáltal kevésbé biztonságosak, mint a vezetékes társaik. A WLAN hálózatok adattovábbító közege is az elektromágneses hullám, így ezen rendszerek is ki vannak téve, hogy illetéktelenek hozzáférjenek az adatokhoz, lehallgassák, módosítsák azokat, vagy

támadást intézzenek a hálózat ellen. A behatoláshoz nincs szükség fizikai kapcsolatra, így a rossz szándék könnyebben érvényre juthat, mint bármely vezetékes hálózatnál. Ha a kommunikáció mindennem titkosítás nélkül
folyik, akkor könnyedén megszerezhet ek bels , céges információk, tisztán a hálózati forgalom megfigyelésével. A céges hálózatok szerverei bel támadás ellen nincsenek úgy védve, mint a küls k ellen, így nagyobb veszélyben vannak. Ezért fontos – ha vezeték nélküli hálózatot használunk –, hogy kell képpen odafigyeljünk a biztonságos kommunikációra. Hogy ne legyen teljesen védtelen a hálózat, az illetéktelen hozzáférések megakadályozására a WLAN szabványok tartalmaznak egy ún. vezetékessel megegyez biztonsági protokollt, a WEP-et (WEP – Wired Equivalent Privacy protocol). Elméletben ez a protokoll biztosítja a – 19 – http://www.doksihu WLAN hálózatok biztonsági analízise –

diplomaterv WLAN-on átvitt adatok titkosítását, valamint másodlagos funkcióként megakadályozza, hogy illetéktelenek hozzáférhessenek magához a hálózathoz. Vizsgáljuk hát meg ezt a protokollt, mennyire lehet hatékony a hálózatunk védelmére. 1.51 A WEP Számos vizsgálat szerint a WEP nem tölti be maradéktalanul a három funkcióját, a bizalmasságot (Confidentiality – az átvitt adat nem lehallgatható), az adat integritást (Data Integrity – az elküldött adatunk módosítás nélkül ér el a címzetthez) és az illetéktelen hozzáférést l való védelmet (Access Control). Sajnos 2001 augusztusától már nem jelent elfogadható védelmet, mivel a WEP matematikai alapjait a kutatók megingatták, az interneten találhatóak szoftverek, amelyek segítségével egyszer en feltörhet .
Általánosan a következ támadások fordulhatnak el : Passzív támadás: a hálózati forgalom statisztikai vizsgálatok alapján történ dekódolása. Aktív

támadás: illetéktelen eredet új információ beágyazása (injection) és ezáltal mások
téves információhoz juttatása. (Így kódok megszerzésére, a hozzáférési pont (AP) kijátszására (IP Redirection), vagy a forgalom dekódolására van lehet ség.) "Lexikonépít " (Decryption Dictionaries) támadás: a forgalom folyamatos figyelése és vizsgálata, elemzése, (Táblázatba rendezéssel a dekódoláshoz szükséges kulcsok el állítása, amellyel a kés bbiekben a teljes forgalom valósidej dekódolása lehetséges.)
A WEP protokollnak a 802.11 szabványokban alapvet en három f funkciója lenne: biztosítja az átvitt információ védettségét, kódolva az átvitelt, megakadályozza az illetéktelen belépését a vezeték nélküli hálózatba, védettséget biztosít a módosított információ visszajuttatása ellen. A WEP m ködése (7. ábra) egy titkos kulcson (k) alapul, amelyet valahogyan megosztanak a
kiinduló tagok (a titok

megosztására nem tesz ajánlást a szabvány). A protokoll el ször egy ellen rz összeget – amely független a k kulcstól – c(M) számol ki az átvivend üzenetb l (M), elvileg ez biztosítja az üzenet integritását, majd valamilyen algoritmus szerint választ egy kezd vektort (v) (Initialization Vector = IV) a kódoláshoz. A következ lépésben az RC4(v,k) algoritmus segítségével generál egy úgynevezett – 20 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv kulcsfolyamot (keystream), amely egy, a kódoláshoz szükséges titkosító adatfolyam. Végül el állítja a bejöv átküldend adatból, annak ellen rz összegéb l, és az RC4(v,k) titkosító adatfolyamból egy XOR kapcsolattal az átvinni kívánt titkosított információt (EncInf). EncInf = <M, c(M)> 
 RC4(v,k) Természetesen a titkosított adat mellett titkosítatlanul át kell adni az IV vektort, és a vev az IV és a közös titkos kulcs (k) segítségével

el tudja állítani a RC4(v,k) kulcsfolyamot, amivel
dekódolja – ugyancsak egy XOR m velet segítségével – az EncInf titkosított adatfolyamból az eredeti üzenetet. <M, c> = EncInf 
 RC4(v,k) A dekódolás után ellen rzi a M’ ellen rz összegét: c = c(M) Ha egyezik, akkor a kapott M’-et elfogadja, mint jó üzenetet. Nyílt üzenet CRC32 XOR Keystream = RC4(v,k) + IV = IV Kódolt jelfolyam 7. ábra A WEP működési elve Az RC4 algoritmus, mely egyébként kimenet visszacsatolásos folyamkódoló (OFB – Output FeedBack stream cipher) technikán alapul, jól ismert algoritmus, ezért nem magától az algoritmustól függ a titkosítás (a titkosított információ), hanem egyedül v és k (IV és a titkosító kulcs) tartalmától. A 802.11-es szabvány egyik nagy hiányossága, hogy nem rendelkezik a megosztott kód – 21 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv kezelésér l, nincs kell képpen

kidolgozva a szabvány ide vonatkozó része.

Az XOR m velet az úgy nevezett „One-Time-Pad” elnevezés , elvileg is bizonyítottan feltörhetetlen eljárások közé tartozik, abban az esetben ha ugyanaz a kulcs (RC4 keystream) nem kerül soha újbóli felhasználásra! Tételezzünk fel két, ugyanazzal a K kulccsal kódolt P1 és P2 üzenetet. Legyen C1 = P1

 K, C2 = P2 K Lehallgatjuk C1 és C2 kódolt üzenetet és
 C1
Egyszer C2 = P1
 K
 P2
 K = P1 
 P2 .
m veletekkel megkaptuk a két nyílt üzenet XOR kapcsolatát. Ahhoz, hogy valamelyiket megkapjuk ezután már elegend ismerni (megszerezni, vagy ismert üzenetet küldeni a hálózatba és visszahallgatni annak kódolt változatát) az egyik nyílt üzenetet és dekódolhatóvá válik a kódolt másik üzenet. Mivel a WEP algoritmus 24 bites kezd vektort (IV) használ, ez behatárolja a lehetséges IV-k számát ( 224~16,7millió), így szinte biztos, hogy ugyanazt a kezd

vektort relatíve rövid id közönként felhasználja a kódoló, tehát 16,7 millió csomag forgalmazása után biztosan ugyanazzal a kulcsfolyammal lesz kódolva a nyílt üzenet. Ráadásul a legtöbb 802.11 eszköz nullázza a saját kezd vektort minden aktiválódás (feléledés alvó állapotból, bekapcsolás) esetén és növeli azt 1-el minden csomag átvitelekor, ez annyit
tesz hogy sokkal nagyobb valószín séggel fognak kis IV értékek el fordulni átlagos kommunikáció során. És mivel egyazon kulcsot egyszerre több eszköz is használja, a helyet meg ennél is rosszabb. A "Lexikonépít " támadás a rendszernek ezen hiányosságait használja ki. A módszer feltételezi, hogy egy adott IV vektor felhasználásával van kódolva egy, a támadó által is ismert nyílt üzenet. Ilyen könnyen el állítható ping-elés, mail, stb küldésével a hálózatba,
vagy egyszer en csomagütközések figyelésével, mert így nagy mennyiségben el

állíthatjuk ismert kódolatlan üzenet kódolt párját. Ezután már kiszámíthatóvá válik az RC4(v,k) keystream a nyílt és rejtjelezett üzenet XOR kapcsolatba hozásával, azonban a k titkos kulcsot nem ismerjük, de nincs is rá szükség. A – 22 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv módszer lényege, hogy egy táblázatban kell tárolni a megfejtett RC4 keystream-et (minden csomagét külön-külön), a táblázat indexei legyenek az adott csomag IV vektorai. A táblázat maximális mérete ~ 24 GByte lesz 1500 byte-os csomagméret mellett. Másképp megközelítve, egy forgalmas 11 Mbps-os access point, ami 1500 byte-os csomagokat küld (ez a Maximum Transfer Unit – MTU), ~18000 másodperc (5 óra) alatt kimeríti az IV-k összes lehetséges variációját. Ezután, ha meg szeretnénk kapni egy tetsz leges, kódolt üzenet tartalmát, nincs más dolgunk, mint a kódolt üzenet ismert IV vektorához tartozó RC4

keystream-et kiolvassuk a táblázatból és XOR kapcsolatba hozzuk a rejtjelezett üzenettel. A

táblázat méretei jóval kisebbre adódhatnak ha feltételezzük, hogy viszonylag s r n nullázódik az IV. levezetésben sehol nem szerepelt a k kulcs bit értéke (amit általában Mivel az el z feltüntetnek a 802.11 eszközön – 64 vagy 128 bit), nem befolyásolja az üzenetek ilyen módszerrel történ visszafejtését! Az adat integritásának ellen rzést a CRC-32 algoritmus segítségével végzi a protokoll, ami egy széles körben ismert hibaellen rz módszer. E módszer legf bb problémája az, hogy lineáris: c(M
 D) = c(M)
 c(D) és független az adott üzenet IV vektorától és k kulcsától. Ez egy ugyancsak súlyos problémára
hívja fel a figyelmet, az egyszer üzenetmódosítás lehet ségére – a CRC hatékony a véletlen hibák detektálására, de a szándékos módosítások ellen nem nyújt igazi védelmet. Adott egy c(M) kódolt

üzenet(lehallgatott, de nem megfejtett), de módosítani szeretnénk és a vev be már a saját ál-üzenetünket akarjuk eljuttatni. A módosítás, amit az eredeti üzeneten alkalmazni szeretnénk, legyen D, egy bármilyen szabadon választott információ. Azt szeretnénk, hogy a vev F = M
 D hamis információt kapja meg, és fogadja el. Mivel a CRC-32 módszer lineáris, és független, hiába van kódolva RC4(k,v) kulcsfolyammal, hiszen a linearitás (asszociativitás) miatt kijátszhatóvá válik a kódolási algoritmus a következ képpen.
Egyszer en küldjük el az alábbi üzenetet: C = C
 <D,c(D)> – 23 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv A vev az alábbi módon kódolja vissza az üzenetet: <M,c> = C = C

 <D,c(D)> = <M,c(M)> = <M = <M RC4(v,k)



 RC4(v,k) <D,c(D)> D, c(M) D, c(M

 c(D)> D)> = <F, c(F)> Leellen rzi az ellen

rz összeget is: c= c(M ), és helyesnek találja, mivel mindkett c(F).

Ilyen egyszer en levezethet , hogy a feltételezett támadás sikerrel jár és az egyszer en beillesztett tetsz leges információt fogja a vev dekódolni. Hasonlóan az el z ekhez létrehozható egy teljesen a saját információval feltöltött csomag is, amelyet a kommunikáló felek eredetinek fognak felismerni.
Mivel ennyire védtelen a hálózat, a behatoló egyszer en juthat hozzá olyan információkhoz
is, amelyek az azonosítást szolgálják. Ennek egyszer sége abban rejlik, hogy az AP a „k” titkos kulcs alapján azonosítja a bejelentkez t (Authentication Spoofing):
Az AP küld egy Ch(Challange) véletlenszer sztring üzenetet a kliens felé, amely visszaküldi azt Re(response) WEP protokollal (k kulccsal) titkosítva. Az AP leellen rzi és ha helyesnek találja azt, kommunikálni fog a klienssel. Ez a következ képpen játszható ki: A támadó keres egy Ch/Re párt adott k

kulccsal, kinyeri bel le a kódolatlan IV-t és a leírtak szerint el állítja az RC4(v,k) kódoló kulcsfolyamot. Ezután megpróbál csatlakozni a hálózathoz a következ képpen: Az AP miután „észrevette” a 802.11 eszközt, küld felé egy Ch sztringet (legyen most M ),a támadó válaszol a v,<M,c(M)>
 RC4(v,k) általa el állított üzenettel, anélkül, hogy ismerné a ’k’ kulcsot! Az AP, visszafejtve az üzenetet, kulccsal rendelkez nek fogja felismerni a támadó klienst, így kommunikálni fog – 24 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv vele. Ennek a módszernek a segítségével is dekódolhatunk csomagokat. Csatlakozunk a WLAN hálózathoz az el bb ismertetett módon (Authentication Spoofing), majd egy második Internet kapcsolat felhasználásával kívülr l az AP által kódolt csomagokat küldünk saját magunknak. Az AP másodszor is kódolni fogja azt, elegend próbálkozás után valamikor ugyanazt

az IV-t fogja használni és a második kódolás egyben a dekódolást fogja jelenteni (dupla XOR
m velet). Ez a módszer nem túl hatékony, mivel lehet, hogy nagyon sokat kell várni a megfelel IV-re. Másik lehetséges módszer, hogy az IP csomag fejrészének módosításával (IP Redirection) a hozzáférési pont a csomagot dekódolás után másik (vezetékes hálózati kapcsolattal rendelkez ) számítógépre továbbítsa, így ott el áll a kódolatlan tartalom. A támadáshoz el ször csatlakozni kell a hálózathoz az el z ekben leírt Authentication Spoofing módszerrel, majd a csomagok fejlécében lév IP címet kell módosítani a megfelel re (mutattam módszert a dekódolás nélküli módosításra). Az IP cím módosítása után a csomagot eredetiként feltüntetve vissza kell küldeni az AP felé, amely a saját kulcsával dekódolni fogja azt és továbbítja a módosított IP címre az immár nyílt információt. Ha a WLAN hálózatot
megfelel en

felkonfigurált t zfal választja el a vezetékes hálózatról, akkor ezzel a módszerrel igen nehéz illetéktelenül információhoz jutni. A leírtakon kívül vannak még más módszerek is, de az eddigiekre épülnek, azok kombinációi amelyek különböz hálózati lehet ségeket használnak ki.

A fent leírt támadások nem túl egyszer ek. A biztonsági rések kihasználásához valószín leg módosítani kell a 802.11 eszköz firmware-ét, driver-ét ahhoz, hogy a fels bb protokollok részére is továbbítsa a nem neki címzett csomagokat az eszköz. Ezenkívül speciális
programot kell írni, amely együttm ködik az így módosított eszközzel, driverrel. Érdekesség, hogy az USA-ban például nem ritka dolog az úgynevezett “war driving”. A kifejezés azt takarja, hogy egy WLAN eszköz és hordozható számítógép (Laptop, PDA) segítségével furikázva a városban ingyen Internet, vagy a bels hálózaton elérhet információk után kutatnak. Ezt

a tevékenységet a legtöbb országban büntetik, de az elkövet t nehéz tetten érni, vagy utólag megtalálni. Ha, a használható hálózatra bukkanó, ezt a többi hasonló módszerrel „dolgozó” társával is – 25 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv tudatni akarja, akkor egy krétával, megfelel jelet fest az épület falára. Ezt hívják “warchalking”-nak. A WLAN hálózat tehát korántsem tekinthet
célszer minden szempontból biztonságosnak, ezért másodlagos biztonsági szolgáltatásokat beépíteni, amelyek garantálják adataink védelmét és a felhasználók azonosítását. Ilyenek lehetnek például az IPSec (Internet Protocol Security), VPN (Virtual Private Network), SSH (Secure Shell), stb. Hasonlóan kell kezelni a

WLAN–t, mint egy nyílt Internethez csatlakozó, t zfal nélküli hálózatot. Ezért t zfallal ajánlott védeni a bels vezetékes hálózatot is a WLAN–tól. A WEP

problémáira lehetséges megoldás lenne a hosszú ’k’ kulcsok használata helyett a hosszú IV-k használata, IV-k álvéletlen kiosztása, a CRC-32 helyett egy er sebb, nemlineáris üzenetazonosító kód használata (például SHA1, MD5). [3] [4] Mivel a WEP protokoll fentebb említett hiányosságaival a szakemberek is teljesen tisztában vannak, elkezdtek kidolgozni a WLAN hálózatokhoz olyan biztonsági protokollokat, amelyek javítanak a WEP hibáin. Lássunk ezek közül néhányat 1.52 Az EAP Extensible Authentication Protocol (EAP): Az IEEE 802.1X szabvány definiál egy általános hálózathozzáférési infrastruktúrát, ennek elterjedtebb neve az EAP. Igaz, hogy alapvet en vezetékes hálózatokra tervezték, de kisebb módosításokkal vezeték nélküli hálózatokhoz is használható. A WEP ellen indított támadások nagy része elkerülhet lenne, ha a WEP kulcsok bizonyos id közönként megváltoznának, hiszen a fent leírt módszerek mindegyike viszonylag

hosszabb id t vesz igénybe. A 80211-es szabvány nem nyújt lehet séget a kulcsok hatékony, automatikus cseréjére. Egy kisebb hálózatnál a rendszergazda még esetleg megváltoztathatja id nként a kulcsokat, de egy nagyobb, akár többszáz csomópontból álló hálózatnál ez lehetetlen. Az EAP segítségével automatikusan megvalósítható a WEP kulcsok rendszeres cseréje, és így a forgalom megfelel titkosítása, illetve az authentikáció számos formáját támogatja, mint például a Kerberos-t, az egyszer használatos jelszavas authentikációt (one-time password), a – 26 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv tanúsítványokat (certificates) és a publikus kulcsos azonosítást. Az EAP néhány elterjedtebb változata: EAP-MD5: A RADIUS szerver a klienseket a felhasználó jelszavának MD5 hashe
alapján azonosítja. Ez a módszer nagyon egyszer , és vezetékes környezetben jól is használható. De mivel

vezeték nélküli hálózatban az elküldött MD5 hash könnyen lesniffelhet , így ez a változat WLAN-on nem ajánlott. LEAP (Lightweight EAP): A Cisco által kidolgozott és támogatott protokoll. Egy fokkal tovább lép, mint az EAP-MD5, kétoldali (szerver <–> kliens) azonosítást igényel, és a WEP kulcsok átvitelére is lehet séget ad. Mivel ezt a változatot viszonylag régebbi Cisco
eszközök is támogatják, olyan hálózatban, ahol ilyen termékek vannak jelen, ez egy egyszer és gyors választás lehet. EAP-TLS (RFC 2716 - Transport Layer Security): Biztonság és támogatottság szempontjából a legjobb. A kölcsönös (szerver <–> kliens) azonosítás kötelez , és digitális tanúsítványokon alapul. Számos kliens platformon (Linux, Windows, MacOS X) és RADIUS szerverrel (Cisco, HP, Microsoft, FreeRADIUS) használható. El nye egyben hátránya is, a
m ködéshez teljes PKI (Public-Key Infrastructure) infrastruktúra szükséges, ez pedig

sok esetben nem kivitelezhet . EAP-TTLS (Tunneled Transport Layer Security): A kliens oldali tanúsítványok kiküszöbölésével jött létre ez az EAP változat. A szerveroldalon továbbra is szükség van rájuk, de a kliens már jelszóval azonosítja magát hagyományos protokollokkal (CHAP, MSCHAP, stb.) Az elterjedt operációs rendszerekre létezik megvalósítás, és többféle RADIUS szerver közül választhatunk (Funk, Meetinghouse). PEAP (Protected EAP): Nagyon hasonló megoldás mint a TTLS, ennek f támogatója a Microsoft és a Cisco. Mostanra talán már jobban támogatott mint a TTLS, és a Windows XP (SP1) is tartalmazza. – 27 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 1.53 A WPA Wi-Fi Protected Access (WPA): A WEP hibái miatt az IEEE új szabványt kezdett kidolgozni (IEEE 802.11i), amelyr l jelen pillanatban annyit tudni, hogy valószín leg valamikor idén
jelenik meg a végleges változat. Az ipar hamarabb akart

lépni, és létrehozták a WPA-t, mely gyakorlatilag a 802.1X, az EAP és a TKIP (Temporal Key Integrity Protocol) összegeként képzelhet el. A f cél az volt, hogy a meglév hálózati kártyák és AP-k firmwarejét frissítve egy szabványos és biztonságos megoldást kapjunk. A szabvány kötelez vé teszi a gyakori kulcscserét, és bevezet egy új visszajátszás elleni védelmet. Jól skálázható megoldás nagy, közép vagy kisvállalati szinten is. A WPA az authentikációt a már említett 802.1X protokollal végzi, az EAP-TLS változattal Authentikációs szervernek valamilyen RADIUS szerver használható. Az EAP leírásánál is el került a RADIUS (Remote Access Dial-In User Service) protokoll. Eredetileg a RADIUS betárcsázós kapcsolatokhoz tervezett AAA (Authentication Authorization Accounting) protokoll. Négy fajta üzenettípus vesz részt a kommunikációban (Kérés – Request, Kihívás – Challenge, Elfogadás – Accept, Elutasítás – Reject), az

azonosítást kér access point Kérés üzeneteket küld az azonosító szervernek, amely a szituációnak megfelel en a másik három üzenettípus valamelyikével válaszol. El nye más AAA rendszerekhez képest, hogy nagyon sok implementációja létezik szinte minden operációs rendszerre – kereskedelmiekre és nyílt forrásúakra is –, mindenki kiválaszthatja a neki legmegfelel bbet. Most, hogy a kliens azonosítását megoldottuk, már csak a hálózati forgalom titkosítását kell megoldanunk, illetve azt, hogy a kliens biztos lehessen benne, hogy a hálózatunk részét képez hozzáférési pontnak küldi az adatait, nem pedig egy támadónak. A WPA ezt úgy éri el, hogy négy utas kézfogás módszerével állapítja meg az ideiglenes kulcsokat. Ezek a kulcsok: Adat titkosító kulcs Adat integritás kulcs EAP titkosító kulcs – 28 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv EAP integritás kulcs Olyan hálózatokban, ahol

a felhasználó mozgása során access pointot válthat, ezek a kulcsok újra generálódnak. Ez biztosítja, hogy a felhasználó csak valódi hozzáférési ponthoz kapcsolódhat. Ezen kulcsok használhatóak a hálózati forgalom titkosítására is A kulcsok kiszámításához szükség van az authentikációs eljárás során megszerzett közös osztott titokra, két úgy nevezett nonce-ra (soha nem ismétl d véletlen szám) és a két eszköz MAC címére. Tehát: titkos kulcs + access point nonce + user nonce + access point MAC + kliens MAC -» ideiglenes kulcsok A négy utas kézfogás: 1. Az access point elküldi a nonce-át a felhasználónak, aki ebb l el tudja állítani az ideiglenes kulcsokat, hiszen 2. A felhasználó visszaküldi az már minden minden szükséges adatot ismer. nonce-át az EAP integritás kulccsal együtt, így az access point a kulcsok el állítása után ellen rizheti a felhasználó identitását. 3. Az AP visszaküld egy adat integritás

kulcsot és egy számot, ami az els titkosított csomagot jelöli majd. 4. A kliens ezt visszaigazolja egy üzenettel Ezután megkezd dik a kommunikáció az adat titkosító kulccsal titkosítva. A TKIP azért lett a WPA része, mert a meglév hardware eszközökkel könnyen együtt tud m ködni, és a WEP hibáit viszonylag jól orvosolja:
Integritás ellen rzés IV megfelel megválasztása Csomagonkénti kulcsváltás IV méretének megnövelése Láthatjuk, hogy a WPA elég jól javítja a WEP hibáit, de nem szabvány, hanem csak a Wi-Fi közösség által készített ajánlás addig, amíg nem készül el az IEEE által kidolgozás alatt lév 802.11i szabvány, amit a WPA után WPA2-nek is neveznek néha [5] – 29 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 1.54 IEEE 80211i – a jövő A WPA2-nek is nevezett 802.11i szabványon már több éve dolgoznak az IEEE szakemberei, de az egyeztetések még jelen pillanatban is tartanak. Egy

minden tekintetben tökéletes szabványt szeretnének kidolgozni, nehogy újra el fordulhasson az, ami a WEP-pel. (Mivel a WLAN eszközök gyártóinak lépnie kellett a piaci igények miatt, ezért alkották meg az el bb már említett WPA-t.) A 802.11i biztonsági alszabványa az úgy nevezett RSN (Robust Security Network) – er sen biztonságos hálózat. Az RSN olyan tulajdonságokat követel meg a vezeték nélküli kliensekt l és hozzáférési pontoktól – nagyobb feldolgozó képesség, bonyolultabb titkosító eljárások –, amelyekkel a meglév eszközök nem rendelkeznek. Ezért, hogy a váltás folyamatosan is végbe mehessen, és ne kelljen az összes eszközt egyszerre lecserélni, van mód arra, hogy az RSN-t és a WEP-et használó eszközök együtt tudjanak m ködni. Ennek neve: Transitional
Security Network (TSN). A hálózat természetesen mindaddig nem lesz sokkal biztonságosabb a WEP-es hálózatnál mindaddig, amíg az összes WEP-et használó

eszközt le nem cserélik olyanra, ami már támogatja az RSN-t. Az RSN és a WPA több dologban is hasonlóságot mutat. Ugyanazt a biztonsági architektúrát használják a magasabb szint azonosításra, a kulcsok szétosztására és a kulcs megújításra. A
WPA ellenben a TKIP köré épül, ami sok eszközhöz elérhet firmware frissítéssel, míg az RSN sokkal átfogóbb és AES (Advanced Encryption Standard) támogatás kell hozzá, ami csak a legújabb WLAN eszközökben található. Sajnálatos módon a 802.11i elfogadtatása még mindig folyik, habár ha minden jól megy most már hamarosan napvilágot lát a végleges változat. 1.55 Alternatív biztonsági megoldások Ha az el bb említett, a WLAN-hoz viszonylag szorosabban kapcsolódó biztonsági megoldások alkalmazása nem lehetséges a hálózatunkban – nem érhet el az eszközeinkhez megfelel fimware frissítés; több különböz gyártó termékeit használjuk, és örülünk, ha
egyáltalán együtt

tudnak m ködni az eszközök WEP-et használva –, még akkor is van lehet ségünk biztonságossá tenni a hálózatot. – 30 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Léteznek olyan megoldások, amelyeket vezetékes környezetben is el szeretettel használnak a biztonság fokozására, és ugyanúgy használhatóak vezeték nélküli környezetben, s t
kompenzálják a WLAN hálózatok azon hátrányait, amelyek az egyszer lehallgathatóságból fakadnak. Lássunk néhány ilyen módszert: 1.551 ACL alkalmazása ACL – Access Control List, azaz hozzáférés szabályzó lista. A hálózati kártya MAC címe alapján döntjük el, hogy valakit beengedünk-e a hálózatba vagy sem. Ez a módszer lehallgatás ellen nem véd, hiszen a hálózati forgalom titkosítatlan, de néhány környezetben ez nem is fontos. Például ha egy internetes hot-spotot szeretnénk létrehozni, amit azok a felhasználók használhatnak, akik el tte el

fizetnek a szolgáltatásra. Ez egy nagyon egyszer és gyors
megoldás, ámde a kommunikáló engedélyezett címek lehallgathatóak, és a támadó kártyája MAC címét egyszer en átállíthatja egy ilyenre. Adminisztrálás szempontjából gondot jelent,
hogy használat el tt regisztrálni kell a kártyákat, ráadásul a MAC cím a felhasználó számára gyakran nem is kérdezhet le könnyen (pl. PDA esetén) 1.552 Biztonság felsőbb rétegekben Bármilyen hálózatot is használunk, mindenképpen javasolt olyan alkalmazásokat használni, amelyek az alkalmazási rétegben végeznek titkosítást – a processzornak nem csinálunk túl nagy plusz munkát, adatainkat viszont megvédjük a támadóktól. A legtöbb hagyományos hálózati alkalmazásnak megvan a biztonságos megfelel je: Telnet (belépés távoli számítógépre) helyett mindenképpen javasolt például SSH-t (Secure Shell) használni. FTP (File Transzfer Protocol) helyett SCP-t (Secure Copy) illetve

SFTP-t (Secure FTP). A biztonságilag kritikus weboldalakat ajánlott HTTP (HyperText Transfer Protokol) protokoll helyett HTTPS (Secure HTTP) segítségével elérni. A bizalmas leveleket PGP-vel (Pretty Good Privacy) titkosítva kell elküldeni, hogy csak a címzett olvashassa el. Hogy ezeket használni tudjuk, az elérni kívánt szervereknek is támogatniuk kell ezen módszereket. – 31 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Keresnünk kell tehát valami olyan megoldást, amihez nem feltétlenül szükséges, hogy az elérni kívánt szerver tudjon róla, de a WLAN hálózatunkon belül a csomagok titkosítva közlekedjenek. 1.56 IPSec Az IPSec protokollcsomagot az IETF dolgozta ki, az egyes protokollok definícióit RFC-kben rögzíteték. Hitelesítést és titkosítást is végezhet, így nem csak a hálózati forgalom tartalmát védhetjük, de magának a hálózat használatát is megakadályozhatjuk illetéktelenek számára. Az

IPSec két szinten is végez hitelesítést: A kapcsolat felépítése során biztosítja, hogy a résztvev felek közvetlenül azzal veszik fel a kapcsolatot, akivel szeretnék. A felépült kapcsolatot csomagok szintjén is ellen rzi, hogy a kommunikációba ne avatkozhasson bele nemkívánatos résztvev . Az IPSec kódolás hibrid kulcsú titkosítást használ, amely azt jelenti, hogy mind a szimmetrikus, mind az aszimmetrikus titkosítást bevetik. Az IPSec két féle módban m ködhet: transzport vagy tunnel módban.
Tunnel módban (8. ábra ) egy teljesen új IP csomag generálódik, melynek új fejléce van, ez után jön az AH/ESP fejléc, és az ESP részbe belecsomagolva az egész eredeti IP csomag. Ez lehet séget ad arra, hogy az olyan eszközök, mint például a routerek IPSec proxy-ként funkcionáljanak, azaz a hostok helyett ezek végezzék el a titkosítást, és a dekódolást. A tunnel módban az IPSec-et alkalmazó gépek átjáróként funkcionálnak és

akárhány logikailag az átjáró mögött elhelyezkedõ gép forgalmát képesek továbbítani a tunnelben. A kliens gépeken semmilyen IPSec-hez kapcsolódó feldolgozást nem szükséges végezni, az egyetlen kritérium, hogy az útválasztó táblájukban szerepeljen a megfelelõ IPSec átjáró címe. Ez a módszer nagyobb védettséget nyújt a forgalomelemzés ellen, mivel az eredeti fejlécek is rejtve maradnak, így a támadó nem tudja, hogy pontosan hova voltak címezve a csomagok, csak azt, hogy melyik két átjáró között mentek át (még azt sem tudja megkülönböztetni, hogy konkrétan az átjárónak szóltak, vagy a logikailag a mögötte elhelyezked gépeknek). Transzport módban (9. ábra ) az AH/ESP fejléc az IP csomag eredeti fejléce mögé szúródik be, az IP payload elé (titkosítás használata esetén ez a payload rész titkosított). Itt az el z t l – 32 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv eltér en

host-host kapcsolat épül fel, amelynek résztvev i kizárólag azok a gépek, amelyek a kapcsolat végpontjai. Ez a mód kevésbé ellenálló a forgalomelemzés jellegû támadásokkal szemben, viszont el nye, hogy csak néhány byte-ot ad hozzá minden csomaghoz. A két mód tetszés szerint kombinálható egymással, azaz például két különböz alhálózatban található számítógép IPSec transport kapcsolaton keresztül kommunikál egymással, miközben a két hálózat között egy IPSec tunnel található. 8. ábra IPSec tunnel mód 9. ábra IPSec transzport mód 1.561 Az IPSec működése A IPSec infrastruktúra alapját az SA-k (Security Association) adják. Az SA az, ahol a konkrét implementáció és a heterogén környezet találkozik. SA-k más biztonsági protokollokban is léteznek, régebbiek mint maga az IPSec. Egy SA az alábbi összetev kb l épül fel: SPI (Security Parameter Index): 32 bites érték, az SA-k megkülönböztetésére szolgál. Cél IP

cím – 33 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Biztonsági protokoll azonosító Az SA határozza meg, hogy a két fél között AH vagy ESP (vagy esetleg mindkett ) segítségével épüljön ki a kapcsolat. Hitelesítéshez az IPSec az AH (Authentication Header) részt használja. Az AH opcionális fejlécként az IP csomag eredeti fejléce (header) és a hasznos adat (payload) közé épül be. A támadóknak többféle támadás esetén is módosítaniuk kell az IP csomag fejlécét (például spoofing). A hitelesítéshez az MD5 és az SHA algoritmusokat használja A küld kalkulál egy hash-t a fejléc bizonyos részeib l, és beleteszi az AH fejlécbe. A fogadó fél is elvégzi az el bbi számítást és összehasonlítja a kapott értéket a csomag fejlécben érkez vel. Módosítatlan csomag esetén a két értéknek egyeznie kell. A hash algoritmusok rendkívül megnehezítik az adatok módosítását a helyes ellen rz összeg

megtartása mellett. A számítások felhasználják a közös titkos kulcs értékét, így a támadónak szinte lehetetlen dolga van. Minden esetben a csomagfejléc tartalmaz egy “következ protokoll” mez t, amely megmondja a rendszernek, hogy milyen fejléc után kell néznie. Az IP fejlécek általában TCP, vagy UDP bejegyzést tartalmaznak ebben a mez ben, míg az IPSec hitelesítés alkalmazása esetén a mez értéke AH. Az AH rámutat, hogy a következ fejléc Authentication Header lesz és ez a fejléc pedig már általában TCP, UDP, vagy encapsulated IP csomagfejlécre mutat. Titkosításhoz az AH nem elég, erre való az ESP (Encapsulated Security Payload). Az ESP alkalmazható hitelesítésre és titkosításra egyaránt, illetve használható AH-val vagy anélkül. Az RFC szerint két titkosítási mód használható, a DES és a null titkosítás, valamint hitelesítéshez az AH-ban is használt MD5-öt vagy SHA-t. Ezeken kívül a konkrét implementáció más

algoritmusokat is támogathat. Napjainkban például a legtöbb implementáció a 3DES-t (triple DES) is támogatja, mivel ez bizonyítottan biztonságosabb a sima DES-nél. A kapcsolat paramétereinek megvitatása és a kulcsok cseréje az IKE (Internet Key Exchange)
protokoll segítségével megy végbe. Leegyszer sítve az IKE a kövtetkez protokollok kombinációja: ISAKMP (Internet Security Association and Key Management Protocol) – ez kezeli a kapcsolati paraméterek megvitatását, definiálja az SA-kat. – 34 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv IPSec DOI (Domain Of Interpretation) – Az ISAKMP szükséges kiterjesztései. Oakley key determination – A Diffie-Hellman kulcs csere protokoll egy speciális változata. Az IKE els fázisában a hostok hitelesítik egymást shared secret vagy RSA kulcs segítségével. A két fél felépíti a két irányú ISAKMP SA-t Ezt az ISAKMP SA-t felhasználva a két fél megvitatja a

szükséges IPSec SA-kat. Ezek egyirányúak, azaz minden irányban különböz kulcs van használatban, így mindig párokban kerülnek megvitatásra, hogy megvalósulhasson a kétirányú kapcsolat. Mindkét fázis az 500-as UDP portot használja. Aktuálisan az IPSec SA-k az ESP, vagy az AH protokollt alkalmazzák. Ezeknek a protokolloknak nincsen portja csak száma ESP esetén 50, AH esetén pedig 51. Az alap információkon túl mindkét fázisban akármelyik fél közölhet további információkat. Többek között az alábbi paraméterek kerülnek egyeztetésre: SA élettartama, azaz az a maximális id , amíg egy kulcs használatban lehet A titkosítási algoritmus A hitelesítési algoritmus Diffie-Hellman kulcs csere Az SA-k megvitatása során a kezdeményez több választási lehet séget kínál fel a másik félnek, aki ezek közül számára legmegfelel bbet választja ki, és küldi vissza a feladónak. Ezek után megindulhat a kommunikáció az egyeztetett

paraméterekkel. [6] [7] 1.562 IPSec és WLAN Mint láthattuk az IPSec tökéletes lehet a WLAN biztonsági problémáinak orvoslására, hatásosan véd a lehallgatás, illetve a csomagok módosítása ellen. Mint már említettem a WLAN hálózatunkat mindenképpen ajánlott egy t zfal számítógépével
elválasztani a vezetékes hálózatunktól. Ez a t zfal funkcionálhat IPSec átjáróként is A
vezeték nélküli kliens és a t zfal között IPSec tunnelt építünk ki, így a legvédtelenebb
szakaszon a forgalmunk biztonságban van. – 35 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 2. Tanszéki WLAN hálózat kiépítése Azt a feladatot kaptuk társaimmal, hogy a Híradástechnikai Tanszék területén a megismert technológiák alapján m köd
vezeték nélküli hálózatot alakítsunk ki. Az én feladatom els dlegesen a hálózat biztonsági rendszerének kialakítása volt. Röviden ismertetem a hálózat

kiépítését, majd b vebben kitérek a biztonsági kérdésekre. Els lépésként felmértük a lehetséges felhasználók számát, igényeit a leend vezeték nélküli hálózattal kapcsolatban. Feltérképeztük a tanszéket az access point-ok elhelyezésének szempontjából, illetve el zetes vizsgálatokat végeztünk az eszközök hatótávolságáról. A részletes kivitelezés ezután következett. 2.1 Fizikai kiépítés A vezeték nélküli aktív eszközök megismerése után nekiláttunk a tanszéki mintahálózat kiépítésének. Természetesen a fizikai kiépítés el tt tervet készítettünk a leend hálózatról Megegyeztünk abban, hogy a meglév vezetékes hálózat elemeit a lehet legminimálisabb módon használjuk csak fel, tehát az egyes access point-okhoz saját magunk vezetünk kábelt, illetve saját switch-et használunk ezek összekötésére. Biztosítani akartuk viszont a felhasználók számára, hogy a vezetékes hálózat által nyújtott

szolgáltatásokat (például az Internet és a tanszéki bels hálózat szervereinek elérését, stb.) a vezeték nélküli rendszerben is elérjék. A 802.11-es protokollcsalád biztonsági vizsgálatakor megállapítottuk, hogy védelmi szempontból érdemes a WLAN hálózatot úgy kezelni mintha az küls hálózat lenne. Ezért úgy döntöttünk, hogy üzembe helyezünk egy t zfal, illetve gateway funkciót ellátó
számítógépet, mely egyrészt a tanszéki vezetékes hálózathoz csatlakozik, másrészt ahhoz a switch-hez melyhez az access pointok is. Ez a gép különböz sz rési funkciói által biztosítja,
hogy a vezeték nélküli hálózatot elválasszuk a vezetékest l, és csak a szükséges információk kerüljenek át egyik rendszerr l a másikra. Így a két hálózatot külön kezelhetjük, és – 36 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv
mintahálózatunk forgalmáról pontos képet kapunk. A t zfal

számítógép emellett hálózat menedzsment szempontjából is fontos feladatokat lát el. DHCP szerver segítségével IP címet oszt a klienseknek, DNS szolgáltatást biztosít, illetve a kés bb bemutatásra kerül védelmi rendszer is ezen üzemel (10. ábra ) 10. ábra A mintahálózat topológiája Ezután eldöntöttük, hogy hova kerüljenek az access point-ok, figyelembe véve azt, hogy a kés bbiekben milyen forgalom várható az egyes eszközök környezetében, meghatároztuk a köztük lév távolságot. Az access point-okat megpróbáltuk minden esetben a folyosón elhelyezni, így egy karbantartás esetén könnyen elérhet k (11. ábra ) – 37 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 11. ábra Az AP-ok elhelyezkedése a tanszéken A rendszer kiépítése úgy zajlott, hogy a kihelyezend access point-okon el re beállítottuk a fontosabb paramétereket – IP cím, alhálózati maszk, név stb. – hogy telepítés

után, egyéb beállításokat, illetve a menedzselést távolról is el tudjuk végezni. Ezután a vezetékes hálózat rendez helyiségéb l UTP kábeleket vezettünk az álmennyezetben a megtervezett pontokig. Szerencsére az álmennyezetben már ki volt építve a kábeltartó rendszer, így a rögzítéssel nem sokat kellett bajlódnunk. Az access point-ok rögzítését is úgy oldottuk meg, hogy hozzáer sítettük azokat a kábeltartó profilokhoz. A folyosón lév

eszközök mind távtáplálású elven m ködnek, az egyszer kivitelezés érdekében. Ez azt jelenti
, hogy a m ködésükhöz szükséges áramot az Ethernet kábel kihasználatlan vezetékein keresztül kapnak, így nem szükséges az eszköz közelébe vezetni az elektromos hálózatot. Úgy becsültük, hogy az MC2L labor területén viszonylag nagy számú felhasználó fog csatlakozni a hálózathoz (például mérések alkalmával), ezért ide két access point telepítését terveztük viszonylag

közel egymáshoz. Sajnos a laboratórium helyiségében nem volt álmennyezet, viszont az infrastruktúra lehet vé tette hogy a távtáplálású adapterrel nem – 38 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv rendelkez eszközöket, pl. a Cisco 1100-ast elhelyezzük
A fizikai kiépítés után, leteszteltük hogy mindegyik elhelyezett eszköz m ködik-e, elérhet -e távolról. Majd kipróbáltuk hogy a lefedni kívánt helyiségekb l mindenhonnan hozzáférhet -e a vezeték nélküli hálózat.
Az ellen rzés után a rendszer tesztüzeme kezd dött el, mely id alatt a t zfal számítógép védelmi rendszerének finomhangolását is elvégeztük. 2.2 Biztonsági kérdések Az alábbiakban kifejezetten a tanszéki biztonsági rendszert írom le, hiszen a WLAN hálózat kiépítése kapcsán ennek elkészítése volt a f feladatom. 2.21 Gateway funkciók Mivel a hálózatunk nem rendelkezik dedikált IPv4 címtartománnyal, szükség

van egy gateway funkciókat ellátó eszközre. Ennek az eszköznek kell összekapcsolnia a helyi vezeték
nélküli hálózatunkat a külvilággal, az Internettel. Ezen kívül jó, ha t zfal funkciókkal is
rendelkezik az eszköz. Praktikusnak t nt, hogy a DHCP alapú címkiosztást is rábíztuk erre a szerverre. Többféle megoldás közül választhattunk. A kereskedelemben is kaphatóak ezen funkciókat ellátó eszközök, illetve egy számítógépet is bekonfigurálhatunk ilyen célokra. Mivel több állandó szolgáltatást is szerettünk volna megvalósítani, amihez egy szerver számítógép mindenképp szükséges, ezért úgy döntöttünk, hogy ez a szerver lássa el a gateway funkciót is. A szerver beüzemelése az én feladatom volt. Felmerült a kérdés, hogy erre a számítógépre milyen operációs rendszert telepítsek. A Debian GNU/Linux-ot választottam. A Windows alapú megoldásokat már az elején kizártam – ezen a számítógépen nem lesz

szükség grafikus környezetre, az utóbbi id ben pedig egyre több vírus/féreg jelenik meg, amelyek veszélyt jelentenének a rendszerünkre. Mivel Linux-ot már több éve használtam, és mert a Debian a Linux-ok között is híres a biztonságosságáról és a – 39 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv gyors hibajavításokról, így ezt választottam. A számítógép egy Intel Celeron 600 Mhz-es processzorral, 128 Mbyte RAM-mal, egy 20 Gbyte-os merevlemezzel és két DEC hálókártyával lett felszerelve. A számítógép
paraméterei sem tették volna lehet vé korszer Windows használatát, viszont Debian/GNU Linux-ot gond nélkül használhattunk rajta. Az egyik hálózati kártyával a tanszéki hálózathoz kapcsolódik és dedikált IP címmel rendelkezik, a másikra vannak kapcsolva egy switch segítségével az WLAN access point-ok. A gateway feladata, hogy a WLAN hálózatról érkez forgalmat továbbítsa az

Internet felé. Ezt a funkciót, a hálózati címfordítással együtt, a Linux kernelének beépített csomagsz r je, a netfilter valósítja meg.
2.22 Hálózati címfordítás A hálózati címfordítás a t zfal rendszer egyik alapvet els dleges funkciója. A t zfal hálózati

címfordítás funkciója állandóan aktív és két formában lehetséges: dinamikus és statikus címfordításként. Az alapértelmezett címfordítás a dinamikus több-egyre séma, ami azt jelenti, hogy a védett hálózat összes számítógépének IP címe egy IP címre kerül átfordításra. Ez az egy IP cím pedig a küls hálózati kártya els dleges IP címe. Másik címfordítási lehet ség a statikus címfordítási módszer, amit a t zfalban címleképzésnek (Mapping) nevezünk. A
címleképzési módszer lehet séget ad a t zfal rendszergazdájának arra, hogy egy hálózati
címet vagy tartományt statikus módon rendeljen hozzá a rendszer küls hálózati címéhez.

Hálózatunkban dinamikus címfordítást végez a gateway számítógép. Erre a címfordításra általában akkor van szükség, ha több számítógépet szeretnénk az Internetre csatlakoztatni, mint ahány dedikált IP címmel rendelkezünk. A bels hálózaton lév eszközöknek olyan címtartományból kell IP címet adnunk, amely címtartományt a közvetlenül az Internetre kapcsolt eszközök nem használják. Ezek a címtartományok az alábbiak: 10.000 / 255000 172.1600 / 25524000 192.16800 / 25525500 – 40 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Mi ez utóbbi tartomány legalsó 192.16800 / 2552552550 szegmensét használjuk, így most elvileg 255 darab hálózati eszköz csatlakozhat a hálózatunkhoz. (De ha igény van rá, a rendszer viszonylag gyorsan átkonfigurálható ennek többszörösére.) Mindamellett, hogy a NAT (Native Address Translation) segítségével nem pazaroljuk az amúgy is fogyó IPv4 címeket, az

Internet felé elrejti a hálózati struktúrát, ezzel is védve a bels hálózat felhasználóit az Internet fel l jöv támadásoktól. Minden csomagban, amit a bels gépek küldenek az Internet felé, a forrás IP címet a saját IP címére cseréli ki a gateway, így kívülr l nem lehet tudni, hogy melyik gép küldte. A gateway tárolja, hogy melyik gépt l érkezett csomagot melyik portján továbbította, hogy a válaszként érkez csomagok cél IP címét a megfelel IP címre tudja kicserélni ki. Sajnos így egyes alkalmazások, amelyeknél szükséges, hogy egy távoli számítógép kezdeményezzen kapcsolatot valamely portunkra (például sok peer-to-peer program, egyes hálózati játékok),
nem m ködnek, mivel az Internet fel l nem lehet kapcsolatot létesíteni a bels hálózaton lév gépekkel. Hálózatunkon a gatewayen Linux operációs rendszer fut, így a címfordítást is a Linux kernelének csomagsz r jével, a netfilterrel valósítottam meg, melynek ez

beépített funkciója.
A netfiltert az iptables nev programmal lehet elérni, illetve konfigurálni.
Mindenek el tt engedélyezni kell a két hálózati kártya közötti csomagtovábbítást. Ehhez a kernelt kell értesítenünk, amelyet az úgy nevezett sysctl interfészen keresztül érünk el: echo 1 > /proc/sys/net/ipv4/ip forward Így az egyes hálókártyákon beérkez csomagok megjelennek a másik hálózati kártya kimenetén. Ezután a címfordítást kell beállítanunk a bels hálóról az Internet felé továbbítandó csomagokra. Ezt a már említett iptables parancs segítségével tehetjük meg: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE A -t paraméter adja meg a táblát, amibe a szabályt be szeretnénk szúrni – ez itt most a nat tábla, azaz a címfordítás táblája. A -A paraméter jelzi, hogy új szabályt szeretnénk hozzáadni, mégpedig a POSTROUTING chain-be. Jelezzük, hogy a címfordítást azokon a csomagokon kell

végrehajtani, amelyek az Internet felé távoznak (azaz a kimen interfészük az eth0, az els dleges hálózati kártya). A csomagokon MASQUERADE-et, azaz dinamikus címfordítást kell végezni. – 41 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 2.23 Tűzfal beállítása A gateway számítógép t zfal szerepet is betölt. Ennek segítségével védjük a hálózatunkat az
Internet fel l induló támadásoktól, korlátozzuk a szolgáltatásokat, illetve azt, hogy mely kliens érheti el az Internetet. A t zfal funkciók védelmet biztosítanak a szerverünknek is,
mivel a hálózati címfordítás miatt a bels hálózaton található eszközök nem érhet ek el közvetlenül az Internet fel l, csak a gatewayen keresztül, így az Internet fel l érkez támadásoknak mindig maga az átjáró lesz a célpontja. A t zfalunk egy egyszer

csomagsz r , de az eddig felmerült igényeinket tökéletesen
kielégíti.

Megvalósításához, mint ahogy a címfordításnál, itt is a Linux kernelének a csomagsz r jét, a netfiltert használtuk fel. Mivel közvetlenül a kernel része, ezért gyorsan és
hatékonyan valósítja meg a csomagsz r funkciókat, a lehet legkisebb sebezhet ség mellett.
Linux operációs rendszerre többféle program is létezik, amelyekkel könnyen és gyorsan beállíthatjuk a t zfalunkat, illetve mi magunk is konfigurálhatjuk egyszer en az iptables

parancs segítségével. Mi ez utóbbi módot választottuk, mivel a legtöbb segédprogram olyan alapbeállításokat tartalmaz, amelyek nekünk nem minden szempontból tökéletesek. A t zfalunkban az alábbi portokat engedélyeztük, amiken keresztül a szerver elérhet :
53-as tcp és udp port Domain Name Service (dns) a hálózati címfeloldásért felel s protokoll 22-es tcp port Secure Shell (ssh) biztonságos távoli shell elérés 25-ös tcp port Simple Mail Transfer Protocol (smtp) elektronikus

levelezés 80-as tcp port HyperText Transfer Protocol (http) a weboldalak eléréséért felel s protokoll 443-as tcp port Secure HTTP (https) weboldalak biztonságos elérése – 42 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv icmp echo-request/reply Internet Control Message Protocol a ping hálózati segédprogram használja
A többi portra érkez csomagokat, amelyeknek a célja a szerverünk, a t zfal visszautasítja. A visszautasítás parancsa (1024 alatti tcp és udp portokra): iptables -A INPUT -p tcp -m tcp –dport 0:1023 -j REJECT iptables -A INPUT -p udp -m udp –dport 0:1023 -j REJECT Míg a címfordításnál a nat tábláját használtuk a netfilternek, a csomagsz r szabályokat a
filter táblába kell tenni – mivel ez az alapértelmezett tábla, ezért nem kell használni a -t paramétert. Az -A paraméterrel jelöljük meg, hogy a beérkez csomagokat kell majd sz rni
(INPUT lánc kiválasztása), -p paraméterrel

a protokolt, -m jelzi, hogy valami minta alapján szeretnénk sz rni, ez pedig a cél port (--dport). A -j paraméterrel adjuk meg, hogy mi
történjen a csomaggal – ez jelen esetben REJECT, azaz visszautasítás. Ezután lássunk egy példát az engedélyezésre. iptables -I INPUT -p tcp -m tcp --dport 22 -j ACCEPT Itt a f különbség, hogy a REJECT helyére ACCEPT kerül, azaz a csomagot nem elutasítjuk, hanem épp ellenkez leg – elfogadjuk. Fontos megjegyezni, hogy -A (add – a lánc végére f z) helyett -I (insert – a lánc elejére f z)

paramétert használtuk. Ugyanis a netfilter a láncon sorba végigmenve probálja illeszteni a csomagot, és azt a szabályt alkalmazza, amelyik a legel ször illik rá. Értelmetlen lenne az 1024 alatti portok tiltása mögé betenni egy engedélyezést egy ilyen portra, ezért a láncban felül lesznek az elfogadó (ACCEPT) sorok és alul az elutasítóak (REJECT). Beállítottuk, hogy a bels kliensek NAT segítségével

elérjék az Internetet, de nem szeretnénk, hogy illetéktelenek a mi hálózatunkat használják, esetleg innen indítson támadásokat más számítógépek ellen. Ezért alapesetben a gateway-ünk mégsem továbbítja a csomagokat, viszont – hogy utána minden egyes hálózati kártyára külön-külön engedélyezni tudjuk a továbbítást (a már említett ACL technika egy változatát alkalmazzuk) –, nem az ip forwardot állítjuk 0-ra, hanem a csomagsz r ben tiltjuk a továbbítást az alábbi módon:
iptables -A FORWARD -i eth1 -j DROP A FORWARD lánc tartalmazza azokat a szabályokat, amelyeket a továbbított csomagokra kell alkalmazni. Ezzel a paranccsal tehát a bels hálózatról érkez (ahol a bejöv interfész az – 43 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv eth1) továbbítandó csomagokat eldobjuk (DROP). Ezután ha egy eszköz számára elérhet vé szeretnénk tenni az Internetet, akkor annak az IP címére, vagy a

hálózati kártyájának a MAC címére engedélyezni kell a továbbítást. Mivel nálunk az IP címek dinamikusan DHCP-vel kerülnek kiosztásra, ezért inkább a második módot választottuk. Egy példa egy hálózati kártya engedélyezésére: iptables -I FORWARD -m mac –mac-source 00:60:1D:22:25:2F -j ACCEPT A -m mac, a MAC cím alapján való mintaillesztést jelenti, ahol a MAC, a –mac-source paraméterrel adható meg. [7] 2.24 Engedélyezés weben keresztül Mivel az Internet felé egy eszköz forgalmát sem engedjük ki, ha egy felhasználó mégis igénybe szeretné venni a küls hálózat szolgáltatásait, akkor az el bb bemutatott módon lehet engedélyezni ezt neki. Hogy ne kelljen minden alkalommal a rendszergazdát zaklatni, ezért készítettünk egy weboldalt, ahol a felhasználónévvel és jelszóval rendelkez felhasználók engedélyezni tudjak a hálózati kártyájuknak a kijárást az Internet felé (12. ábra) 12.ábra: Kártya engedélyezése a

honlapon – 44 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Ezt a weboldalt a https://zen.hitbmehu/login címen lehet elérni Mivel az oldal https protokollal érhet el, így a felhasználói név és a jelszó kódolva kerül továbbításra, azt a hálózati forgalom megfigyelésével nem lehet megszerezni. Itt bejelentkezés után kiválaszthatjuk, hogy melyik hálózati kártyát szeretnénk engedélyeztetni, és hogy mennyi id re. A felhasználóhoz az adminisztrációs felületen keresztül a rendszergazda hozzárendelheti az általa használható hálózati kártyák MAC címeit. Ezen kártyák közül lehet csak választani, ezzel is megnehezítve az illetékteleneknek a hozzáférést. Az id tartam minimuma 5 perc, maximuma pedig 4 óra Az engedélyezés technikailag úgy történik, hogy a php script mikor megkapja az engedélyezend kártya adatait, meghívja az allow.sh shell scriptet, ami elvégzi az engedélyezést az

alábbiak szerint: iptables -I FORWARD -m mac –mac-source $1 -j ACCEPT $FILE=`date +%j%H%M%S` echo “iptables -D FORWARD -m mac –mac-source $1 -j ACCEPT” > tmp/$FILE at now + $2 minutes -f tmp/$FILE A script paraméterként a hálókártya MAC címét ($1) és az engedélyezési id t kapja meg percben ($2). Az els a paranccsal kerül engedélyezésre a hálózati kártya Ezután történik az engedélyezés befejezésének id zítése. Létrehoz a script egy file-t, ami tartalmazza azt a parancsot, ami kitörli a netfilter láncszabályai közül az adott engedélyezést (-D, azaz delete). Ezután az at parancs segítségével beállítja, hogy ez a parancs mikor fusson le. A MAC cím szerinti sz rést azért egészítettem ki egy felhasználó/jelszó párossal illetve egy
id tartammal, mert már az ACL technika bemutatásakor említettem, hogy a hálózati kártyák MAC címe könnyen megváltoztatható. Például Linux alatt egyszer en az alábbi paranccsal:


ifconfig <interface> hw ether <új MAC cím> A mi módszerünkkel viszont, ha a támadó meg is szerez egy m köd MAC címet a hálózati
forgalom megfigyelésével, azt csak addig tudja használni, amíg lejár a beállított id korlát. 2.25 A WEP beállítása Általános tapasztalat, hogy a gyártók az access point-okat úgy szállítják, hogy azok
különösebb szakértelem nélkül is használhatóak legyenek – egyszer en rácsatlakoztatva ket – 45 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv a hálózatunkra, DHCP-vel IP címet kérnek, esetleg ha ez nem sikerül, megpróbálnak
meghatározni egyet maguknak, és megkezdik a m ködést. A WEP-et 3Com és Cisco AP-ken próbáltam meg beállítani. A kártyák az ugyanazon

gyártótól származó access point-okkal m ködtek is, de (valószín leg a különböz kulcs megadási módoknak köszönhet en) a másik gyártó termékével már nem. Mivel a WEP

titkosítás amúgy sem igazán hatékony módszer a védekezésre (a korábban ismertetett hibái miatt), ezért már a kezdetekkor valamilyen alternatív megoldást próbáltam keresni. 2.26 IPSec alkalmazása Egy ilyen alternatív megoldás lehet az IPSec. Én az IPSec-et Linux alatt a FreeS/WAN implementációval valósítottam meg. Ennek el nye, hogy ha egy kliensen FreeS/WAN IPSec található, akkor az automatikusan együtt tud m ködni a szerverrel (un. OE módban), illetve a
Linux kernel 2.4-es verziójú változatához ez a legelterjedtebb IPSec implementáció Nem minden kliens rendelkezik IPSec támogatással (például egyes PDA-kra elég nehezen, vagy talán sehogy sem elérhet ), ezért használatát nem tudjuk kötelez vé tenni, de ahol csak lehet ség van rá, ott nagyon ajánlott, ha fontos adatokkal dolgozunk. 2.261 FreeSWAN telepítése Linuxra A FreeSWAN IPSec implementáció két f részb l áll: egy kernel szinten futó részb l (modulként fordítva

ipsec.o), melynek neve KLIPS (Kernel IPsec Support) egy a felhasználói szinten futó pluto nev démonból, ami az IKE kulcsmenedzsmentjét
végzi el Az ipsec paranccsal tudjuk elvégezni a különféle m veleteket.
Debian GNU/Linuxhoz nem érhet el olyan el re fordított kernel, amely támogatná a IPSec használatát, ezért nekem kellett kernelt fordítani. El ször a kernel forrását kell letölteni [8] és kicsomagolni a /usr/src könyvtárba. Majd ugyanúgy le kell tölteni a FreeSWAN forrását [9] – 46 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv (mégpedig azt a verziót, amelyik rendelkezik X.509-es tanúsítványok támogatásával – erre a Windowsos kliensek miatt van szükségünk) és ugyanoda ki kell csomagolni. A FreeSWAN könyvtárában kiadva a make menugo parancsot, a kernel forráskódja automatikusan frissül, majd megkezd dik a kernel konfigurációja. Itt arra figyeljünk, hogy a “Networking Options” menüben

válasszuk ki az IPSec támogatást. Miután a konfigurációval végeztünk, a rendszer lefordítja és telepíti az új kernelt, illetve a FreeSWAN segédprogramjait is. Az operációs rendszerünk újraindítás után készen is áll IPSec kapcsolatok létesítésére. 2.262 FreeSWAN beállítások A FreeSWAN csomaggal rengeteg konfigurációs példa érkezik, amelyek különféle helyzetekre kínálnak megoldást. Én most két esetet fogok bemutatni, ami egy WLAN hálózatnál hasznos lehet. Mindkét esetben a mobil egység és a t zfal között épül fel egy IPSec
tunnel, amelyen keresztül bonyolódik majd a vezeték nélküli hálózatot használó számítógép teljes ki és bemen forgalma – így védve lesz mindennem támadástól. (13 ábra)
13. ábra A WLAN hálózat biztonságossá tétele IPSec használatával – 47 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Els példánkban egy Linuxot használó kliens kapcsolódik

majd a hálózatra – ekkor
használhatjuk az egyszer bb PSK (Pre-Shared Key – el re kiosztott kulcs) alapú azonosítást. A FreeSWAN f konfigurációs állománya a /etc/ipsec.conf, ha nincs külön megemlítve, akkor a módosításokat ezen a file-on kell végrehajtani. Egy IPSec kapcsolatnak két egyenrangú oldala van. Definíciójakor a kapcsolat neve mellett meg kell adni az egyes oldalak paramétereit is. A FreeSWAN a “left” és “right” kulcsszóval különbözteti meg az egyes oldalakat. Legjobb úgy elnevezni az oldalakat, hogy könnyen eszünkbe juthasson melyik oldal melyik számítógép. A dokumentációban azt ajánlják, hogy legyen a “left” a helyi számítógép ( left-local ), a “right” pedig a távoli ( right-remote ). Ez persze nem kötelez , de én ehhez tartottam magam. Egy kapcsolat definíciója a következ képpen néz ki a mobil számítógép oldalán: conn linuxlap left=192.1680112 #mobil IP címe lefttsubnet=192.1680112/32

leftid=@linuxlap.mclinfo leftrsasigkey=0sAQPIPN9uI. right=192.1680254 #a tűzfal IP címe rightsubnet=0.000/0 rightid=@zen rightrsasigkey=0sAQOFMsmS. auto=start Ez a bejegyzés definiál egy “linuxlap” nev kapcsolatot (conn linuxlap). A laptop IP címe
192.1680112 (left=1921680112), subnetje saját maga (leftsubnet=1921680112/32, a tunnel módot eredetileg subnetek összekötésére találták ki). A publikus RSA kulcsokat az alábbi parancsokkal kaphatjuk meg: ipsec showhostkey –left illetve: ipsec showhostkey –right
A megkapott kulcsokat kell ezután a megfelel helyre bemásolni. Lássuk a t zfal oldai konfigurációt: conn linuxlap right=192.1680112 #mobil IP címe rightsubnet=192.1680112/32 rightid=@linuxlap.mclinfo – 48 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv rightrsasigkey=0sAQNu9+h. left=192.1680254 #a tűzfal IP címe leftsubnet=0.000/0 leftid=@zen leftrsasigkey=0sAQP5gkS. auto=add Mint láthatjuk a két

bejegyzés szinte teljesen megegyezik, csak a két oldal van megcserélve. Vigyázzunk, mert a kulcsok értékei ez esetben mások lesznek, mint az el bb, mind az oldalak, mind a kulcsok szerepei megcserél dtek. A másik különbség, hogy a laptop oldali auto=start helyett most auto=add szerepel. Az auto paraméter start értékénél az IPSec rendszer egyb l elindulása után megkísérli kiépíteni a kapcsolatot az IKE protokoll segítségével, míg add esetén vár a másik félre, hogy az kezdeményezze a kapcsolatkiépítést. A másik példa azt az esetet mutatja be, amikor Windowst használó kliens szeretne IPSec kapcsolatot létesíteni. A Windowsos IPSec implementáció nem támogatja a PSK alapú azonosítást, ezért más megoldást kellett keresnünk. Egy ilyen megoldás az X509-es tanúsítványok használata, amit mindkét oldal támogat. A konkrét IPSec beállítások el tt készítenünk kell tehát ilyen tanúsítványokat a kliensek és a szerver részére.

Ehhez Linux alatt az openssl csomagra van szükségünk, ami valószín leg
minden disztribúcióhoz elérhet . El ször egy úgy nevezett Root CA-t (Certification Authority) kell létrehoznunk, ami a PKI infrastruktúránk alapját képezi majd, ezzel írjuk majd alá az általunk kibocsátott kulcsokat. A CA az alábbi paranccsal hozható létre: /usr/lib/ssl/misc/CA.sh -newca A parancs kiadása után meg kell adnunk egy jelszót – a CA csak ennek a jelszónak az ismeretével használható -, illetve a kulcs Distinguished Name (DN, megkülönböztet név) paramétereit. Ezekkel a paraméterekkel lehet a kulcshoz némi információt rendelni Nem kell a DN minden paraméterét megadni, ugyanakkor célszer
olyan értékeket adni, melyek beszédesek, ha mondjuk hosszabb id után kell használni a kulcsot valamiért, akkor tudjuk mir l van szó. Nézzük röviden ezeket a paramétereket: Country Name (2 letter code): az ország nevének kétbet s kódja
State or Province Name

(full name): az állam neve, nálunk nem használatos Locality Name (eg, city): helységnév – 49 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Organization Name (eg, company): a vállalat neve Organizational Unit Name (eg, section): a vállalaton belül a részleg neve Common Name (eg, YOUR name): a kulcs neve Email Address: a tulajdonos e-mail címe Ha minden paramétert megadtunk, és a parancs lefutott, akkor az aktuális könyvtárban találunk egy demoCA nev
file-t – ez maga a CA. A következ lépés a szerver tanúsítványának létrehozása: /usr/lib/ssl/misc/CA.sh -newreq Egy jelszó, illetve a DN paraméterek megadása után el álló file még nem a kész tanusítvány, azt még alá kell írnunk az alábbi módon: /usr/lib/ssl/misc/CA.sh -sign Ezután elkészíthetjük az X.509-es formátumú kulcsot: openssl x509 -in newcert.pem -outform der -out /etc/x509certder A két keletkezett file-t bemozgatjuk a helyére: mv

newcert.pem /etc/ipsecd/certs/zen-certpem mv newreq.pem /etc/ipsecd/private/zen-privpem Ezzel el is készült a szerver tanúsítványa. A klienseknek ugyanígy készíthetünk tanúsítványokat, amiket a megfelel néven másoljuk be a file-okat a /etc/ipsec.d könyvtár alá A Windows számára X.509-es formátumról konvertáljuk a certificate-eket P12-es formátumra, hogy azokat be tudjuk vele tölteni: openssl pkcs12 -export -in newcert.pem -inkey newreqpem -certfile demoCA/cacert.pem -out w-certp12 Ily módon tetsz leges számú kliensnek generálhatunk kulcsot, arra kell csak ügyelnünk, hogy
ne legyen két egyforma DN- kulcs, mert aláíráskor az openssl hibát jelez, ha ugyanolyan
DN- kulcsot akarunk aláírni. Kliensként Windows XP-vel próbáltuk ki az IPSec kapcsolatot. Mindenek el tt fel kell telepíteni a Windows XP Support Tools – ez megtalálható a Windows XP telepít CD-jén, illetve hasznos lehet még a kulcs importálására a Marcus Müller féle

Windows 2000 VPN
Tool [10]. Ezzel a segédprogrammal viszonylag egyszer en importálhatjuk a fentebb el állított P12-es formátumú tanúsítványunkat. Az importálás e program segítsége nélkül is – 50 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv
megoldható, de sokkal hosszadalmasabb, az interneten található err l angol nyelv leírás [11], erre most nem térnék ki b vebben. A kulcs importálása után jöhet az IPSec konfigurációja. El ször lássuk a kliens (Windows) oldalt: conn winlap left=192.1680123 right=192.1680254 rightsubnet=0.000/0 rightca="C=HU,S=NA,L=Budapest,O=BME,OU=MCL,CN=MCL CA,E=dyuri@mindit.hu" network=auto auto=start pfs=no Lássuk a szerver oldali konfigurációt: conn winlap left=192.1680254 leftrsasigkey=%cert leftcert=zen-cert.pem leftid="C=HU,S=NA,L=Budapest,O=BME,OU=MCL,CN=MCL CA,E=dyuri@mindit.hu" right=192.1680123 rightrsasigkey=%cert rightcert=/etc/ipsec.d/certs/winlap-certpem

rightid="C=HU,S=NA,L=Budapest,O=BME,OU=MCL,CN=MCL CA,E=dyuri@mindit.hu" auto=add pfs=no A /etc/ipsec.secrets file-t is módosítani kell még az alábbi módon: : RSA zen-priv.pem "ide jön a jelszó" Ha mindezzel kész vagyunk, akkor már csak a szerencsén múlik, hogy összejön-e az IPSec kapcsolat a kliens és a szerver között. (Sajnos a Windowsos kliens néha produkál váratlan dolgokat, nem mindig épül ki a kapcsolat, ha valami félresikerül, akkor az csak a számítógép újraindításával javul meg. Várhatóan ezek a problémák a rendszer fejl désével szépen lassan
elt nnek.)
Ahhoz, hogy az IPSec megfelel en m ködjön, néhány beállítás még hátra van a
szerverünkön. El ször is a t zfalunknak el kell fogadnia az ISAKMP csomagjait, amelyek az – 51 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 500-as UDP portot használják, illetve nem szabad eldobnia az ESP csomagokat sem. Az
alábbi

módosításokat kell tehát a t zfal szabályokon eszközölni: iptables -I INPUT -p udp -m udp –dport 500 -j ACCEPT iptables -I INPUT -p esp -j ACCEPT Létezik egy olyan szabvány [12], amely arra hivatott, hogy megvédjen minket számos olyan támadástól, ami hamisított forrás IP címek felhasználásával m ködik. Azt mondja ki röviden,
hogy ne vegyünk át olyan csomagot egy adott interfészen, aminek a forrás- és célcímét felcserélve, az így kapott csomagot egy másik interfészen keresztül továbbítanánk. Mivel az IPSec rendszerünkben ez a helyes m ködés, mivel minden csomagot az IPSec interfészen
keresztül route-olunk, de a bejöv titkosított csomagok az eth1-es (a WLAN hálózatunk felé néz ) interfészen érkeznek. Ezt az úgy nevezett RP-filtert az alábbi módon kapcsolhatjuk ki: echo 0 > /proc/sys/net/ipv4/conf/eth1/rp filter Ezek után máris élvezhetjük az IPSec által nyújtott biztonságot WLAN hálózatunkban. [13] – 52 –

http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 3. Egy segédprogram elkészítése A munkám során egy segédprogramot is készítettem, mellyel a hálózat biztonsági beállításai is tesztelhet ek. A cél egy olyan program megalkotása volt, mellyel könnyen és gyorsan megtudhatunk hasznos információkat a hálózatunkról. Mivel a programot speciálisan WLAN hálózathoz szerettük volna használni, felmerült az igény, hogy a program PDA-a, azaz kéziszámítógépen (is) fusson – így könnyedebben mozoghatunk a hálózatunk területén, mint egy viszonylag nehéz notebookkal. Notebookra illetve PC-re több hasonló program is készült már, de ezek vagy nem használhatóak PDA-n, vagy drága kereskedelmi termékek. Ha viszont PDA-n kell majd használni a programot, el ny ha minél kevesebbszer kell használni a program futtatása során billenty zetet. Jó, ha a program egyszer

grafikus felülettel rendelkezik, ahol pár kattintással

elérhet ek a fontosabb funkciók. A labor biztosított számomra egy Compaq iPAQ 3950-es kéziszámítógépet, hogy ennek segítségével végezzem el a fejlesztést. A PDA Microsoft Windows PocketPC 2003 operációs rendszerrel érkezett, de mivel ilyen alkalmazások esetében a Linuxot el nyben részesítem a Microsoft rendszereivel szemben, illetve mivel Windows alatt a keresztplatformos fordításhoz nem használhatóak az általam a Campus program [13] kereteiben elérhet fejleszt eszközök, ezért úgy döntöttem, hogy a programot Linux alatt fejlesztem, és a PDA-ra is azt telepítek. 1 3.1 Familiar Linux Az iPAQ típusú PDA-kra elérhet több Linux disztribúció is, én ezek közül a Familiar Linuxot választottam GPE grafikus környezettel. A rendszer legújabb változata elérhet az interneten [15][16]. A GPE környezet a Gnome kéziszámítógépekre szánt változata, ugyanúgy a gtk widget könyvtárra épül, amire szükségem is lesz. A telepítés viszonylag

egyszer en végezhet el [17]:
Legel ször a Linuxot is támogató boot loadert kell installálnunk. ActiveSync segítségével 1 Jelenleg már Microsoft fejleszt eszköz is elérhet egyetemisták számára. [14] – 53 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv
fel kell töltenünk a BootBlaster nev segédprogramot, mellyel a boot loader telepíthet , illetve magát a boot loadert. Ezután a BootBlastert elindítva és a bootldrbin image file-t kiválasztva fel is települ az új boot loader. A kéziszámítógépet reszetelve a frissen telepített boot loader fogad minket. Ezután a soros porton keresztül egy terminál emulátorral csatlakozhatunk a PDA-hoz. A kapcsolódás után a load root parancsot kiadva a rendszer várni fogja a telepítend operációs rendszert. Az image file-t YMODEM file-átvitel segítségével küldhetjük a PDAnak A file-átvitel befejezése után a boot parancsot kiadva máris az új rendszer, azaz a Familiar

Linux indul el. A Linux feltelepítése után megkezdhettem a program fejlesztését. 3.2 Program fordítása PDA-ra Mivel az iPAQ-ban ARM processzor található, nem fut rajta az x86-os processzorhoz fordított programkód. Speciálisan ARM processzoron futó kód el állítására több módszer is adódik: 1. Keresztplatformos fordítás (Cross-compile): Ezzel a módszerrel egy hagyományos (x86) számítógépen tudjuk úgy lefordítani a programunkat, hogy az el állított programkód ARM processzoron fusson. Sajnos a módszer meglehet sen körülményes, és viszonylag
bonyolult el készületeket igényel. Aki viszont nagy mennyiség program lefordítását tervezi más platformra, annak mindenképpen ez a módszer ajánlott, mivel általában gyorsabb, mint a többi eljárás. 2. Program fordítása a kéziszámítógépen: Ugyanúgy, mint a hagyományos számítógépeken, a PDA-n is tudunk programot fordítani, a megfelel compiler és fejleszt i csomagok


feltelepítése után. Ez nagyon egyszer is lenne, csakhogy általában a kéziszámítógépekben nincs túl nagy háttértár, így a fejleszt i csomagok feltelepítése akadályba ütközhet. 3. Program fordítása a handheldsorg iPAQ cluster-én: A handheldsorg csapata a Compaq segítségével összeállított egy cluster-t, hogy az iPAQ-re Linuxos programokat fordítani kívánóknak megkönnyítsék a dolgukat. A cluster hét iPAQ kéziszámítógépb l áll, – 54 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv
melyeket egyszer en telnet kapcsolattal érhetünk el. A használata teljesen ingyenes, guest névvel, jelszó nélkül lehet belépni az ipaq{1-7}.handheldsorg címeken Belépés után nagy
mennyiség fejleszt i könyvtár áll a rendelkezésünkre. 3.3 A program elkészítése A programot C nyelven írtam, Linux operációs rendszer alatt sok függvénykönyvtár áll hozzá rendelkezésre, amelyek közül kett nek nagy

hasznát vettem. A grafikus felület kialakításához
a GTK+ függvény könyvtárat használtam, a csomagok hálózatról való begy jtéséhez pedig a pcap csomagot hívtam segítségül. 3.31 A pcap használata A pcap képes arra, hogy a hálózati kártyára érkez csomagokat elfogja, hogy azokat mi fel tudjuk dolgozni. Röviden bemutatom a fontosabb függvényeket, amelyeket a programom elkészítése során használtam [18]: dev = pcap lookupdev(errbuf); Kiválasztja az els használható hálózati interface-t, és visszatér a nevével (pl. Eth0) pcap lookupnet(dev,&netp,&maskp,errbuf); Az interface-hez tartozó hálózati paramétereket állapítja meg. (netp – alhálózat címe, maskp – alhálózati maszk) descr = pcap open live(dev,BUFSIZ,promisc,to ms,errbuf); Megnyitja az eszközt a használatra, és az kapcsolathoz rendelt leíróval tér vissza. Ha a promisc értéke 1, akkor a hálókártya promiscuous módba kerül, azaz a nem neki szóló

ethernet csomagokat sem dobja el. A to ms az id limitet állítja be nem blokkoló mód esetére pcap setnonblock(descr, 1, errbuf); Nem blokkoló módba állítja a pcap rendszert, azaz ha nem érkezik csomag a pcap open live-ban beállított to ms id alatt, akkor nem vár tovább. pcap compile(descr,&fp,PCAP FILTER,0,netp); A pcap nyelvére fordítja a szövegesen megadott filtert (a tcpdump programnál már megismert filterek használhatóak). – 55 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv pcap setfilter(descr,&fp); Beállítja a már lefordított filltert. pcap dispatch(descr,1,handle all, (u char *) buffer); Egy darab csomagot vár, és ha az megjött, akkor átadja azt a handle all függvénynek. Ha nem blokkoló módban van, és nem
jön csomag a megadott id korláton belül, akkor egyszer en kilép. 3.32 A GTK+ A GTK (GIMP Toolkit) grafikus felhasználói felületek készítésére használható

függvénykönyvtár. Eredetileg a GIMP (GNU Image Manipulation Program) nev
rajzolóprogramhoz fejlesztették ki, de azóta nagyon sok más szoftver elkészítéséhez használták. A pcaphoz hasonlóan itt is bemutatom az általam használt fontosabb függvényeket [19]: gtk init (&argc, &argv); Inicializálja a GTK rendszert. window = gtk window new (GTK WINDOW TOPLEVEL); Új ablakot hoz létre, és az ablak leírójára mutató pointerrel tér vissza. g signal connect (G OBJECT (window), "delete event", G CALLBACK (delete event), NULL); Egy megadott objektumhoz hozzárendel egy callback függvényt arra az esetre, ha egy bizonyos jelzés (signal) érkezik az objektumhoz. Jelen esetben ez a window nev
objektum, a signal a delete event és a függvénynek is ugyanezt a nevet adtam. view = gtk text view new (); Egy szövegmez t hoz létre. buffer = gtk text view get buffer (GTK TEXT VIEW (view)); Lekéri a szövegmez pufferének a címét, amelyen keresztül

írhatunk bele. gtk text buffer insert ((GtkTextBuffer *)buffer, &iter,”szöveg”, -1); A szöveget beleírja a pufferbe, így az megjelenik a szövegmezöben. gtk text buffer set text ((GtkTextBuffer *)buffer, ”szöveg”, -1); A puffer szövgét ”szöveg”-re állítja. menu bar = gtk menu bar new (); Menüsor létrehozása. menu = gtk menu new (); Új menü. – 56 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv menu item = gtk menu item new with label ("Start"); Létrehozza a ”Start” nev
menüelemet. gtk menu shell append (GTK MENU SHELL (menu), menu item); A menu item menüelemet hozzárendeli a menu nev menühöz.
gtk widget show (widget); Megjeleníti az adott elemet. gtk main iteration do (blocking); A gtk programoknál alapesetben egy úgy nevezett main loop (azaz f húrok) dolgozza fel a felhasználó által generált eseményeket. Ez a függvény egyetlen ilyen eseményt dolgoz fel. Ha nincs feldolgozásra

váró esemény, és a blocking változó értéke 0, akkor nem egyb l kilép, ellenkez esetben feldolgozza az eseményt a kívánt callback függvények meghívásával. gtk events pending(); Visszatérési értéke igaz, ha van lekezelésre váró gtk esemény. 3.33 A program működése Els lépésben a felhasználói felület épül fel, majd beindul f ciklus. Mivel mind a pcap, mind a gtk valami eseményre vár (a gtk felhasználói beavatkozásra, a pcap pedig csomag érkezésére a hálózaton), el kellett érni, hogy ne blokkolják egymást. A f ciklus az alábbi módon m ködik:
Ha folyamatban van a hálózat figyelése (azaz a CAPTURE változó értéke 1), akkor legel ször a pcap dispatch megpróbálja lekezelni a hálózaton érkez els csomagot. Ha ezzel végzett (illetve, ha az id korláton belül nem érkezik csomag), akkor le kell kezelni a csomag kezelése közben érkezett gtk eseményeket. Mindaddig hívódik meg a gtk main iteration do, amíg van ilyen

esemény (azaz amíg a gtk events pending() igazzal tér vissza). Ha viszont a CAPTURE értéke 0, akkor csak a gtk main iteration do hívódik meg blokkoló módon, hogy várja hogy gtk esemény keletkezzen. Ugyanitt a f ciklusban történik az új filter beállítása, amit a felhasználó a menün keresztül tud megváltoztatni. A csomagok vizsgálatát a handle all függvény végzi. Miután megkapta a pcap-tól a csomagot, azt további függvényeknek adja át annak függvényében, hogy milyen típusú – 57 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv csomagról van szó. Nézzük meg példaképp a TCP fejléceket vizsgáló függvényt: u int16 t handle TCP (const struct pcap pkthdr* pkthdr,const u char packet, gpointer buffer) { struct tcphdr* tcp;int size ip = sizeof(struct ip); int size eth = sizeof(struct ether header); int size tcp = sizeof(struct tcphdr); u int16 t sport, dport, window, urgp; u int32 t seq, ack; char buff[255]; tcp =

(struct tcphdr*)(packet + size ip + size eth); sport = ntohs(tcp->source); dport = ntohs(tcp->dest); seq = ntohl(tcp->seq); ack = ntohl(tcp->ack seq); window = ntohs(tcp->window); urgp = tcp->urg ptr; if ( SH TCP ) { sprintf(buff," TCP: forras: %u cel: %u seq: %u ack seq: %u win: %u urg p: %u flags(uaprsf): %d%d%d%d%d%d ", sport, dport, seq, ack, window, urgp, tcp->urg, tcp->ack, tcp->psh, tcp->rst, tcp->syn, tcp->fin); gtk text buffer insert at cursor((GtkTextBuffer *)buffer, buff, -1); } return 0; } A függvény paraméterként megkapja magát a csomagot is (packet) és a puffer címét, ahova az információkat ki kell majd írnia. A függvény legel ször a TCP csomag fejlécét keresi meg a csomagban, ami az Ethernet és az IP fejlécek után következik. A program a Linux által szállított fejléc struktúrákat használja. Néhány érték byte sorrendje a hálózaton más, mint ahogy a processzor kezeli segítségével át kell

ket, ezért ezeket az ntoh (network to host) függvények ket alakítanunk. A fejlécb l kinyert információkat ezután beírja a pufferbe, ha a TCP információk kiírását nem tiltottuk le (azaz az SH TCP értéke 1). A többi függvény ehhez nagyon hasonlóan m ködik.
A WLAN hálózati információkat a program a Linux proc interface-én keresztül éri el, – 58 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv mégpedig a /proc/driver/aironet/eth0 könyvtárban található file-okból olvasva ki az adatokat.
Így sajnos a program csak olyan hálózati kártyákkal tud tökéletesen együttm ködni, amelyek az aironet meghajtóval m ködnek. Ez nem baj, hiszen a célom nem egy általánosan
használható szoftver létrehozása, hanem egy speciális biztonsági ellen rz rendszer elkészítése, melyet a PDA és a program párosa tesz ki. A PDA-ban Cisco hálózati kártya van, és ez megfelel ennek a kritériumnak. 3.34 A program

használata A program elindítása után a Capture menüben indíthatjuk el a csomagok figyelését, illetve ugyanitt állíthatjuk azt le. Az Options menüben a Wlan Stats almenü alól érhetjük el a WLAN kártyától lekérhet információkat (14.ábra – konfiguráció, státusz, engedélyezett AP-k listája, statisztika, azon AP-k, melyeket a kártya érzékel, a beállított WEP kulcs, illetve a beállított hálózati azonosítót), Wlan Mode menü alatt pedig beállíthatjuk a kártya m ködési módját
(15.ábra) A m ködési módok az alábbiak:
infrastruktúra mód: Az els fejezetben leírt infrastruktúra módnak felel meg, a kártya access point-tal kapcsolódik a hálózathoz. adhoc mód: Az els fejezetben leírt adhoc módnak felel meg, t bb vezeték nélküli hálózati eszköz spontán összekapcsolását teszi lehet vé. rfmon mód: A kártya nem csak a saját, hanem az összes rádiós csatornát figyeli, és minden lehetséges keretet elkap, még az

access point-ok által küldött beacon kereteket is eljuttatja az operációs rendszerhez. Adásra ilyenkor nem képes y-mode: A WLAN kártya bázisállomásként kezd el üzemelni, hirdeti magát, és infrastruktúra módban lév kártyák csatlakozhatnak hozzá. – 59 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 14. és 15ábra Options menü és almenüi A felhasználó az Options menü PCAP filter menüpontjával tudja beállítani a pcap sz r jét
(16. ábra), a View menüpontban pedig azt lehet beállítani, hogy az elfogott csomag milyen paramétereit írja ki a program (17. ábra) 16. és 17ábra PCAP filter illetve View menük A pcap a tcpdump program által is használat filter szintaktikát ismeri [20]. Miután a filtert beírtuk a beviteli mez be, enter-t nyomva az azonnal érvénybe is lép, és ezután csak olyan csomagok jellenek meg, amelyek megfelelnek a szür nek. A View menüpontban rádiógombok segítségével

állíthatjuk be, hogy a csomagok mely paramétereit jelenítse meg a program. Ez azért hasznos, mert ha minden paramétert megjelenítünk, akkor a PDA kicsi képerny je miatt sokat kell jobbra-balra görgetni. – 60 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 4. A tanszéki WLAN hálózat vizsgálata Ebben a fejezetben röviden be szeretném mutatni, hogyan használható az általam elkészített program egy tipikus WLAN hálózat vizsgálatára. A vizsgálatot tanszéki WLAN hálózaton kezdtem, majd a Távközlési és Médiainformatikai Tanszék hálózatára is felcsatlakoztam. 4.1 A mérés megtervezése Legel ször azt határoztam meg, hogy hol vizsgálom meg a hálózatot. A tanszéken két különböz helyet jelöltem ki, amelyek a közöttük lév falak árnyékolása miatt elkülönülnek. Az els helyszínnek a labor el tti területet választottam. Itt akkor éppen nem folyt mérés, reméltem, hogy nem lesz forgalom a

hálózaton, és meg tudok figyelni a WLAN hálózatra jellemz beacon kereteket is. (18 ábra, 1 pont) Második helyszín a tanszék északi oldalán lév elárnyékolnak az el z folyosó, melyet a falak és a liftek területt l. Itt viszont szerettem volna, ha sikerül elfognom egy felhasználónk forgalmát. (18 ábra, 2 pont) 18. ábra A mérések helye a Híradástechnikai Tanszéken – 61 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv A harmadik mérést a Távközlési és Médiainformatikai Tanszék irodái el tt szerettem volna elvégezni, tisztán érdekl d és nem támadó jelleggel. 4.2 Első helyszín: MCL labor előtti terület A labor környezetében valóban nem használták rajtam kívül a hálózatot, így a WLAN kártyát rfmon módba téve sikerült megfigyelnem az access point-ok által küldött speciális kereteket. Ezekr l a keretekr l a program sok plusz információval nem szolgál, mert az interneten nem találtam

megfelel leírást róluk. (19 ábra) 19. ábra Speciális keretek Igaz, hogy a beacon kereteket nem tudta értelmezni a program, de bebizonyosodott, hogy a kártya képes az rfmon módú m ködésre.
A forgalom megfigyelése mellett más információkat is megtudhattam a programból az adott hálózati részr l. Az Options menü Wlan Stats almenüjében találhatjuk ezeket Számomra a Status és a BSSList menüpont volt az érdekes. Az el bbi általános információkat mutat meg a káryáról, míg a másodikból az elérhet access point-ok ethernet címe tudható meg. Status: Status: CFG ACT SYN LNK Mode: rfmon Signal Strength: 56 Signal Quality: 17 SSID: mcl AP: cisco6 Freq: 0 – 62 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv BitRate: 11mbs Driver Version: airo.c 06 (Ben Reed & Javier Achirica) Device: 350 Series Manufacturer: Cisco Systems Firmware Version: 4.2530 Radio type: 2 Country: 1 Hardware Version: 30 Software Version: 425

Software Subversion: 1e Boot block version: 150 Látható, hogy a hálózat azonosítója mcl (ez nem is meglep , hiszen a tanszékünk hálózatán vagyunk), kiolvasható a jel er ssége, min sége, illetve hogy a cisco6 nev bázisállomáshoz
kapcsolódik a kártya. Ezután nézzük a BSSList tartalmát: 00:40:96:58:c5:73 mcl rssi = 66 channel = 0 ESS shorthdr 00:02:8a:21:13:fd mcl rssi = 64 channel = 0 ESS shorthdr 00:40:96:58:6d:46 mcl rssi = 43 channel = 0 ESS shorthdr 00:02:8a:21:13:6e mcl rssi = 64 channel = 0 ESS shorthdr Megkaptuk négy access point ethernet címét, amely címekhez IP címet is tudunk rendelni az arp -na parancs segítségével: ~ # arp -na ? (192.1680250) at 00:40:96:58:C5:73 [ether] on eth0 ? (192.1680249) at 00:40:96:58:6D:46 [ether] on eth0 ? (192.1680245) at 00:02:8a:21:13:fd [ether] on eth0 ? (192.1680246) at 00:02:8a:21:13:6e [ether] on eth0 A kártyák képesek arra, hogy csak azokhoz a bázisállomásokhoz kapcsolódjanak, amelyeket el

zetesen beállítottunk nekik, ezzel is védekezve az ellen, hogy egy támadó magát bázisállomásnak kiadva lehallgathassa a forgalom egy részét. Mint láthatjuk ez a módszer elég egyszer en kijátszható, a támadó az el bb ismertetett módszerrel megszerezheti a
bázisállomás adatait, azt kiiktatva (DoS támadással, fizikailag lehúzva a hálózatról) már könnyedén meg tud személyesíteni egy megbízhatónak vélt access point-ot. – 63 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 4.3 Második helyszín: A tanszék északi folyosója A labor el tti vizsgálatot követ en a tanszék északi folyosóján próbáltam biztonsági hiányosságok után kutatni. A BSSList itt az alábbi bázisállomásokat mutatta: 00:04:76:a5:bb:72 mcl rssi = 84 channel = 0 ESS 00:04:76:a1:56:cd mcl rssi = 69 channel = 0 ESS 00:04:76:a1:56:22 mcl rssi = 76 channel = 0 ESS Látható, hogy itt valóban más access point-okat érzékel a kártya,

mint az el z helyen, azaz valóban el van árnyékolva egymástól a két terület. 20. ábra TCP forgalom a hálózaton A PCAP sz r jét “proto TCP”-re állítottam, hogy ne zavarjanak a számomra lényegtelen
csomagok (Beacon keretek, ARP csomagok, UDP broadcast üzenetek). Az alábbi két különböz kapcsolatot figyeltem meg (20. ábra): Az egyik egy HTTP kapcsolat volt a www.indexhu oldalra A másik egy SSH kapcsolat az mlabdial.hitbmehu számítógépre Léteznek programok amelyeket arra a célra készítettek, hogy a forgalomból kiszedje azokat a jelszavakat, amelyek FTP, IMAP, POP3 és más titkosítatlan átvitel során a hálózatba kerülnek. Jelen esetben a wwwindexhu valószín leg nem tartalmaz bizalmas adatokat, az
SSH protokoll pedig megfelel védelmet nyújt, így különösebb biztonsági hiányosságot nem fedeztem fel. – 64 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv 4.4 Mérés a Távközlési és

Médiainformatikai Tanszék hálózatán A tanszék területén elvégzett mérések után úgy döntöttem, hogy betekintek az I épület harmadik emeletén található Távközlési és Médiainformatikai Tanszék területén kiépített WLAN hálózat forgalmába. A BSSList az alábbi access point-ot jelezte: 00:80:c8:15:06:dc TTT rssi = 54 channel = 0 ESS Mint látható, a hálózati azonosító ezen a tanszéken TTT (azaz a tanszék régi nevének – Távközlési és Telematikai Tanszék – rövidítése). Nem sikerült vezeték nélküli kliens forgalmát a mérés ideje alatt megfigyelnem, viszont a tanszék Master Browser-e által küldött UDP broadcast üzeneteket igen. (21 ábra) 21. ábra UDP broadcast üzenetek A WLAN hálózat itt egy alhálózatot alkot a vezetékes hálózattal, illetve az IP címek egy tartományból kerülnek ki. Ez bizonyos szempontból jó (például a tapasztalt üzenetek miatt a Windows-os file megosztások látszódnak mind a vezetékes,

mind a vezeték nélküli részen), viszont biztonsági kérdéseket is felvet (az esetleges támadó a tanszék címtartományából kap IP címet). Valószín leg a hálózatot kiépít személyek megtalálták a számukra legmegfelel bb
megoldást. Mivel nem akartam támadóként fellépni, ezért a vizsgálódást rövidesen abbahagytam. – 65 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Összegzés A vezeték nélküli LAN technológia, viszonylag új, még nem teljesen kiforrott módszer. Biztonsági problémái miatt sajnos ezidáig sok helyen nem szívesen alkalmazzák. A biztonsági mechanizmus továbbfejlesztésével, és újabb sebességnövel módszerek kidolgozásával, alkalmazásával viszont a közeljöv ben konkurenciát jelenthet a vezetékes LAN-ok számára is, hiszen ilyen hálózatok kiépítése, sokkal bonyolultabb, kivitelezése hosszabb id t vesz igénybe, és a vezetékek, csatlakozók hibaforrást jelentenek.

Munkám során részletesen megismerkedtem a WLAN hálózati technológiával, különösképpen a biztonsági kérdésekre fokuszálva. Társaimmal megterveztünk és kiépítettünk egy mintahálózatot, mely tavaly május óta a Híradástechnikai Tanszék munkatársainak rendelkezésére áll. Tökéletesen biztonságos hálózat nem létezik, minden hálózat legkritikusabb pontjai a felhasználók, akik ha okosan használják a hálózat nyújtotta lehet ségeket, a legügyesebb támadóknak sem lesz esélyük megszerezni a bizalmas információkat. Manapság azonban a felhasználók nagy része azt hiszi, hogy biztonságos hálózat kialakítása a rendszergazdák dolga. Szerintem, ha az átlagos felhasználók jobban ügyelnének, az adataik is sokkal nagyobb biztonságban lennének. Munkám során írtam az IEEE 802.11 szabványcsaláddal kapcsolatos fontosabb tudnivalókról, különös figyelmet fordítva a kapcsolódó biztonsági megoldásokra. Röviden bemutattam

a tanszékünkön található WLAN hálózat kiépítését és az általam kidolgozott biztonsági rendszert. Majd leírtam, hogyan készítettem egy hasznos segédprogramot, mellyel a WLAN hálózatok vizsgálhatóak biztonsági szemszögb l, és mutattam példát a program használatára. Bízom benne, hogy tapasztalataimat mások is fel tudják használni biztonságosabb vezeték nélküli rendszerek kiépítésére. – 66 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Felhasznált irodalom [1] Csórián Sándor: Hálózat kábel nélkül COMPUTERWORLD – Számítástechnika 2001/20, 2001/29. [2] Ian Goldberg: The Insecurity of 802.11 An analysis of the Wired Equivalent Privacy protocol, Black Hat Briefings, 11 July, 2001 [3] Security of the WEP algorithm http://www.isaaccsberkeleyedu/isaac/wep-faqhtml [4] Florida State University - Computer Science Department: WEP Security www.csfsuedu/~yasinsac/group/slides/cubukcupdf [5] Hendra Hendrawan:

How WPA secures the Wi-Fi connection and eliminates the weaknesses in WEP. GSEC Practical, Oct 22, 2003 [6] An Introduction to IP Security (IPSec) Encryption http://www.ciscocom/warp/public/105/IPSECpart1html [7] IPTables tutorial http://iptables-tutorial.frozentuxnet/iptables-tutorialhtml [8] A Linux kernel forráskódja ftp://ftp.kernelorg/pub/linux/kernel/v24/ [9] A FreeSWAN forráskódja http://www.freeswanca/downloadphp [10] Marcus Müller féle Windows 2000 VPN Tool http://vpn.ebootisde/packagezip [11] Windows 2000 X.509 Certificate Import http://jixen.tripodcom/win2k-screenhtm – 67 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv [12] ITEF: RFC 2267 http://www.faqsorg/rfcs/rfc2267html [13] Keszei Csaba: Biztonságos hálózati elérés vezeték nélküli hálózat felett GNU/Linux szakmai konferencia, 2003 [14] Microsoft Developer Network Academic Alliance http://www.msdnaanet/ [15] Familiar Linux letöltés http://familiar.handheldsorg [16]

GPE desktop környezet letöltés http://gpe.handheldsorg [17] Familiar Linux installation guide http://familiar.handheldsorg/familiar/releases/v071/install/ [18] Martin Wright: My libpcap tutorial http://www.cetnauedu/~mc8/Socket/Tutorials/section1htm [19] GTK+ 2.0 tutorial http://gtk.org/tutorial/ [20] Tcpdump manual page http://www.tcpdumporg/tcpdump manhtml – 68 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv Rövidítésjegyzék AH Authentication Header AP Access Point BOOTP Bootstrap Protocol BPSK Binary Phase Shift Keying CCK Complementary Code Keying CRC Cyclic Redundancy Check CSMA/CA Carrier Sense Multiple Access/Collosion Avoidance CSMA/CD Carrier Sense Multiple Access/Collosion Detection CTS Clear to Send DBPSK Differential Binary Phase Shift Keying DHCP Dynamic Host Control Protocol DQPSK Differential Quadrature Phase Shift Keying DSSS Direct Sequence Spread Spectrum ESP Encapsulated Secure Payload FHSS

Frequency Hopping Spread Spectrum FTP File Transfer Protocol GSM Global System for Mobile communication HTTP HyperText Transfer Protocol HTTPS Secure HTTP IEEE Institute of Electrical and Electronics Engineers IP Internet Protocol IPSec IP Security Protocol ISM Industrial, Scientific, and Medicine IV Initialisation Vector LAN Local Area Network MAC Medium Access Control MC2L Mobil Communications and Computing Laboratory NAT Native Address Translation OFDM Ortogonal Frequency Division Multiplex – 69 – http://www.doksihu WLAN hálózatok biztonsági analízise – diplomaterv QAM Quadrate Amplitude Modulation QoS Quality of Service RTS Request to Send SCP Secure Copy SHF Super High Frequency SNMP Simple Network Management Protocol SSH Secure Shell SSID Service Set Indentifier TCP Transmission Control Protocol TFTP Trivial File Transfer Protocol UDP User Datagram Protocol UHF Ultra High Frequency UTP Unshielded Twisted Pair WEB

Wireless Ethernet Bridge WEP Wired Equivalent Privacy Wi-Fi Wireless Fidelity WLAN Wireless Local Area Network – 70 –