Hardver tokenes hitelesítés vezeték nélküli hálózatokban mérési útmutató

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Híradástechnika Tanszék Hardver tokenes hitelesítés vezeték nélküli hálózatokban mérési útmutató (v 1.2) Készítették: Földes Ádám Máté, Gódor Győző, Gulyás Gábor György E-mail: fa606@hszk.bme.hu Köszönet illeti továbbá Paulik Tamást és Erdős Attilát, amiért építő javaslataikkal hozzájárultak a mérés és a mérési útmutató színvonalának emeléséhez.

1. A mérés célja A vezeték nélküli hálózatok egyre inkább teret nyernek mindennapjaink számítógéphasználatában. A bárki által könnyen megközelíthető közeg azonban felvet egy sor biztonsági problémát: a hálózatban közlekedő kereteket a megfelelő ismeretekkel rendelkező támadók lehallgathatják, elnyomhatják, visszajátszhatják, stb. A mérés célja bemutatni, hogy hogyan használható a nyilvános kulcsú infrastruktúra a vezeték nélküli hálózatok védelmére. A mérés megismerteti a hallgatókat a nyilvános kulcsú infrastruktúra alapjaival, az IEEE 802.1x-re és az EAP-TLS protokollra alapulú hitelesítéssel, valamint a hardver tokenek használatával. 2. Háttérismeretek Gyakran alapvető igény egy hálózatban, hogy a hozzá kapcsolódó kliensek hitelesítése (autentikációja) megtörténjen, például számlázási vagy használatnaplózási okokból. Ez alól természetesen a vezeték nélküli hálózatok sem kivételek. Ezt mutatja, hogy ma már a legtöbb SOHO útválasztó alapbeállításként osztott kulcson alapuló hitelesítést használ leggyakrabban WEP-et vagy WPA PSK-t. A mérési feladatokban ennél összetettebb, de sok tekintetben hatékonyabb hitelesítési módokat kell konfigurálni (pl. WPA enterprise -t). E komplexebb, PKI-n alapuló hitelesítési sémák előnye lehet a rugalmasabb hozzáférésszabályozás (lásd a 2.3. fejezetet) vagy a viszonykulcsegyeztetés lehetősége. A mérés során kétféle koncepció mentén fogjuk konfigurálni a védett vezeték nélküli hálózatot. Az első esetben a hitelesítés a kliens és a hozzáférési pont (2.1. fejezet) között történik, míg a második konfigurációban a hozzáférési pont maga védtelen, de a hálózat lényeges részét csak akkor éri el a kliens, ha a hálózaton működő VPN-átjárón (2.2. fejezet) hitelesíti magát. 1 Az első koncepció előnye, hogy egyszerű, míg a másodikkal természetszerűleg szétválaszthatjuk hálózatunkat mindenki számára hozzáférhető és korlátozott hozzáférésű zónákra. 2.1. Hozzáférési pontok (Access Point, AP) A vezeték nélküli hozzáférési pont feladata, hogy bejáratként szolgáljon a hálózatra a csatlakozni kívánó kliensek számára. A WLAN-ok védelmére bevezetett biztonsági megoldások kezdeti balsikerei után a Wi-Fi Alliance a 802.11i jelzésű szabványban definiálta az ún. WPA (WLAN Protected Access) protokollt, valamint a hitelesítés és a kulcsegyeztetés lépéseit. A 802.11i szabvány bevezetéséig mindössze egyetlen titkos kulcs létezett a hitelesítésre és a rejtjelezésre. Az új eljárásokban kulcskezelési és -származtatási hierarchiát vezettek be, hogy megoldható legyen a kulcsok rendszeres időközönkénti cseréje, ami ellehetetleníti a lexikonépítő és egyéb, a hálózati forgalmat lehallgató, majd a kulcsot visszafejtő támadási lehetőségeket. A kulcshierarchiát az 1. ábra mutatja be. A mesterkulcs (Master Key, MK) a legfelső titok, melyet mind a kliensnek, mind pedig a hitelesítést végző eszköznek ismernie kell. A páronkénti mesterkulcsot (Pairwise Master Key, PMK) a mobil állomás és a hitelesítő szerver minden egyes bejelentkezésnél a mesterkulcsból generálja 2. A hitelesítő szerver ezt a kulcsot elküldi a klienssel kapcsolatban levő AP-nak, melyből ez utóbbi két fél majd a négyutas kézfogás nevű folymat segítségével származtat egy páronkénti ideiglenes kulcsot (Pairwise Transient Key, PTK). Ez a kulcs minden bejelentkezéskor illetve kulcsfrissítési kérelemnél újragenerálódik. A PTK voltaképpen egy három kulcsból álló kulcscsomó. Első 16 bájtja a kulcsmegerősítő kulcs (Key Confirmation Key, KCK), melynek célja, hogy az AP és a kliens kölcsönösen meggyőződhessen 1 A mérés során ugyanaz a számítógép tölti be az AP és a VPN-átjáró szerepét. Ez azonban egyáltalán nem kötelező. 2 PSK-n alapuló hitelesítés esetén ez az osztott kulcs. 2

