WLAN hálózatok biztonsági analízise

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 [email protected]

Konzulens: Schulcz Róbert [email protected]

Budapest, 2004. március 30.

WLAN hálózatok biztonsági analízise – diplomaterv

Tartalomjegyzék

TARTALOMJEGYZÉK........................................................................................................................................2 BEVEZETŐ ............................................................................................................................................................3 1. A 802.11 SZABVÁNY ÁTTEKINTÉSE...........................................................................................................5 1.1 VEZETÉK NÉLKÜLI HÁLÓZATOK TÖRTÉNETE............................................................................................................5 1.2 A WLAN HÁLÓZATOK FIZIKAI RÉTEGE................................................................................................................7 1.3 VEZETÉK NÉLKÜLI HÁLÓZATOK KÖZEGHOZZÁFÉRÉSI MÓDSZEREI..............................................................................11 1.4 WLAN TOPOLÓGIÁK........................................................................................................................................14 1.4.1 Infrastruktúra hálózat.........................................................................................................................................14 1.4.2 Cellaváltás infrastruktúra hálózatban................................................................................................................15 1.4.3 Ad Hoc üzemmód..............................................................................................................................................17 1.4.4 Vezeték nélküli hidak........................................................................................................................................18

1.5 BIZTONSÁGI KÉRDÉSEK......................................................................................................................................19 1.5.1 A WEP...............................................................................................................................................................20 1.5.2 Az EAP..............................................................................................................................................................26 1.5.3 A WPA...............................................................................................................................................................28 1.5.4 IEEE 802.11i – a jöv ........................................................................................................................................30 1.5.5 Alternatív biztonsági megoldások.....................................................................................................................30 1.5.6 IPSec..................................................................................................................................................................32

2. TANSZÉKI WLAN HÁLÓZAT KIÉPÍTÉSE...............................................................................................36 2.1 FIZIKAI KIÉPÍTÉS...............................................................................................................................................36 2.2 BIZTONSÁGI KÉRDÉSEK......................................................................................................................................39 2.2.1 Gateway funkciók..............................................................................................................................................39 2.2.2 Hálózati címfordítás...........................................................................................................................................40 2.2.3 T zfal beállítása.................................................................................................................................................42 2.2.4 Engedélyezés weben keresztül..........................................................................................................................44 2.2.5 A WEP beállítása...............................................................................................................................................45 2.2.6 IPSec alkalmazása..............................................................................................................................................46

3. EGY SEGÉDPROGRAM ELKÉSZÍTÉSE...................................................................................................53 3.1 FAMILIAR L INUX..............................................................................................................................................53 3.2 PROGRAM FORDÍTÁSA PDA-RA..........................................................................................................................54 3.3 A PROGRAM ELKÉSZÍTÉSE..................................................................................................................................55 3.3.1 A pcap használata..............................................................................................................................................55 3.3.2 A GTK+.............................................................................................................................................................56 3.3.3 A program m ködése.........................................................................................................................................57 3.3.4 A program használata........................................................................................................................................59

4. A TANSZÉKI WLAN HÁLÓZAT VIZSGÁLATA......................................................................................61 4.1 A MÉRÉS MEGTERVEZÉSE...................................................................................................................................61 4.2 ELS HELYSZÍN: MCL LABOR EL TTI TERÜLET....................................................................................................62 4.3 MÁSODIK HELYSZÍN: A TANSZÉK ÉSZAKI FOLYOSÓJA.............................................................................................64 4.4 MÉRÉS A TÁVKÖZLÉSI ÉS MÉDIAINFORMATIKAI TANSZÉK HÁLÓZATÁN....................................................................65

ÖSSZEGZÉS.........................................................................................................................................................66 FELHASZNÁLT IRODALOM...........................................................................................................................67 RÖVIDÍTÉSJEGYZÉK.......................................................................................................................................69

–2–


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–

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 802.11-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–


1. A 802.11 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 802.11 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–

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 802.11b. Végül

megjelent 2001-ben a 802.11g szabvány. Az eredeti IEEE 802.11 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 802.11g 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–

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 802.11b-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–


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–

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–

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 –

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 802.11 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 –

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 –

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 –


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.4.1 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 –

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.4.2 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 –

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 –


1.4.3 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 –

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.4.4 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ó 802.11b 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 –


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 –

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.5.1 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 –

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 –

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 –

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

– 23 –

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

= <M,c(M)> = <M = <M

RC4(v,k)

RC4(v,k)

D, c(M) D, c(M

c(D)> D)>

=

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 –

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 –

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.5.2 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 802.11-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 –

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 –


1.5.3 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 –

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 –


1.5.4 IEEE 802.11i – 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.5.5 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 –

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.5.5.1 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.5.5.2 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 –

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.5.6 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 –

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.5.6.1 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 –

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 –

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.5.6.2 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 –


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 –


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 –


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 –

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.2.1 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 –

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.2.2 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.0.0.0 / 255.0.0.0 172.16.0.0 / 255.240.0.0 192.168.0.0 / 255.255.0.0

