Csatlakoztasson egy zárt Wi-Fi hálózatot a Mas-cím engedélyével két tp-link tl-wr842nd ponton alapulóan

Végezze el a kiválasztott módszer beállítását.

RADIUSPicking Auth-TypeAuthenticating

Itt van a cikkem ingyenes fordítása, nem tudom garantálni a megbízhatóságot.

És csak abban az esetben szinkronizálom a feltételeket:

Az ügyfél ezzel összefüggésben (a RADIUS szerver szempontjából) hozzáférési pont.

A felhasználó (felszólító) az, aki hozzáférési ponttal akar hozzáférni a hálózathoz.

A legtöbb konfigurációs probléma a FreeRADIUS koncepció hiányának tudható be. A konfigurációs fájlok szerkesztése és a lehetséges beállítások rendezése nem segít a fogalom megértésében.

Sem Ön, sem a sugár nem ismeri, és eldönti, hogy az ügyfél elküldi-e a kérésben. A kérelemben szereplő adatokért az ügyfél felelőssége 100%.

A radiusz kiszolgáló a lekérdezést vizsgálja és azt mondja:

A kérdésre adott válasz attól függ, hogy milyen típusú hitelesítést tartalmaz, mit keres a kiszolgáló az adatbázisban, és mi szerepel a lekérdezésben.

Egyik pillanatban az egyik modul mondja:

Ha a modul úgy gondolja, hogy van esélye a felhasználó hitelesítésére, akkor azt fogja mondani:

Ha a modul nem ismeri fel semmit, vagy tudja, hogy nincs szükség valamire, akkor egyszerűen nem tesz semmit.

Tegyük fel, hogy az ügyfél kérelmet küldött a User-Password attribútummal, és a pap-modul szerepel az autorize szakaszban <>. Ezután a pap modul az Auth-Type = pap értéket állítja be.

Így a kiszolgáló újra hozzáfér a pap-modulhoz, de a hitelesítési fázisban (ez szintén saját szakaszát tartalmazza a hitelesítőben <> ), pap válaszol:

Tehát összehasonlítjuk a helyileg ismert, helyes jelszót, amelyet a felhasználó beírt (a kérelemben szerepelt). Így működik a hitelesítés.

A "helyes" jelszót (az ismert jelszó előre ismert volt) egy másik modul hozzáadásával egészítette ki. Például a pap modul egyszerűen elvégzi a PAP hitelesítést és semmit. Ennek a megközelítésnek az előnyei, hogy a "helyes" jelszót fel lehet adni a lekérdezéshez a szövegfájl felhasználói számára. SQL. LDAP. / etc / passwd. külső program stb. és hasonlók. nagyon széles tartományban.

Például, ha az engedélyezési szakaszban egy LDAP modul csatlakozik <>. és a kiszolgáló feldolgozza a kérést, ha a modul jelszóbejegyzést talál (valahol az LDAP könyvtárban), akkor ezt a jelszót a kéréshez hozzáadja, hogy a másik modul a hitelesítési szakaszban használhassa azt.

Mi van akkor, ha az ügyfél MSCHAP kérést küld? Mit fog a radiusz szerver ehhez a kéréshez?

De a kiszolgáló már kimerítette az opciókat, az egyetlen lehetőség az mschap volt, mivel az ügyfél ezt a kérést elküldte. A Mschap modul nem tudott semmit tenni, mert nem kapta meg a "helyes" jelszót. Így a szerver elutasítja az opciók hiányára vonatkozó kérelmet. Az MSCHAP adatok helyesek lehetnek, de a kiszolgálónak nem volt módja annak igazolására. Ezért nem volt hajlandó.

A FreeRADIUS moduláris alapon szerveződik. Annak érdekében, hogy a FreeRADIUS támogassa egy adott protokollt, engedélyeznie kell / letiltnia a modult a konfigurációban. Sok, ha nem minden modul rendelkezik saját konfigurációs részével az általános konfigurációban.

A hitelesítési módszerek a hitelesítési szakaszban vannak beállítva <>. Itt a kérés a modulhoz tartozik, amely az Auth-Type attribútumban van megadva. A tárolómodul lekérdezésébe beillesztett adatok alapján, még az előző szakaszban is, összehasonlítjuk az ügyfélről származó attribútumokat a repository attribútumaival. Ezen összehasonlítás alapján már hoztak döntést a hozzáférés engedélyezésére vagy megtagadására, illetve az ügyfél paramétereinek finomítására.

Itt van egy koncepció a radiusz szerver számára, ebben az esetben egyszerűvé válik a szégyen.

A meglévő TP-Link TL-WR842ND vezeték nélküli routerek gyárilag a firmware segítségével képesek vagyunk a következő típusú védelmi eszközök használatára: WPA2-PSK, WPA2-Enterprise. A fennmaradó opciókat nem vették figyelembe azok irrelevánssága miatt: egy nyílt hálózat nem felel meg a célnak; WEP - régóta veszélybe került; WPA-PSK / Enterprise - a WPA2 a titkosítás szigorúbb megközelítése.

A WPA2-Enterprise számos EAP hitelesítési módot támogat. Az EAP-TLS és az EAP-PEAPv0 relevánsak az ablakban. EAP-TLS - enyhíti a felhasználót a bevezetése a bejelentkezési név és jelszó, de van egy másik probléma merül fel a telepítési nyilvános kulcsú infrastruktúra és elosztási tanúsítványok. És probléma lesz a tanúsítványok telepítése mobileszközökön. Bár ez a módszer a legmegbízhatóbb, hanem azért, mert a bonyolult telepítési és támogatási igényeinknek, akkor eltűnik.