Mesterkulcs (MK) PRF() Páronkénti mesterkulcs (PMK) PRF() Páronkénti ideiglenes kulcs (PTK) Kulcsellenőrző kulcs (KCK) (0-127. bit) Kulcsrejtjelező kulcs (KEK) (128-255. bit) Ideiglenes (kódoló) kulcs (TK) (256-k. bit) 1. ábra. A kulcshierarchia arról, hogy ugyanazon PMK-t ismerik. A második 16 bájtból származó kulcsrejtjelező kulcs (Key Encryption Key, KEK) célja egy csoportos ideiglenes kulcs (Group Transient Key, GTK) kiosztása a kliensek részére. A GTK-t többesküldésre (multicast) és szórásra (broadcast) használják. A PTK utolsó bájtjai adják az ideiglenes kulcsot (Transient Key, TK), mely a TKIP vagy CCMP szerinti rejtjelezéshez használatos. Az autentikáció során az AP a 802.1x protokollt használja, mely az EAP (Extensible Authentication Protocol) nevű biankó hitelesítési protokollon alapszik. Ennek lényege, hogy a csatlakozó kliens először csak egy hitelesítő szerverrel (Authentication Server, AS) kommunikálhat, pl. RADIUS protokoll szerint. Minden, a kliens és az AS közötti kommunikáció ún. EAP over LAN keretekbe ágyazva közlekedik, méghozzá úgy, hogy az AP szempontjából a valódi hitelesítési protokoll lényegtelen. EAP-ot használó protokollok például az EAP-MD5, EAP-TTLS, LEAP, PEAP és az EAP-TLS. Számunkra ez az utolsó módszer az érdekes, mert mind a kliens, mind az AS számára kötelező benne a PKI (2.3. fejezet) támogatása. EAP-TTLS esetén a kliensnek nem kötelező PKI-képesnek lennie, míg az EAP-MD5-nél csak egy jelszó MD5 lenyomata képezi a hitelesítés alapját (vezeték nélküli hálózatokon nemigen alkalmazzák, mert nem biztonságos, és a protokoll nem szolgáltat alapanyagot egy viszonykulcs származtatásához). Az EAP TLS-re alapuló hitelesítésnél az EAP kommunikációt az AP kezdeményezi egy EAP- Request Identity üzenettel, melyre a mobil állomás (Mobile Station, MS) egy EAP-Response Identity / MS-Identifier üzenettel válaszol. Miután az AP észlelte, hogy EAP-képes eszköz csatlakozott hozzá, kapcsolódik az AS-hez (mely egyben TLS szerver is), és elküld számára egy EAP-Response üzenetet, egy RADIUS Access Request üzenetbe ágyazva. Az AS-től egy RADIUS Access Challenge üzenetbe ágyazott EAP-Request érkezik válaszul, melyet az AP a RADIUS-fejléc nélkül továbbít az MS-nek. Ezután egy egyszerű TLS hitelesítés veszi kezdetét, mely az AP számára transzparens, EAP-Response 3

és EAP-Request üzenetekbe ágyazva közlekedik az MS és az AS között. A hitelesítés végén a PMK generálása következik, majd az AS EAP-Success üzenettel tudatja az AP-vel, hogy a hitelesítés sikeresen lezajlott. Az AP ennek hatására megnyitja az MS-hez tartozó portot. Mint említettük, a PTK származtatásakor az ún. négyutas kézfogás nevű folyamat zajlik le (2. ábra). Mobil állomás AP Csatlakozási kérés MK-ból generálja, vagy a hitelesítési szerver küldi el PMK PMK PTK = PRF(PMK, R1, R2, MAC1, MAC2) R1 PTK R2, MIC PTK Használd a TK-t!, MIC OK, MIC Az eljárás részletei a következők: 2. ábra. A négyutas kézfogás 1. Az AP elküldi az általa generált véletlen számot (R 1 ) a mobil állomásnak. 2. Az MS generál egy másik véletlen számot (R 2 ). Ezután a PMK, R 1, R 2, az AP MAC címe és a saját MAC címe segítségével legenerálja a PTK-t az EAPoL-PRF (pseudorandom function) segítségével. Az AP ezután egy EAPoL üzenetet fogad az MS-től, melyben megkapja az R 2 számot. 3. Az AP egy EAPoL üzenetben utasítja az MS-t az ideiglenes kulcs beállítására, és újra elküldi R 1 -et. 4. A negyedik kézfogási lépés egy egyszerű nyugta (MS AP). Megjegyzendő, hogy az első kézfogási lépést kivéve mindegyiket MIC (Message Integrity Check) hitelesíti. Ez az oka például annak, hogy az AP két lépésben is elküldi a véletlen számát. A mérés első részében tehát egy egyszerű PC-t kell AP-ként konfigurálni, EAP-TLS hitelesítéssel. A hitelesítő kiszolgáló és a hozzáférési pont ugyanazon a hardveren fog futni, azonban megjegyzendő, hogy a valóságban ez a legtöbbször nem így van. 4