– 40 –

WLAN hálózatok biztonsági analízise – diplomaterv Mi ez utóbbi tartomány legalsó 192.168.0.0 / 255.255.255.0 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 –


2.2.3 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 –

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 –

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.2.4 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 –

WLAN hálózatok biztonsági analízise – diplomaterv Ezt a weboldalt a https://zen.hit.bme.hu/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 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.2.5 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 –

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.2.6 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.2.6.1 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 –

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.2.6.2 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 –

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.168.0.112

#mobil IP címe

lefttsubnet=192.168.0.112/32 [email protected] leftrsasigkey=0sAQPIPN9uI... right=192.168.0.254

#a tűzfal IP címe

rightsubnet=0.0.0.0/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.168.0.112 (left=192.168.0.112), subnetje saját maga (leftsubnet=192.168.0.112/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.168.0.112

#mobil IP címe

rightsubnet=192.168.0.112/32 [email protected]

– 48 –

WLAN hálózatok biztonsági analízise – diplomaterv rightrsasigkey=0sAQNu9+h... left=192.168.0.254

#a tűzfal IP címe

leftsubnet=0.0.0.0/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 X.509-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 –

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/x509cert.der

A két keletkezett file-t bemozgatjuk a helyére: mv newcert.pem /etc/ipsec.d/certs/zen-cert.pem mv newreq.pem /etc/ipsec.d/private/zen-priv.pem

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 newreq.pem -certfile demoCA/cacert.pem -out w-cert.p12

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 –


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.168.0.123 right=192.168.0.254 rightsubnet=0.0.0.0/0 rightca="C=HU,S=NA,L=Budapest,O=BME,OU=MCL,CN=MCL CA,[email protected]" network=auto auto=start pfs=no

Lássuk a szerver oldali konfigurációt: conn winlap left=192.168.0.254 leftrsasigkey=%cert leftcert=zen-cert.pem leftid="C=HU,S=NA,L=Budapest,O=BME,OU=MCL,CN=MCL CA,[email protected]" right=192.168.0.123 rightrsasigkey=%cert rightcert=/etc/ipsec.d/certs/winlap-cert.pem rightid="C=HU,S=NA,L=Budapest,O=BME,OU=MCL,CN=MCL CA,[email protected]" 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 –

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 –


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 –


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 bootldr.bin 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 handhelds.org iPAQ cluster-én: A handhelds.org 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 –


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}.handhelds.org 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.3.1 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 –

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.3.2 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 –

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.3.3 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 –

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,"\tTCP: 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 –

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.3.4 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 –


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 –


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 –

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 –

WLAN hálózatok biztonsági analízise – diplomaterv BitRate: 11mbs Driver Version: airo.c 0.6 (Ben Reed & Javier Achirica) Device: 350 Series Manufacturer: Cisco Systems Firmware Version: 4.25.30 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.168.0.250) at 00:40:96:58:C5:73 [ether] on eth0 ? (192.168.0.249) at 00:40:96:58:6D:46 [ether] on eth0 ? (192.168.0.245) at 00:02:8a:21:13:fd [ether] on eth0 ? (192.168.0.246) 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 –


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.index.hu oldalra. A másik egy SSH kapcsolat az mlabdial.hit.bme.hu 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 www.index.hu 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 –


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 –


Ö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 –


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.isaac.cs.berkeley.edu/isaac/wep-faq.html [4] Florida State University - Computer Science Department: WEP Security www.cs.fsu.edu/~yasinsac/group/slides/cubukcu.pdf [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.cisco.com/warp/public/105/IPSECpart1.html [7] IPTables tutorial http://iptables-tutorial.frozentux.net/iptables-tutorial.html [8] A Linux kernel forráskódja ftp://ftp.kernel.org/pub/linux/kernel/v2.4/ [9] A FreeSWAN forráskódja http://www.freeswan.ca/download.php [10] Marcus Müller féle Windows 2000 VPN Tool http://vpn.ebootis.de/package.zip [11] Windows 2000 X.509 Certificate Import http://jixen.tripod.com/win2k-screen.htm

– 67 –

WLAN hálózatok biztonsági analízise – diplomaterv [12] ITEF: RFC 2267 http://www.faqs.org/rfcs/rfc2267.html [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.msdnaa.net/ [15] Familiar Linux letöltés http://familiar.handhelds.org [16] GPE desktop környezet letöltés http://gpe.handhelds.org [17] Familiar Linux installation guide http://familiar.handhelds.org/familiar/releases/v0.7.1/install/ [18] Martin Wright: My libpcap tutorial http://www.cet.nau.edu/~mc8/Socket/Tutorials/section1.htm [19] GTK+ 2.0 tutorial http://gtk.org/tutorial/ [20] Tcpdump manual page http://www.tcpdump.org/tcpdump_man.html

– 68 –


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 –

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 –

WLAN hálózatok biztonsági analízise

Recommend Documents