Budapesti M˝uszaki é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˝oz˝o, Gulyás Gábor György E-mail:
[email protected] Köszönet illeti továbbá Paulik Tamást és Erd˝os Attilát, amiért épít˝o 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˝o” közeg azonban felvet egy sor biztonsági problémát: a hálózatban közleked˝o kereteket a megfelel˝o ismeretekkel rendelkez˝o 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˝o 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˝onye lehet a rugalmasabb hozzáférésszabályozás (lásd a 2.3. fejezetet) vagy a viszonykulcsegyeztetés lehet˝osé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˝o 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˝uköd˝o VPN-átjárón (2.2. fejezet) hitelesíti magát.1 Az els˝o koncepció el˝onye, hogy egyszer˝u, míg a másodikkal természetszer˝uleg szétválaszthatjuk hálózatunkat mindenki számára hozzáférhet˝o és korlátozott hozzáférés˝u 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˝u 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˝oközönkénti cseréje, ami ellehetetleníti a lexikonépít˝o és egyéb, a hálózati forgalmat lehallgató, majd a kulcsot visszafejt˝o támadási lehet˝oségeket. A kulcshierarchiát az 1. ábra mutatja be. A mesterkulcs (Master Key, MK) a legfels˝o titok, melyet mind a kliensnek, mind pedig a hitelesítést végz˝o eszköznek ismernie kell. A páronkénti mesterkulcsot (Pairwise Master Key, PMK) a mobil állomás és a hitelesít˝o szerver minden egyes bejelentkezésnél a mesterkulcsból generálja2 . A hitelesít˝o szerver ezt a kulcsot elküldi a klienssel kapcsolatban lev˝o AP-nak, melyb˝ol ez utóbbi két fél majd a négyutas kézfogás nev˝u 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˝o 16 bájtja a kulcsmeger˝osít˝o kulcs (Key Confirmation Key, KCK), melynek célja, hogy az AP és a kliens kölcsönösen meggy˝oz˝odhessen 1 2
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˝o. 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˝o 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˝u „biankó” hitelesítési protokollon alapszik. Ennek lényege, hogy a csatlakozó kliens el˝oször csak egy hitelesít˝o 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˝o benne a PKI (2.3. fejezet) támogatása. EAP-TTLS esetén a kliensnek nem kötelez˝o 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 EAPRequest 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˝ol 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˝u 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˝u folyamat zajlik le (2. ábra).
Mobil állomás
AP MK-ból generálja, vagy a hitelesítési szerver küldi el
Csatlakozási kérés
PMK
PMK R1
PTK = PRF(PMK, R1, R2, MAC1, MAC2)
PTK R2, MIC
PTK „Használd a TK-t!”, MIC OK, MIC
2. ábra. A négyutas kézfogás Az eljárás részletei a következ˝ok: 1. Az AP elküldi az általa generált véletlen számot (R1 ) a mobil állomásnak. 2. Az MS generál egy másik véletlen számot (R2 ). Ezután a PMK, R1 , R2 , 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˝ol, melyben megkapja az R2 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 R1 -et. 4. A negyedik kézfogási lépés egy egyszer˝u nyugta (MS → AP). Megjegyzend˝o, hogy az els˝o 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˝o részében tehát egy egyszer˝u PC-t kell AP-ként konfigurálni, EAP-TLS hitelesítéssel. A hitelesít˝o kiszolgáló és a hozzáférési pont ugyanazon a hardveren fog futni, azonban megjegyzend˝o, 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˝o személyek vagy szervezetek számára kontrollálhatatlan és megbízhtatalan közbens˝o hálózatszakaszok felett. Az összekötend˝o 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˝os rejtjelezéssel és integritásellen˝orzéssel védett. Az ún. hozzáférési VPN-ek annyival egyszer˝ubbek, 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˝osen dinamikus felépítés˝u. 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˝o hálózatot. Az IPSec hálózati rétegbeli protokoll többek közt megvalósítja a rejtjelezést és az integritáselleno˝ rzést a biztonsági hozzárendelések (Security Association, SA) segítségével3 , míg az L2TP szerepe az IPSec csomagok beágyazására és az átjáróhoz történ˝o transzparens, alagút típusú átvitelére korlátozódik4 . 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˝ukö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˝u: a Windowsba épített kliens csak L2TP-vel együtt kezeli az IPSec-et a mérés el˝okészítésének pillanatában fellelhet˝o egyéb kliensek pedig vagy fizet˝osen, 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˝u, 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˝oség. A mérés során érdemes lehet külön konfigurálni az L2TP-t, és ha az már stabilan m˝uködik, akkor rátérni az IPSecre – így sokat egyszer˝usödik a hibakeresés. A Windows csak akkor tekint el az IPSec SA-k felépítését˝ol, ha el˝otte egy rendszerleíróadatbázis-kulcsot5 módosítunk/létrehozunk. A mez˝o 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˝uen 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˝ojének meg kell bíznia. Ha ez teljesül, akkor egy tanúsítványról az infrastruktúra egyéb szerepl˝oi 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 o˝ 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. 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 4
5
ilyenkor a külvilág számára ez a CA megbízhatatlan lesz, a mérés során azonban teljesen elegend˝o, 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˝o is szabályozhatja. Egyrészt mindegyik csak egy meghatározott id˝opontig érvényes, másrészt lehet˝oség van egy tanúsítványt már a lejárat el˝ott is visszavonni. Ez utóbbi módszer m˝uködhet on-line vagy off-line módon. El˝obbire példa az Online Certificate Status Protocol (ez egy tanúsítványellen˝orz˝o 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˝oszakos 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˝os 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˝uveletvé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˝u 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˝ol 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˝o operációk kiszámításához, és a gazda rendszer (a tokent fogadó számítógép) csak az eredményr˝ol értesül. Végeredményben tehát így biztosítható, hogy a hitelesítés csak mindkét tényez˝o (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˝o. Az eToken PRO ún. tamper evident eszköz, vagyis a vele való manipuláció könnyen észrevehet˝o (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˝o hardvereszközökb˝ol á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˝ojét, ha az antenna kilóg a kártya testéb˝ol. É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˝u 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˝o 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˝u, a tinyca2 paranccsal indítható alkalmazást, mely voltaképpen az OpenSSL nev˝u 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˝o szerepl˝oinek (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˝ott a CA tanúsítvány legenerálásra kerül, ellen˝orizni kell a rendszerid˝o 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˝o indításkor felajánlja egy CA inicializálását. A feldobott panel mez˝oit értelemszer˝uen kitöltve generálhat egy önaláírt CA tanúsítványt (a paraméterek tetsz˝olegesek). 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˝o értéke 1.3.6.1.5.5.7.3.1. Ezt csak akkor tudjuk megadni, ha el˝ozetesen 7
kiválasztja a megfelel˝o 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˝onyei é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˝o bal oldalán lev˝o 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˝obbi az AP-funkcionalitást valósítja meg, míg utóbbi egy meglehet˝osen leegyszer˝usí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˝oség le van írva a kommentezett sorokban. (A fájl szerkesztéséhez ajánlott a nano szövegszerkeszt˝o 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 interface driver hw_mode channel debug ssid auth_algs ieee8021x eap_server ca_cert server_cert private_key private_key_passwd wpa_key_mgmt wpa_pairwise eap_user_file
Funkció A vezeték nélküli hálózati interfész neve. Az interfész meghajtóprogramja. Értéke madwifi. Az interfészre beállítandó 802.11 szabvány. Értéke g. A rádiós csatorna száma. Értéke 1 és 13 közt tetsz˝oleges. A program által kiírt információ mennyisége. Ajánlott értéke 4. A beállítani kívánt SSID. A felhasznált hitelesítési séma. Értéke 3. 802.1x engedélyezése. Értéke 1. Bels˝o RADIUS szerver engedélyezése. Értéke 1. A CA tanúsítványának elérési útja. A szerver tanúsítványának elérési útja. A szerver privát kulcsának elérési útja. A privát kulcsot véd˝o jelszó. Az alkalmazott kulcsmenedzsment módszer. Értéke WPA-EAP. A rejtjelezési protokoll. Értéke TKIP. 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˝o RADIUS szerver használata azért el˝onyös, mert így nem szükséges küls˝o 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˝obb 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˝o 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˝orizheti az interfész sikeres létrejöttét. Ha mindez megvan, akkor gy˝oz˝odjö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˝o, 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˝orizze 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˝oen a madwifi hibájának köszönhet˝oen id˝onké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˝oz˝oleg 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˝obeszéd˝unek, ezért segítségül egy kitölthet˝o 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˝ore, melynek értéke vezeték nélküli kliensek esetén kötelez˝oen 1.3.6.1.5.5.7.3.2. Vigyázat! Az EKU mez˝ore 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 tokenre6 . 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˝o 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˝oz˝oekben 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˝o 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˝o hálózathoz, például az Internethez. Ennek egyik legegyszer˝ubb 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˝ur˝o t˝uzfal egyszer˝uen konfigurálható a következ˝o 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˝obb lépéseket fedez fel? 3. Milyen el˝onyei lehetnek egy küls˝o RADIUS szervernek a hostapd-be építettel szemben? 4. Milyen el˝onyei é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˝obbi az L2TP, utóbbi az IPSec protokollt valósítja meg7 . 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˝o. 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˝oen 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˝o 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˝o interfészeken keresztül látszanak a kliensek (ppp0, ppp1, . . . ), ellentétben az AP-szint˝u hitelesítéssel, melynél egyetlen athX interfészt kellett kikötni a küls˝o 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˝u 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˝u 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˝o modult kell hozzáadni (Fájl menü → Beépül˝o modul hozzáadása/eltávolítása...). A felugró panelen (6. ábra) a Tanúsítvány beépül˝ot 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˝o 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˝o hozzáadására, ezért az OK gommbal lépjen vissza az MMC-f˝oablakba. 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˝o exportálás a TinyCA-jel könnyedén elvégezhet˝o (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˝u 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˝u 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˝o
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˝orizze a Megbízható legfels˝o szint˝u 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˝o értékeket (intelligens kártya, titkosítás megkövetelése, stb.). Helyes beállításoknál a kapcsolat azonnal felépíthet˝o a kapcsolat ikonján történ˝o dupla kattintással. Ha valami nem m˝uködik, akkor a szerver /var/log/daemon.log naplóállományából lehet informálódni a hiba hollétér˝ol. 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˝obb 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˝onyé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˝ot! 5. Milyen EAP feletti hitelesítési protokollokat ismer? Milyen f˝obb vonásaiban különbözik az EAPTLS protokoll ezekhez képest? 6. Mi a többtényez˝os hitelesítés lényege? Milyen, az egyszer˝u jelszónál összetettebb hitelesítési „tényez˝ot” ismer még a hardver tokeneken és intelligens kártyákon kívül? Nevezzen meg legalább egyet! 7. Mit˝ol biztonságosabb a privát kulcsot egy tokenen tárolni mint a merevlemezen? Milyen szint˝u biztonságot lehet képes garantálni a token vagy az intelligens kártya a küls˝o támadásokkal szemben? 8. Bíznia kell-e a tokennel rendelkez˝o felhasználónak a tokent fogadó számítógépben? Miért? 9. Mikor lehet el˝onyösebb AP-szint˝u, és mikor VPN-szint˝u 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˝ot! 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˝u tanúsítványt használja? Miért?
13
6. Rövidítésjegyzék WLAN PKI CA CRL PKCS12 PEM AP SSID WPA PRF PSK MK PMK PTK KEK KCK TK GTK VPN AS IEEE EAP TLS TTLS LEAP PEAP RADIUS L2TP IPSec SA EKU MMC DHCP TKIP CCMP SOHO NAT LNS
Wireless Local Area Network Public Key Infrastructure Certificate Authority Certificate Revocation List Public Key Cryptography Standards #12 Privacy Enhanced Mail Access Point Service Set Identification WiFi/WLAN Protected Access Pseudorandom Function Pre-Shared Key Master Key Pairwise Master Key Pairwise Temporal Key Key Encryption Key Key Confirmation Key Temporal Key Groupwise Temporal Key Virtual Private Network Authentication Server Institute of Electrical and Electronics Engineers Extensible Authentication Protocol Transport Layer Security Tunnelled Transport Layer Security Lightweight Extensible Authentication Protocol Protected Extensible Authentication Protocol Remote Access Dial In User Service Layer 2 Transport Protocol Internet Protocol Security Security Association Extended Key Usage Microsoft Management Console Dynamic Host Configuration Protocol Temporal Key Integrity Protocol Counter mode with Cipher block chaining Message authentication code Protocol Small Office, Home Office Network Address Translation 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 802.1X/WPA/WPA2/EAP/RADIUS Authenticator, 2009. augusztus 24.) [9] http://madwifi-project.org/ (madwifi-project.org - Trac, 2009. augusztus 24.)
15
AP,
IEEE