2.2. Virtuális magánhálózatok (Virtual Private Network, VPN) A virtuális magánhálózatok a szó klasszikus értelmében több hálózat összekötését szolgálják az ezen hálózatokat üzemeltető személyek vagy szervezetek számára kontrollálhatatlan és megbízhtatalan közbenső hálózatszakaszok felett. Az összekötendő hálózatok a külvilág felé mindössze átjárókat (gateway) mutatnak, és az átjárók közti ún. alagutakon vezetik át a hálózatközi forgalmat. Az ilyen alagút legtöbbször többek közt erős rejtjelezéssel és integritásellenőrzéssel védett. Az ún. hozzáférési VPN-ek annyival egyszerűbbek, hogy az összeköttetés egy kliens és egy hálózat közt jön létre. Technikailag annyi a különbség, hogy az alagút egyik végpontja gyakran változik, és emiatt a hálózat meglehetősen dinamikus felépítésű. A Windowsba épített L2TP/IPSec kliens pontosan ilyen hálózatokhoz képes csatlakozni. A mérés második részében tehát egy hozzáférési VPN-t kell építeni. A cél az, hogy a védtelen hozzáférési pontra csatlakozott kliensek csak a VPN-re kapcsolódás után érhessék el a külső hálózatot. Az IPSec hálózati rétegbeli protokoll többek közt megvalósítja a rejtjelezést és az integritásellenőrzést a biztonsági hozzárendelések (Security Association, SA) segítségével 3, míg az L2TP szerepe az IPSec csomagok beágyazására és az átjáróhoz történő transzparens, alagút típusú átvitelére korlátozódik 4. Az L2TP-alagút a kliens és az átjáró operációs rendszere számára egyaránt egy-egy ideiglenes, mondhatni virtuális hálózati interfészként látszik, melynek az alagút felépítésekor IP-címet osztanak ki. Valamelyest hasonló működés persze megvalósítható csak IPSecet használva is felmerül a kérdés, hogy miért van szükség az L2TP-re? A válasz egyszerű: a Windowsba épített kliens csak L2TP-vel együtt kezeli az IPSec-et a mérés előkészítésének pillanatában fellelhető egyéb kliensek pedig vagy fizetősen, vagy nem támogatják a tokeneket. (Lehetséges Windowsban is csak IPSec alagutat konfigurálni a Microsoft Management Console-lal, de ez csak klasszikus VPN-eknél egyszerű, hozzáférési VPN-eknél nem. A tokenes hitelesítés mindazonáltal egyik esetben sem lehetséges jóllehet klasszikus VPN-nél nem is igazán lenne praktikus.), L2TP alagút építésére IPSec nélkül viszont van lehetőség. A mérés során érdemes lehet külön konfigurálni az L2TP-t, és ha az már stabilan működik, akkor rátérni az IPSecre így sokat egyszerűsödik a hibakeresés. A Windows csak akkor tekint el az IPSec SA-k felépítésétől, ha előtte egy rendszerleíróadatbázis-kulcsot 5 módosítunk/létrehozunk. A mező típusa duplaszó, jelentése 0-s érték esetén engedélyezett IPSec, 1-es esetén letiltott IPSec [2]. A rendszerleíró adatbázisban végzett módosítások természetesen csak újraindítás után jutnak érvényre. 2.3. A nyilvános kulcsú infrastruktúra (Public Key Infrastructure, PKI) A PKI célja, hogy aszimmetrikus kriptográfiai nyilvános kulcsokat alanyokkal (személyekkel, esetleg számítógépekkel) kössön össze. Ehhez szükség van egy tanúsítványkiadóra (Certificate Authority, CA), aki tanúsítványokat bocsát ki, melyek igazolják, hogy egy adott nyilvános kulcsot ki használ (értelemszerűen a privát kulcsot csak a jogos felhasználó ismeri). A CA-nak is van saját tanúsítványa. A CA egy olyan fél, akiben az infrastruktúra összes résztvevőjének meg kell bíznia. Ha ez teljesül, akkor egy tanúsítványról az infrastruktúra egyéb szereplői el tudják dönteni, hogy érvényes-e, lévén a CA minden általa kiadott tanúsítványt aláír a saját privát kulcsával. A CA iránti bizalom több forrásból is származhat. A valóságban gyakran más CA-k is aláírhatják a tanúsítványát, a mérés során azonban ún. önaláírt tanúsítványt használunk ez azt jelenti, hogy a CAnk tanúsítja, hogy ő maga milyen nyilvános kulcsot használ. Ez önmagában tautológiának hat; valóban, értelmet csak akkor nyer egy ilyen tanúsítvány, ha ezt az operációs rendszerben vagy a konfigurálni kívánt PKI-képes szoftverben kézzel hozzávesszük a megbízható CA-k listájához. Természetesen 3 Az SA mindig unilaterális, tehát a kétirányú forgalomhoz két SA kiépítése szükséges. 4 Az L2TP nem rejtjelezi az átvitt adatokat! Az alagút maga tehát csak a felépítését tekintve biztonságos, amikor is a kliens és az átjáró kölcsönösen hitelesítik egymást. 5 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\ProhibitIpSec 5

