Már említettek néhány példát a vállalati WiFi megszervezésére. Itt kifejtem, hogyan valósítottam meg egy hasonló megoldást és azokat a problémákat, amelyekkel különböző eszközök csatlakoztatása során szembesültem. Az előre létrehozott LDAP felhasználókat fogjuk használni, felállítjuk a FreeRadiusot, és beállítjuk a WPA2-Enterprise-t az Ubnt vezérlőn. Úgy tűnik, minden egyszerű. Lássuk...
EAP módszerekről egy kicsit
Mielőtt elkezdenénk a feladat végrehajtását, meg kell határoznunk, hogy milyen hitelesítési módszert fogunk használni a megoldásunkban.
A Wikipédiából:
Az EAP egy hitelesítési keretrendszer, amelyet gyakran használnak vezeték nélküli hálózatokban és pont-pont kapcsolatokban. A formátumot először az RFC 3748-ban írták le, majd az RFC 5247-ben frissítették.
Az EAP a hitelesítési módszer kiválasztására, a kulcsok átadására és ezen kulcsok kezelésére szolgáló EAP módszereknek nevezett csatlakozó modulokkal való együttműködésre használatos. Számos EAP módszer létezik, amelyeket vagy magával az EAP-val együtt határoztak meg, vagy külön gyártók adtak ki. Az EAP nem határozza meg a csatorna szintet; csupán az üzenetek formátumát határozza meg. Minden olyan protokoll, amely az EAP-t használja, saját EAP üzenetencapsulációs protokollal rendelkezik.
A módszerek:
- LEAP — egy proprietárius protokoll, amelyet a CISCO fejlesztett ki. Sebezhetőségeket találtak. Jelenleg nem ajánlott a használata
- EAP-TLS — a vezeték nélküli kapcsolatok szállítói körében jól támogatott. Biztonságos protokoll, mivel az SSL szabványok örököse. Az ügyfélszintű beállítás meglehetősen bonyolult. Az ügyféltanúsítvány mellett jelszóra van szükség. Sok rendszer támogatja.
- EAP-TTLS — széles körben támogatott számos rendszerben, jó biztonságot kínálva, a PKI tanúsítványokat csak a hitelesítési kiszolgálón használva.
- EAP-MD5 — egy másik nyílt szabvány. Minimális biztonságot kínál. Sebezhető, nem támogatja a kölcsönös hitelesítést és a kulcsgenerálást.
- EAP-IKEv2 — az Internet Key Exchange Protocol version 2-n alapul. Kölcsönös hitelesítést és munkameneti kulcs létrehozását biztosít az ügyfél és a szerver között.
- PEAP — a CISCO, a Microsoft és az RSA Security közös megoldása, mint nyílt szabvány. Széles körben elérhető termékekben, nagyon jó biztonságot nyújt. Hasonló az EAP-TTLS-hez, csak a szerveroldali tanúsítványt igényli.
- PEAPv0/EAP-MSCHAPv2 — az EAP-TLS után a második legelterjedtebb szabvány a világon. Ügyfél-szerver kapcsolatot használ a Microsoft, Cisco, Apple, Linux rendszerekben.
- PEAPv1/EAP-GTC — a Cisco által kifejlesztett alternatíva a PEAPv0/EAP-MSCHAPv2-nek. Egyáltalán nem védi az autentikációs adatokat. Nem támogatják a Windows OS-t.
- EAP-FAST — a Cisco által kifejlesztett módszer, amely a LEAP hiányosságait hivatott orvosolni. A Protected Access Credential (PAC) használatával működik. Teljesen nem kidolgozott.
E sokféleség közül a választék mégis korlátozott. Az autentikációs módszerrel szemben elvárás volt: jó biztonság, támogatás minden eszközön (Windows 10, macOS, Linux, Android, iOS) és persze, minél egyszerűbb, annál jobb. Ezért az EAP-TTLS mellett döntöttünk a PAP protokollal kombinálva.
Felmerülhet a kérdés — miért is használjunk PAP-ot? Hiszen a jelszavakat nyílt szövegként továbbítja?
Igen, ez teljesen igaz. A FreeRadius és a FreeIPA közötti kommunikáció pontosan így fog történni. Debug üzemmódban követhetjük, hogyan küldődnek el a felhasználónév és a jelszó. De hát, ha már itt tartunk, csak Önnek van hozzáférése a FreeRadius szerverhez.
További információkat olvashat az EAP-TTLS működéséről.
FreeRADIUS
A FreeRadius-t CentOS 7.6 rendszerre telepítjük. Itt semmi bonyolult nincs, a megszokott módon telepítjük.
yum install freeradius freeradius-utils freeradius-ldap -yA csomagokból a 3.0.13-as verzió települ. A legújabbat innen szerezheti be.
Ezután a FreeRadius már működik. A /etc/raddb/users mappában kommentelheti a következő sort:
steve Cleartext-Password := "testing"Futtassa a szervert debug módban.
freeradius -XÉs végezzünk el egy tesztkapcsolatot a localhost-tal.
radtest steve testing 127.0.0.1 1812 testing123Megkaptuk a választ. Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, tehát minden rendben van. Folytassuk.
Bekapcsoljuk a modult. ldap.
A tartalmát a következőképpen alakítom át:És azonnal módosítjuk. Szükségünk van arra, hogy a FreeRadius hozzáférhessen a FreeIPA-hoz.
mods-enabled/ldap
ldap {
server="ldap://ldap.server.com"
port=636
start_tls=yes
identity="uid=admin,cn=users,dc=server,dc=com"
password=**********
base_dn="cn=users,dc=server,dc=com"
set_auth_type=yes
...
user {
base_dn="${..base_dn}"
filter="(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
}
...Újraindítjuk a radius szervert, és ellenőrizzük az LDAP felhasználók szinkronizálását:
radtest user_ldap password_ldap localhost 1812 testing123 Szerkesztjük az eap-t a mods-enabled/eap
Itt két EAP példányt adunk hozzá. Ezek csak a tanúsítványokban és kulcsokban fognak eltérni. Kicsit később elmagyarázom, miért éppen így.
mods-enabled/eap
eap eap-client { default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_file = ${certdir}/fisrt.key
certificate_file = ${certdir}/first.crt
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}
eap eap-guest {
default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests}
tls-config tls-common {
private_key_passwotd=blablabla
private_key_file = ${certdir}/server.key
certificate_file = ${certdir}/server.crt
dh_file = ${certdir}/dh
ca_path = ${cadir}
cipher_list = "HIGH"
cipher_server_preference = no
ecdh_curve = "prime256v1"
check_crl = no
}
ttls {
tls = tls-common
default_eap_type = md5
copy_request_to_tunnel = no
use_tunneled_reply = yes
virtual_server = "inner-tunnel"
}
}Ezután szerkesztjük site-enabled/default. Az authorize és authenticate szakaszok érdekelnek.
site-enabled/default
authorize {
filter_username
preprocess
if (&User-Name == "guest") {
eap-guest {
ok = return
}
}
elsif (&User-Name == "client") {
eap-client {
ok = return
}
}
else {
eap-guest {
ok = return
}
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
logintime
pap
}
authenticate {
Auth-Type LDAP {
ldap
}
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
pap
}Az authorize szakaszban eltávolítjuk az összes felesleges modult. Csak az ldap-t hagyjuk meg. Hozzáadjuk a kliens ellenőrzését a felhasználónév alapján. Pontosan ezért adtunk hozzá két példányt az eap-hoz korábban.
Több EAPAz a helyzet, hogy bizonyos eszközök csatlakoztatásakor rendszerszintű tanúsítványokat fogunk használni, és megadjuk a domaint. Van egy tanúsítványunk és kulcsunk egy megbízható tanúsítóhatóságtól. Szerintem ez a csatlakozási eljárás egyszerűbb, mint minden eszközre önaláírt tanúsítványt alkalmazni. De önaláírt tanúsítványok nélkül sem sikerült megkerülni a problémát. A Samsung eszközök és az Android < 6 verzió nem tudják használni a rendszerszintű tanúsítványokat. Ezért számukra létrehozunk egy külön eap-guest példányt önaláírt tanúsítványokkal. Minden más eszközhöz az eap-client-t fogjuk használni megbízható tanúsítvánnyal. A User-Name az eszköz csatlakoztatásakor az Anonymous mezőből kerül meghatározásra. Csak 3 értéket lehet használni: Guest, Client és üres mező. Minden más elutasításra kerül. Ez a politikákban van beállítva. Példát kicsit később hozok.
Szerkeszteni fogjuk az authorize és authenticate szakaszokat a site-enabled/inner-tunnel
site-enabled/inner-tunnel
authorize {
filter_username
filter_inner_identity
update control {
&Proxy-To-Realm := LOCAL
}
ldap
if ((ok || updated) && User-Password) {
update {
control:Auth-Type := ldap
}
}
expiration
digest
logintime
pap
}
authenticate {
Auth-Type eap-guest {
eap-guest
}
Auth-Type eap-client {
eap-client
}
Auth-Type PAP {
pap
}
ldap
}Ezután meg kell határoznunk a politikákban, hogy milyen neveket lehet használni az anonim bejelentkezéshez. Szerkesztjük a policy.d/filter.
Meg kell találni hasonló sorokat ehhez:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}És alatta, az elsif ágba hozzáadni a szükséges értékeket:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Most át kell lépnünk a könyvtárba certs. Ide kell elhelyezni a megbízható tanúsítóhatóságtól származó kulcsot és tanúsítványt, amely már megvan, és generálni kell az önaláírt tanúsítványokat az eap-guest számára.
A fájl paramétereit módosítjuk ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = HU
stateOrProvinceNmae = Megye
localityNmae = Város
organizationName = NÉV NÉLKÜL
emailAddress = admin@admin.hu
commonName = "CA FreeRadius"Ugyanazokat az értékeket írjuk be a fájlba server.cnf. Csak azt változtatjuk
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = HU
stateOrProvinceNmae = Megye
localityNmae = Város
organizationName = NÉV NÉLKÜL
emailAddress = admin@admin.hu
commonName = "Server Certificate FreeRadius"Létrehozás:
makeKész. A kapott server.crt és server.key már fentebb szerepelnek az eap-guest fájlban.
És végül, hozzáadjuk a hozzáférési pontjainkat a fájlhoz client.conf. Nekem 7 van. Hogy ne kelljen minden egyes pontot külön hozzáadni, csak a hálózatot írjuk be, amelyben találhatók (nekem a hozzáférési pontok egy külön VLAN-ban vannak).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Ubiquiti vezérlő
A vezérlőn létrehozunk egy külön hálózatot. Legyen 192.168.2.0/24
Menjünk a beállításokhoz -> profil. Készítsünk egy újat:
Írjuk be a radius-szerver címét és portját, valamint a fájlban megadott jelszót clients.conf:
Készítsünk új vezeték nélküli hálózatnevet. Az azonosítási módszernek a WPA-EAP (Enterprise) megoldást választjuk, és megadjuk a létrehozott radius-profilt:
Mindent elmentünk, alkalmazzuk, és lépünk tovább.
Kliensek beállítása
Kezdjük a legnehezebbel!
Windows 10
A nehézség abban rejlik, hogy a Windows még nem tud csatlakozni a vállalati WiFi-hez domain alapján. Ezért manuálisan kell importálni a tanúsítványunkat a megbízható tanúsítványok tárolójába. Itt használhatunk önaláírt vagy a hitelesítésszolgáltatótól származó tanúsítványt. Én a másodikat fogom használni.
Ezután létre kell hozni egy új kapcsolatot. Ehhez menjünk a Hálózati és Internet beállításokhoz -> Hálózatok és megosztás központja -> Új kapcsolat vagy hálózat létrehozása és beállítása:
Kézzel beírjuk a hálózat nevét, és megváltoztatjuk a biztonsági típust. Ezután kattintunk a kapcsolati beállítások módosítása fülre, a Biztonság részen kiválasztjuk a hálózat hitelesítésének módját — EAP-TTLS.
Lépjünk be a beállításokba, állítsuk be az azonosítási titkosságot — client. Mint megbízható hitelesítési központ, választjuk a korábban hozzáadott tanúsítványt, bepipáljuk a "Ne kérjük a felhasználót, ha a szerver hitelesítése nem sikerül" lehetőséget, és az azonosítási módszernek a titkosítatlan jelszót (PAP) választjuk.
Ezután lépjünk be a további beállításokba, és pipáljuk be a „Adja meg a hitelesítési módot” lehetőséget. Válassza a „Felhasználó hitelesítése” pontot, majd kattintson a jelszavak mentésére. Itt meg kell adni a username_ldap és password_ldap adatokat.
Mindent mentünk, alkalmazzuk, majd bezárjuk. Most már csatlakozhatunk az új hálózathoz.
Linux
Ubuntu 18.04, 18.10, Fedora 29, 30 alatt ellenőriztem.
Először töltsük le a tanúsítványt. Nem találtam Linuxban lehetőséget a rendszer tanúsítványainak használatára, és hogy egyáltalán létezik-e ilyen tároló.
Domain alapján fogunk csatlakozni. Ezért szükség van arra a tanúsítványra, amelyből a tanúsítványunkat megszereztük.
Az összes csatlakozás egy ablakban történik. Válasszuk ki a hálózatunkat:
anonymous — kliens
domain — a tanúsítványra kiállított domain
Android
non-Samsung
A 7-es verziótól a WiFi csatlakozásához használhatjuk a rendszer tanúsítványait, csak a domaint kell megadnunk:
domain — a tanúsítványra kiállított domain
anonymous — kliens
Samsung
Ahogy már említettem, a Samsung-eszközök nem tudják használni a rendszer tanúsítványait a WiFi csatlakozáskor, és nincs lehetőségük domainen való kapcsolódásra. Ezért kézzel kell hozzáadni a gyökér tanúsítványt (ca.pem), amit a Radius szerveren kapunk. Itt önaláírt változatot használ.
Töltsük le a tanúsítványt a készülékünkre és telepítsük azt.
A tanúsítvány telepítése
Ehhez be kell állítani a képernyő feloldásához szükséges mintát, PIN-kódot vagy jelszót, ha még nincs beállítva:
A tanúsítvány telepítési folyamatát mutattam be, a legtöbb eszközön elegendő, ha csak rákattintunk a letöltött tanúsítványra.
Miután a tanúsítványt telepítettük, áttérhetünk a csatlakozásra:
tanúsítvány — megadjuk azt, amelyiket telepítettük
anonim felhasználó — vendég
macOS
Az Apple eszközök alapból csak az EAP-TLS-hez tudnak csatlakozni, de a tanúsítványt nekik is át kell adni. Másik csatlakozási módszer megadásához az Apple Configurator 2-t kell használni. Ennek megfelelően előzetesen le kell tölteni a Mac-re, új profilt létrehozni, és hozzáadni minden szükséges WiFi beállítást.
Apple Configurator
Itt adjuk meg a hálózatunk nevét
Biztonsági típus — WPA2 Enterprise
Elfogadott EAP típusok — TTLS
Felhasználónév és jelszó — hagyjuk üresen
Belső hitelesítés — PAP
Külső identitás — kliens
Bizalom fül. Itt adjuk meg a domainünket
Ennyi. A profilt elmenthetjük, aláírhatjuk és eloszthatjuk az eszközökön.
Miután a profil elkészült, le kell tölteni a Mac-re és telepíteni. A telepítés során meg kell adni a felhasználónevet (username_ldap) és a jelszót (password_ldap) a felhasználóhoz:
iOS
A folyamat hasonló a macOS-hez. Profilra van szükség (pontosan ugyanaz, mint a macOS-hez. Profil készítése az Apple Configuratorban, lásd fent).
Letöltjük a profilt, telepítjük, megadjuk a bejelentkezési adatokat, majd csatlakozunk:
Ezzel végeztünk. Beállítottuk a Radius szervert, szinkronizáltuk a FreeIPA-val, és megadtuk a Ubiquiti hozzáférési pontoknak, hogy WPA2-EAP-t használjanak.
Lehetséges kérdések
K: hogyan küldhetem el a profilt/certifikátot a munkatársnak?
V: Minden certifikátot/profillt FTP-n tárolok, webes hozzáféréssel. Létrehoztam egy vendéghálózatot sebességkorlátozással és csak internet hozzáféréssel, FTP kivételével.
Az autentikáció 2 napig tart, utána alaphelyzetbe áll, és a kliens internet nélkül marad. Tehát amikor a munkatárs csatlakozni szeretne a WiFi-hez, először csatlakozik a vendéghálózathoz, belép az FTP-re, letölti a szükséges certifikátot vagy profilt, majd telepíti azokat, és utána tud csatlakozni a vállalati hálózathoz.
K: miért ne használhatnánk MSCHAPv2 sémát? az biztonságosabb!
V: először is, ez a séma jól működik az NPS-sel (Windows Network Policy System), a mi megvalósításunkhoz további LDAP (FreeIPA) beállításokra van szükség, és a jelszavak hash-eit a szerveren kell tárolni. További beállításokat végezni nem kívánatos, mivel ez különböző szinkronizálási problémákhoz vezethet. Másodszor, a hash MD4 formátumú, tehát nem igazán növeli a biztonságot
K: lehet-e eszközöket MAC-címek alapján hitelesíteni?
V: NEM, ez nem biztonságos, egy támadó megváltoztathatja a MAC-címeket, és ráadásul sok eszköz nem támogatja a MAC-címek szerinti hitelesítést
K: miért kell egyáltalán ezeket a certifikátokat használni? nékülük nem lehet csatlakozni?
V: A tanúsítványokat a szerver hitelesítésére használják. Vagyis az eszköz csatlakozáskor ellenőrzi, hogy ez a szerver megbízható-e vagy sem. Ha igen, akkor a hitelesítés folytatódik, ha nem, a kapcsolat megszakad. Tanúsítványok nélkül is lehet csatlakozni, de ha egy hacker vagy szomszéd saját radius-szervert és hozzáférési pontot indít el ugyanolyan névvel, mint a miénk, könnyen elkaphatja a felhasználó hitelesítési adatait (ne felejtsük el, hogy ezek nyílt formában kerülnek továbbításra). Ha viszont tanúsítványt használunk, az ellenség csak a mi kitalált felhasználónévjegyeinket – vendég vagy kliens – és egy „Ismeretlen CA tanúsítvány” hibaüzenetet fog látni a naplóiban.
Még egy kicsit az macOS-rólÁltalában az macOS újratelepítése az interneten keresztül történik. A helyreállítási módban a Mac-et WiFi-re kell csatlakoztatni, és itt sem a vállalati WiFi-m, sem a vendéghálózat nem működik. Én személyesen indítottam egy másik hálózatot, egy szokásos WPA2-PSK-t, rejtett, csak technikai műveletekhez. Vagy előre létrehozhatunk egy rendszerrel töltött USB meghajtót is. De ha a Mac 2015 után készült, akkor szükség lesz egy adapterre ehhez az USB-hez is.
Forrás: habr.com