EAP-PEAPv0 MS-CHAPv2-vel - a felhasználónak megbízhatónak kell lennie a hozzáférési ponton / kiszolgálón és a login / password linken. A hozzáférési pont / kiszolgáló bizalmát a szerver által bemutatott tanúsítvány ellenőrzése vagy az ellenőrzés letiltása érheti el. A módszer abban áll, ami egy biztonságos csatornát, amelyen belül a felhasználói hitelesítés MS-CHAPv2 módszerrel. Egyszerű telepítés és karbantartás, különösen, ha vakon bízik a hozzáférési ponton / szerveren. De az "aktív" betolakodók biztonsága szenved.

Meg kell jegyezni, hogy ezeket a parancsokat és konfigurációs töredékeket a Debian 7.5 verzióban tesztelték a FreeRADIUS 2.1.12 + dfsg-1.2 verzióval

2.1 Gyártási tanúsítványok létrehozása

Mivel a legtöbb WPA2 módszer legalább tanúsítványt és magánkulcsot igényel a kiszolgálón, létre kell hoznia. Saját aláírással ellátott tanúsítvány létrehozásához szükségünk van egy saját tanúsító központ tanúsítványára és saját kulcsára, amelyet szintén meg kell alkotnunk.

A szükséges freeradius tanúsítványok létrehozása a Debianból az / usr / share / doc / freeradius / examples / certs könyvtárban található. A könyvtár tartalmát át kell másolni az / etc / freeradius / certs könyvtárba. Szükséges fájlok:

És azt is másolni a README, ami festett, mint amire szüksége van, és hogyan kell használni, így tovább menni a szükséges parancsok rövid magyarázattal, több infoy a README.

A parancsfájlok futtatásához openssl és make szükséges.

Hozzon létre egy fájlt a Diffie-Hellman paraméterekkel, ha hirtelen hiányzik az / etc / freeradius / certs könyvtárban:

A munka eredménye: fájl dh

Hozzunk létre egy gyökérigazolást vagy tanúsító központ tanúsítványát. Ha korábban már volt néhány tanúsítvány (általában teszt), akkor töröljük:

Szerkesszük a ca.cnf fájlt. Megjegyzés: a default_md = md5 (jobb, hogy sha1) default_days = 365 (lehet, hogy nem kíván generálni új tanúsítvány egy év alatt, akkor jobb, hogy egy kicsit több), input_password / output_password és szerkeszteni kívánt alatta az egész szakasz [CERTIFICATE_AUTHORITY].

A munka eredményei: ca.pem. ca.key és ca.der - a tanúsító központ tanúsítványa, privát kulcsa és a tanúsítvány Windows rendszerben érthető formátumban.

Hozzon létre egy szerver tanúsítványt. A server.cnf fájlt az Ön számára szerkesztjük. Megjegyzés: a default_md = md5 (jobb, hogy sha1) default_days = 365 (lehet, hogy nem kíván generálni új tanúsítvány egy év alatt, akkor jobb, hogy egy kicsit több), input_password / output_password és szerkeszteni kívánt alatta az egész szakasz [szerver]. Fontos, hogy értékeljük commonName különböznek a megfelelő igazolással központ.

A munka eredménye: a server.pem és a server.key fájlok között a szerver tanúsítványa és privát kulcsa.

Az / etc / freeradius / certs mappában létrehozott tanúsítványok elérési útjának konfigurációjában alapértelmezés szerint regisztrálják.

2.2 RADIUS-ügyfelek (hozzáférési pontok) leírása

Adja hozzá az alábbiakat a /etc/freeradius/clietns.conf fájlhoz:

2.3 A hitelesítő adatokat a bejelentkezés és a jelszó segítségével állítottuk be

A / etc / freeradius / users fájlban a következő tartalom első sorát adjuk hozzá:

A felhasználónév felhasználójának lekérdezéséhez a jelszó ellenőrzése megtörténik, és összehasonlítjuk a hívóállomás-azonosító attribútumot. Ehhez a munkához esetében EAP-PEAP kell /etc/freeradius/eap.conf fájl beállítása sopy_request_to_tunnel = yes az alábbi részben:

Elég, ha a felhasználókat a felhasználók számára a kezdet kezdetén hozzáadják a Calling-Station-Id paraméterrel. ha a hitelesítő adatok megegyeznek, egyszerűen megismételheti őket, például:

Meg kell jegyezni, hogy a felhasználó fájlban megadott bizonyos hívószám-azonosító attribútum egy bizonyos bejelentkezési / jelszópár esetében is működni fog, de a későbbi időpontban ellenőrizni fogja. Tehát ha egy hívás felmerül a Calling-Station-Id értékével. az engedélyezett_macs fájlban nem szerepel, ez a kérés azonnal elutasításra kerül, függetlenül attól, hogy mit tartalmaz a felhasználói fájl.

Ha módosítja a konfigurációs fájlokat, beleértve a felhasználókat és az authorized_macs fájlokat, akkor kényszeríteni kell a konfigurációt, hogy újra olvassa a SIGHUP jelet.

Ha megváltoztatja a radiusd.conf konfigurációját, akkor jobb, ha újraindítja a démont:

A konfiguráció teszteléséhez futtassa a démont hibakeresési módban:

Ezzel az indítással láthatja, hogy a freeradius értelmezte-e a konfigurációt, és hogyan kezeli a kéréseket. Sokat segít abban, hogy különböző problémákat keressen, vagy ha a váratlan viselkedés elmagyarázza.

A készlet hasznos segédprogramot kínál - egy egyszerű RADIUS-kliens. Ezzel egyszerűen elvégezheti a konfiguráció ellenőrzését. Lehetséges használati példa (intranetes hitelesítés a 18120-as porton keresztül):

A naplók azonosítási kísérleteire vonatkozó információk megjelenítéséhez a következő paramétereket kell beírni a radiusd.conf fájlba.