ilyenkor a külvilág számára ez a CA megbízhatatlan lesz, a mérés során azonban teljesen elegendő, ha csak egy helyi CA-ig tudjuk visszavezetni az infrastruktúrát. A tanúsítványok érvényességét több tényező is szabályozhatja. Egyrészt mindegyik csak egy meghatározott időpontig érvényes, másrészt lehetőség van egy tanúsítványt már a lejárat előtt is visszavonni. Ez utóbbi módszer működhet on-line vagy off-line módon. Előbbire példa az Online Certificate Status Protocol (ez egy tanúsítványellenőrző szerver üzembe állítását igényli), míg utóbbi a tanúsítványvisszavonási listák (Certificate Revocation List, CRL) időszakos kibocsátásán és terjesztésén alapszik. A valóságban egy cég egy alkalmazottjának tanúsítványának érvénytelenítésére például akkor lehet szükség, amikor a munkatárs elhagyja a céget, vagy akkor, ha az alkalmazott privát kulcsa nyilvánosságra kerül. 2.4. Hardver tokenek A mérés során használt Aladdin etoken Pro 32k (lásd a 3. ábrát) hardver token funkcionálisan azonos egy intelligens kártyával (smart card). Az intelligens kártyák az autentikáció szempontjából nézve kéttényezős hitelesítési megoldások: a jogosult felhasználó egyrészt birtokában van valamilyen azonosító kódnak (PIN-kód), valamint az eszköz a memóriájában tárol egy kulcsot is, melyet a külvilág számára soha nem ad ki. A kártya csak akkor hajlandó a benne tárolt titkos adatokkal való műveletvégzésre, ha a felhasználó a helyes PIN-kódot adta meg számára. 3. ábra. Aladdin etoken Pro 32k Az ilyen eszközök egyik értelemszerű felhasználása a tanúsítványok és a hozzájuk tartozó privát kulcsok tárolása. A privát kulcsot titkos adatként jelöljük meg, míg a tanúsítványt publikusnak. Az így konfigurált eszközről a PKI-képes szoftver lekéri a tanúsítványt, és bemutatja a minket hitelesíteni szándékozó kiszolgálónak. A kézfogási vagy viszonykulcsegyeztetési fázisban a token a saját processzorát és memóriáját használja a privát kulccsal végzendő operációk kiszámításához, és a gazda rendszer (a tokent fogadó számítógép) csak az eredményről értesül. Végeredményben tehát így biztosítható, hogy a hitelesítés csak mindkét tényező (a PIN-kód ismerete és az eszköz fizikai birtoklása) esetén legyen sikeres, és hogy a gazda számítógép feltörése esetén se juthasson a támadó birtokába mindkét hitelesítési tényező. Az etoken PRO ún. tamper evident eszköz, vagyis a vele való manipuláció könnyen észrevehető (persze a privát kulcs kiolvasása még a memórialapka kiforrasztása esetén sem triviális feladat egy átlagos támadónak). A drágább tokenek lehetnek tamper proofok is, ami azt jelenti, hogy ha a hardver sérülést észlel magán, akkor törli a memóriában tárolt titkos információkat (pl. nullákkal írja felül, vagy fizikailag tönkreteszi a lapkát). 3. A mérési konfiguráció A mérési elrendezés a következő hardvereszközökből áll (a topológiát lásd a 4. ábrán): 1 darab Aladdin etoken Pro hardver token 6

1 darab szerver Ubuntu Linux 8.10 operációs rendszerrel, 1 darab vezeték nélküli hálózati kártyával. A szerver szerepe a CA és az AP/VPN átjáró feladatkörökre terjed ki. A vezeték nélküli interfész kezelését a madwifi szoftver végzi, a WPA-enterprise protokollt pedig a hostapd implementálja. Figyelem! A szerverben használt 3Com WLAN kártya csak akkor aktiválja a rádióadóvevőjét, ha az antenna kilóg a kártya testéből. Érdemes a kártyát már kinyomott antennával bedugni a PCMCIA aljzatba. 1 darab kliens Windows XP operációs rendszerrel, 1 darab vezeték nélküli hálózati kártyával. A vezeték nélküli hálózathoz való csatlakozáshoz a Windows XP Zero Configuration nevű szolgáltatását lehet használni. Mobil állomás Access Point (AP) Hitelesítő szerver (AS) 4. ábra. Mérési elrendezés 4. Mérési feladatok A mérés során kiadandó parancsok nagy része rendszergazdai jogosultságokat igényel ezeket a sudo utasítás argumentumaként kell futtatni. Hogy ezt elkerüljük, lehetséges rendszergazdai jogú promptot kérni a sudo su paranccsal. Ilyenkor azonban nem árt a kellő körültekintés, mivel így könnyebb olyan súlyos hibákat véteni (pl. létfontosságú fájlokat felülírni-törölni), melyeket a Linux rendszermag jogosultsági mechanizmusai egyébként kiküszöbölnének. 4.1. PKI létrehozása A szervergépen megtalálja a TinyCA nevű, a tinyca2 paranccsal indítható alkalmazást, mely voltaképpen az OpenSSL nevű PKI implementáció fölé illesztett grafikus felület. Ezen alkalmazás segítségével kell majd egy CA-t létrehoznia, valamint tanúsítványokat kiadnia a rendszer különböző szereplőinek (mint amilyen például a vezeték nélküli hozzáférési pont vagy a hozzá IEEE 802.1x protokoll segítségével csatlakozó kliens). Mielőtt a CA tanúsítvány legenerálásra kerül, ellenőrizni kell a rendszeridő helyes állását úgy a szerveren mint a kliensen, különben a tanúsítványok érvényességi idejével kapcsolatos problémákba ütközhet! A TinyCA az első indításkor felajánlja egy CA inicializálását. A feldobott panel mezőit értelemszerűen kitöltve generálhat egy önaláírt CA tanúsítványt (a paraméterek tetszőlegesek). Az inicializált CA segítségével ezután egy szervertanúsítványt kell létrehozni (Certificates fül New Server Certificate) ezt fogja használni az AP-t illetve a VPN átjárót megvalósító szoftver. Vigyázat! A Windows csak azokat a tanúsítványokat fogadja el egy AP esetében, amelyekben az Extended Key Usage (EKU) mező értéke 1.3.6.1.5.5.7.3.1. Ezt csak akkor tudjuk megadni, ha előzetesen 7

kiválasztja a megfelelő opciót (Preferences OpenSSL Configuration Server Certificate Settings Extended Key Usage Ask User). Ha ez kész van, akkor legenerálhatjuk a szervertanúsítványt a már említett menüpont alatt. 4.1.1. Kérdések 1. Milyen kulcshosszt választott a CA privát kulcsának? Miért? 2. Milyen előnyei és hátrányai vannak a rövidebb illetve a hosszabb kulcsoknak? 4.2. A hardver token inicializálása A tokent inicializálni kell a hozzá tartozó menedzsmentfelületen, mely úgy a szerveren, mint a kliensen megtalálható mindkét helyen a rendszertálca egyik ikonjaként. Ezen a felületen az Advanced gommbal nézetet váltva az 5. ábrához hasonló ablakot kapunk. 5. ábra. Menedzsmentfelület Ha a tokent a számítógép egyik USB portjába dugja, akkor az meg is jelenik a képernyő bal oldalán levő fában (az ábrán etoken). Válassza ki, majd nyomja meg az Initialize etoken gombot. Az inicializálásnál érdemes felhasználói és adminisztrátori jelszót is megadni. Az Advanced gombbal további beállításokat is konfigurálhat, ezek közül érdemes lehet bekapcsolni az SHA1 és a 2048 bites kulcsok támogatását (ne nyúljon viszont a FIPS mode és a Manually set number of reserved RSA keys beállításokhoz!). Nem árt továbbá adminisztrátori jelszót is felkonfigurálni a felhasználói mellé. 4.3. AP-s hitelesítés beállítása 4.3.1. Az AP konfigurálása Ahhoz, hogy a szervert hozzáférési pontként lássa a kliensen futó szoftver, két ún. daemon felkonfigurálása szükséges. Ezek a hostapd, az udhcpd. Előbbi az AP-funkcionalitást valósítja meg, míg utóbbi egy meglehetősen leegyszerűsített DHCP szerver. A hostapd konfigurációs állománya a /etc/hostapd/hostapd.conf elérési út alatt található. Ebben a fájlban minden lehetséges konfigurációs lehetőség le van írva a kommentezett sorokban. (A fájl szerkesztéséhez ajánlott a nano szövegszerkesztő használata.) A fontosabb beállítások az 1. táblázatban vannak felsorolva. A beállításoknál ügyeljen rá, hogy a környezetben egyedi SSID-t válasszon a hálózat számára. Igény szerint kapcsolja be az SSID szórását. A TinyCA segítségével exportálja a tanúsítványt és a hozzá tartozó privát kulcsot PEM formátumban, 8

Beállítás Funkció interface A vezeték nélküli hálózati interfész neve. driver Az interfész meghajtóprogramja. Értéke madwifi. hw_mode Az interfészre beállítandó 802.11 szabvány. Értéke g. channel A rádiós csatorna száma. Értéke 1 és 13 közt tetszőleges. debug A program által kiírt információ mennyisége. Ajánlott értéke 4. ssid A beállítani kívánt SSID. auth_algs A felhasznált hitelesítési séma. Értéke 3. ieee8021x 802.1x engedélyezése. Értéke 1. eap_server Belső RADIUS szerver engedélyezése. Értéke 1. ca_cert A CA tanúsítványának elérési útja. server_cert A szerver tanúsítványának elérési útja. private_key A szerver privát kulcsának elérési útja. private_key_passwd A privát kulcsot védő jelszó. wpa_key_mgmt Az alkalmazott kulcsmenedzsment módszer. Értéke WPA-EAP. wpa_pairwise A rejtjelezési protokoll. Értéke TKIP. eap_user_file A felhasználókat és a hitelesítési protokollokat felsoroló fájl neve. 1. táblázat. A hostapd miniálisan konfigurálandó paraméterei. és helyezze el a konfigurációs fájlban hivatkozott útvonalon. A belső RADIUS szerver használata azért előnyös, mert így nem szükséges külső RADIUS kiszolgáló (pl. FreeRADIUS) konfigurálása. Így persze elveszítjük egy valódi RADIUS szerver rugalmasságát, de a mérés során erre nincs szükség. Az eap_user_file paraméter egy állományra kell, hogy mutasson, ahol felsoroljuk a felhasználóneveket (alapértelmezésben ez azonos a később létrehozandó klienstanúsítvány alanyával) és a hozzájuk használandó hitelesítési protokollt. Segítségképpen a /templates/users állományban elhelyeztünk egy sablont. A konfigurációs állomány szerkesztésénél fokozott óvatossággal kell eljárni. A leggyakoribb hibaforrás például az ütköző beállítások használata (pl. PSK hitelesítés használata, de PKI-n alapuló hitelesítési információ szórása). Ha végzett a konfigurációs állománnyal, akkor a madwifi szoftverhez tartozó wlanconfig eszköz segítségével törölni kell az alapértelmezésben beállított STA módú eszközt (wlanconfig athx destroy), majd fel kell definiálnunk helyette egy AP módút (wlanconfig athx create wlandev wifiy wlanmode ap). Az iwconfig paranccsal ellenőrizheti az interfész sikeres létrejöttét. Ha mindez megvan, akkor győződjön meg róla, hogy a hostapd nem fut (pl. adja ki a killall hostapd parancsot), majd indítsa el a hostapd -dd /etc/hostapd/hostapd.conf paranccsal. Megjegyzendő, hogy a hostapd futtatható a service parancs segítségével is, de akkor nehezebb lesz a hibakeresés, mert a program daemon módban indul el. Ha a hostapd sikeresen elindult, ellenőrizze az iwconfig paranccsal, hogy visszaköszönnek -e a hostapd-nek megadott paraméterek az aktív beállítások közt. Vigyázat! Vélelmezhetően a madwifi hibájának köszönhetően időnként 802.11a módra vált a hálózati interfész a hostapd elindítása után. Ilyenkor a hostapd-t le kell állítani, a wlanconfig paranccsal pedig törölni kell az interfészt, majd ugyanúgy újra létrehozni. Ha nem így tesz, azzal a rendszer lefagyását kockáztatja! Ha az interfészt sikeresen felkonfigurálta, akkor már csak IP-címet kell neki adni (ifconfig athx www.xxx.yyy.zzz), majd fel kell húzni (ifconfig athx up). Ezzel már van egy interfészünk, mely képes az előzőleg létrehozott CA által aláírt klienstanúsítványok segítségével hitelesíteni a hálózathoz csatlakozni szándékozókat, az általában megszokott automatikus IP-cím konfiguráció azonban még hiányzik ezért van szükség az udhcpd-re. Ennek a szoftvernek a konfigurációs állománya korántsem mondható bőbeszédűnek, ezért segítségül egy kitölthető mintát helyeztünk el itt: /template/udhcpd.conf. 9

Ha végzett a konfigurálással, elindíthatja az udhcpd-t, méghozzá a nem éppen túlbonyolított udhcpd paranccsal. 4.3.2. Kliens konfigurálása A TinyCA segítségével ezek után létre kell hozni a kliens tanúsítványát is (Certificates fül New Client certificate). Itt is figyelni kell az EKU mezőre, melynek értéke vezeték nélküli kliensek esetén kötelezően 1.3.6.1.5.5.7.3.2. Vigyázat! Az EKU mezőre való rákérdezést a TinyCA-ban be kell állítani itt is, pontosan ugyanúgy mint a szerver tanúsítványa esetében, csak épp a Client Certificate Settings fülön. Ezen kívül vigyázni kell a kulcshossz megválasztásával is, mert a token nem képes kezelni az 4096 bit hosszú privát kulcsokat. Ha kész a kliens tanúsítványa, azt PKCS12 formátumban kell exportálni, és fel kell tölteni a tokenre 6. A tanúsítvány feltöltését a menedzsmentfelület Advanced nézetében az Import Certificate gombbal végezheti el. Ezek után, ha a tokent a kliens gépbe dugja, az operációs rendszer azonnal megkérdezi, hogy akarjuk-e importálni a rajta levő tanúsítványokat. A kérdésre Igen -nel kell felelni, máskülönben a Windows nem fog megbízni a kliens számára kiosztott tanúsítványban. Ezután konfiguráljon fel egy kapcsolatot a kliensen a Windows Zero Configuration vezeték nélküli hálózati szolgáltatásában. Az előzőekben megválasztott SSID-vel és rejtjelezési módot kell használnia. Ügyeljen rá, hogy a hitelesítési mód az Intelligens kártya legyen. Megfelelő beállítások esetén a kliens sikeresen kapcsolódik az AP-hez, és automatikusan kap IP-címet a DHCP-szerver tartományából. Valós környezetben a hitelesített kliensek számára gyakran hozzáférést biztosítunk egy külső hálózathoz, például az Internethez. Ennek egyik legegyszerűbb módja a hálózati címfordítás (NAT, Network Address Translation) használata, melyet a boltban megvásárolható SOHO WLAN útválasztók többsége alkalmaz. A legtöbb Linux-disztribúcióhoz mellékelt iptables csomagszűrő tűzfal egyszerűen konfigurálható a következő parancsokkal: 1. echo 1 > /proc/sys/net/ipv4/ip_forward 2. iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE 3. iptables -A FORWARD -i eth1 -o athx -m state --state RELATED,ESTABLISHED -j ACCEPT 4. iptables -A FORWARD -i athx -o eth1 -j ACCEPT Ha minden sikeres, a csatlakozott kliensek már hozzáférnek az Internethez. Ha hibás iptables parancsot adtunk ki, akkor az iptables -F -t nat utasítással kiüríthetjük a címfordítási szabályok táblázatát. Ugyanezen táblázatot kiírathatjuk az iptables -L -t nat paranccsal. 4.3.3. Kérdések 1. Mely bejegyzéseket kellett átírni a hostapd konfigurációs állományában? 2. Figyelje meg a hitelesítési folyamatot a hostapd kimenetén! Milyen főbb lépéseket fedez fel? 3. Milyen előnyei lehetnek egy külső RADIUS szervernek a hostapd-be építettel szemben? 4. Milyen előnyei és hátrányai vannak az SSID-szórás letiltásának? 5. Milyen IP-címet választott a hozzáférési pontnak, és milyen tartomány felett rendelkezik a DHCPszerver? Miért? 6 Ha Windows alatt szeretné feltölteni a tanúsítványt, akkor ajánlott a.p12 kiterjesztés használata. 10

4.4. VPN hitelesítés beállítása 4.4.1. Az átjáró konfigurálása A VPN-hez két további szoftvert kell konfigurálni a szerveren: az xl2tpd-t és a racoont. (A hostapdre a továbbiakban nincs szükség, azt feltétlenül állítsa le!) Előbbi az L2TP, utóbbi az IPSec protokollt valósítja meg 7. A konfigurációs állományok helye: /etc/xl2tpd/xl2tpd.conf és /etc/racoon/racoon.conf. Az xl2tpd esetében a global szekcióban a portot, az lns default szekcióban pedig az ip range, a lac, a local ip, a refuse pap, a refuse chap, a require authentication, a ppp debug és a pppoptfile paramétereket kell beállítani. Ez utóbbi értéke /etc/ppp/options.xl2tpd, a többi pedig minimális gondolkodással kikövetkeztethető. Az IPSec beállításához egy mankó található itt: /templates/racoon.conf. A man xl2tpd.conf és a man racoon parancsokkal lehet további segítséget kérni. Ha a konfigurációs állományok elkészültek, akkor a wlanconfig paranccsal törölje és hozza létre újra a hálózati interfészt. Osszon ki neki csatornaszámot és IP-címet, az iwconfig eszközzel adjon neki SSID-t, és állítsa be ennek megfelelően az udhcpd-t. Ennek hatására az interfész egy védelem nélküli hozzáférési pontként fog látszani a kliensek számára. Most a PEM formátumban exportált szervertanúsítvány helyét kell megadnia a /etc/ppp/eaptlsserver helyen levő EAP-TLS konfigurációs fájlban. Az állomány elején le van írva a helyes szintaxis. Megyjegyzés: érdemes a privát kulcsot titkosítatlanul tárolni, mert az EAP-TLS patch nem kezeli a rejtjelezett kulcsfájlokat. Ezek után indítsa el (vagy indítsa újra) az xl2tpd-t és a racoont a service eszközzel. A NAT beállítását ebben a konfigurációban már máshogy kell elvégeznünk. Most ugyanis dinamikusan létrejövő interfészeken keresztül látszanak a kliensek (ppp0, ppp1,... ), ellentétben az AP-szintű hitelesítéssel, melynél egyetlen athx interfészt kellett kikötni a külső hálózatra. Ezért tanácsos az xl2tpd konfigurációs fájljában megadott IP-cím tartományra megadni a NAT-szabályt, mintsem az interfészre. A -i athx és -o athx helyett ezért --source www.xxx.yyy.zzz/vv illetve --destination www.xxx.yyy.zzz/vv paramétereket kell megadni. 4.4.2. A kliens konfigurálása A kliens a már létrehozott tanúsítványt képes használni az LNS-en való hitelesítésre. Az IPSeckel azonban más a helyzet. A Windows ugyanis megköveteli, hogy az IPSec SA-hoz a hitelesítés az ún. számítógépszintű tanúsítványtárból történjen [3] a token által használt tanúsítvány viszont a felhasználói fiókhoz tartozó tanúsítványtárhoz tartozik. Ezért hozzon létre egy másik klienstanúsítványt, melyet a Microsoft Management Console (MMC) segítségével majd elhelyezhet a számítógépszintű tanúsítványtárban. Az MMC futtatásához a Start menü Futtatás panelen az mmc parancsot kell kiadni. A felbukkanó ablakhoz új beépülő modult kell hozzáadni (Fájl menü Beépülő modul hozzáadása/eltávolítása...). A felugró panelen (6. ábra) a Tanúsítvány beépülőt kell választani, majd a Hozzáadás gombbal lehet továbblépni. A varázslóban a Számítógépfiók kezelését válassza, az utóna következő ablakban pedig a Helyi számítógépet. A varázslóból való kilépés után nincs szükség több beépülő hozzáadására, ezért az OK gommbal lépjen vissza az MMC-főablakba. A tanúsítvány importálásához (lásd a 7. ábrát) azt PKCS12 formátumban érdemes az MMC rendelkezésére bocsátani. Az ilyen formátumban történő exportálás a TinyCA-jel könnyedén elvégezhető (ajánlott a.p12 kiterjesztés használata). Fontos, hogy a PKI-hoz tartozó gyökértanúsítványunkat a számítógépszintű tanúsítványtár is megbízhatónak találja, ezért legjobb, ha a TinyCA-ben az exportáláskor 7 Az xl2tpd igazából egy frontend a pppd nevű szoftverhez, mely PPP protokoll szerint képes kapcsolatokat felépíteni. A pppd feladata a hitelesítés is, viszont az EAP-TLS alapértelmezésként nem támogatott. Ha ilyen protokollt szeretnénk használni a hitelesítéshez, akkor egy patchet kell letölteni innen: [5]. A mérés során használt átjárón a patch már telepítve van. 11

6. ábra. Új beépülő 7. ábra. Tanúsítvány importálása a CA tanúsítványának hozzáadását választja. Importálás után ellenőrizze a Megbízható legfelső szintű hitelesítésszolgáltatók pont alatt, hogy a számítógép-tanúsítvány mellett importálódott-e a gyökértanúsítvány is! Ezután konfiguráljon fel egy VPN kapcsolatot az Új kapcsolat varázslóval (Hálózati kapcsolatok mappa). Vigyázat! A varázslóból való kilépés után további konfiguráció szükséges. Az újonnan létrehozott kapcsolat tulajdonságlapján állítsa be a Biztonság fülön a megfelelő értékeket (intelligens kártya, titkosítás megkövetelése, stb.). Helyes beállításoknál a kapcsolat azonnal felépíthető a kapcsolat ikonján történő dupla kattintással. Ha valami nem működik, akkor a szerver /var/log/daemon.log naplóállományából lehet informálódni a hiba hollétéről. 4.4.3. Kérdések 1. Figyelje meg az xl2tpd kimenetét. Milyen hasonlóságokat fedez fel a 4.3.1. fejezet alapján felkonfigurált hálózat kapcsolatfelépítési folyamatával? 2. Mik az IPSec alagút kiépülésének főbb lépései? 3. Hogyan konfigurálta az EAP-TLS-t a szerveren? Adja meg a konfigurációs állomány tartalmát! 4. Vizsgálja meg az átjáró naplóállományait abban az esetben is, ha a titkosítás elhagyását választja a kliensen a VPN kapcsolat tulajdonságlapján! Ilyenkor is felállnak az IPSec SA-k? 5. Beugró kérdések 1. Sorolja fel a PKI-alapú hitelesítés legalább két előnyét az osztott kulcsú hitelesítéssel szemben! 12

2. Ismertesse a 802.11i kulcshierarchiát! 3. Ismertesse a négyutas kézfogás lépéseit! 4. Milyen EAP üzenettípusokat ismer? Soroljon fel legalább kettőt! 5. Milyen EAP feletti hitelesítési protokollokat ismer? Milyen főbb vonásaiban különbözik az EAP- TLS protokoll ezekhez képest? 6. Mi a többtényezős hitelesítés lényege? Milyen, az egyszerű jelszónál összetettebb hitelesítési tényezőt ismer még a hardver tokeneken és intelligens kártyákon kívül? Nevezzen meg legalább egyet! 7. Mitől biztonságosabb a privát kulcsot egy tokenen tárolni mint a merevlemezen? Milyen szintű biztonságot lehet képes garantálni a token vagy az intelligens kártya a külső támadásokkal szemben? 8. Bíznia kell-e a tokennel rendelkező felhasználónak a tokent fogadó számítógépben? Miért? 9. Mikor lehet előnyösebb AP-szintű, és mikor VPN-szintű hitelesítést alkalmazni? 10. A CA milyen eszközökkel képes korlátozni a jogosulatlan(ná vált) felhasználóknak a hálózathoz való hozzáférését? Nevezzen meg legalább kettőt! 11. Milyen célra használható még egy token a hálózati hitelesítésen kívül? 12. Jelent biztonsági kockázatot a felhasználó vagy a VPN-alapú hitelesítést használó hálózat szempontjából az, ha a felhasználó csak az L2TP-alagutat építi fel, az IPSecet pedig nem? Miért? 13. Biztonsági kockázat-e, ha két kliens ugyanazt a számítógépszintű tanúsítványt használja? Miért? 13

6. Rövidítésjegyzék WLAN Wireless Local Area Network PKI Public Key Infrastructure CA Certificate Authority CRL Certificate Revocation List PKCS12 Public Key Cryptography Standards #12 PEM Privacy Enhanced Mail AP Access Point SSID Service Set Identification WPA WiFi/WLAN Protected Access PRF Pseudorandom Function PSK Pre-Shared Key MK Master Key PMK Pairwise Master Key PTK Pairwise Temporal Key KEK Key Encryption Key KCK Key Confirmation Key TK Temporal Key GTK Groupwise Temporal Key VPN Virtual Private Network AS Authentication Server IEEE Institute of Electrical and Electronics Engineers EAP Extensible Authentication Protocol TLS Transport Layer Security TTLS Tunnelled Transport Layer Security LEAP Lightweight Extensible Authentication Protocol PEAP Protected Extensible Authentication Protocol RADIUS Remote Access Dial In User Service L2TP Layer 2 Transport Protocol IPSec Internet Protocol Security SA Security Association EKU Extended Key Usage MMC Microsoft Management Console DHCP Dynamic Host Configuration Protocol TKIP Temporal Key Integrity Protocol CCMP Counter mode with Cipher block chaining Message authentication code Protocol SOHO Small Office, Home Office NAT Network Address Translation LNS L2TP Network Server 14

Hivatkozások [1] Ken Roser, HOWTO: EAP/TLS Setup for FreeRADIUS and Windows XP Supplicant, 2002. április 18. [2] http://support.microsoft.com/kb/240262 (How to configure an L2TP/IPSec connection by using Preshared Key Authentication, 2009. augusztus 12.) [3] http://www.jacco2.dds.nl/networking/win2000xp-openswan.html (Using a Linux L2TP/IPsec VPN server with Windows 2000/XP, 2009. augusztus 12.) [4] 802.11i, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Amendment 6: Medium Access Control (MAC) Security Enhancements, IEEE Standards, IEEE Computer Society, 2004. július 23. [5] http://www.nikhef.nl/ janjust/ppp/ (EAP-TLS patch for pppd, 2009. augusztus 24.) [6] http://ipsec-tools.sourceforge.net/ (IPSec Tools Homepage, 2009. augusztus 24.) [7] http://www.xelerance.com/software/xl2tpd/ (Xelerance - Xelerance: Software: xl2tpd, 2009. augusztus 24.) [8] http://hostap.epitest.fi/hostapd/ (hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator, 2009. augusztus 24.) [9] http://madwifi-project.org/ (madwifi-project.org - Trac, 2009. augusztus 24.) 15