Boli už opísané niektoré príklady organizácie firemného WiFi. Tu popíšem, ako som implementoval podobné riešenie a problémy, s ktorými som sa stretol pri pripojení na rôznych zariadeniach. Budeme používať existujúci LDAP so zaregistrovanými používateľmi, spustíme FreeRadius a nastavíme WPA2-Enterprise na kontroléri Ubnt. Zdá sa, že to je jednoduché. Poďme sa pozrieť…
Trochu o metódach EAP
Predtým, než začneme plniť úlohu, musíme si uvedomiť, akú metódu autentifikácie budeme používať v našom riešení.
Z Wikipédie:
EAP — rámec autentifikácie, ktorý sa často používa v bezdrôtových sieťach a spojeniach bod-bod. Formát bol prvýkrát opísaný v RFC 3748 a aktualizovaný v RFC 5247.
EAP sa používa na výber metódy autentifikácie, prenos kľúčov a spracovanie týchto kľúčov pripojenými modulmi nazývanými metódy EAP. Existuje mnoho metód EAP, ako sú definované spolu s EAP samotným, tak aj vydané jednotlivými výrobcami. EAP nedefinuje kanálovú vrstvu, iba definuje formát správ. Každý protokol, ktorý používa EAP, má svoj vlastný protokol enkapsulácie správ EAP.
Samotné metódy:
- LEAP — proprietárny protokol, vyvinutý spoločnosťou CISCO. Boli nájdené zraniteľnosti. V súčasnosti sa neodporúča používať.
- EAP-TLS — dobre podporovaný medzi dodávateľmi bezdrôtových spojení. Je to bezpečný protokol, keďže je nástupcom SSL štandardov. Nastavenie klienta je dosť zložité. Je potrebný klientsky certifikát okrem hesla. Podporuje ho mnoho systémov.
- EAP-TTLS — široko podporovaný v mnohých systémoch, ponúka dobrú bezpečnosť pomocou PKI certifikátov iba na serveri autentifikácie.
- EAP-MD5 — ďalší otvorený štandard. Ponúka minimálnu bezpečnosť. Je zraniteľný, nepodporuje vzájomnú autentifikáciu a generáciu kľúčov.
- EAP-IKEv2 — založený na protokole Internet Key Exchange Protocol version 2. Zabezpečuje vzájomnú autentifikáciu a vytvorenie relácie kľúča medzi klientom a serverom.
- PEAP — spoločné riešenie spoločností CISCO, Microsoft a RSA Security ako otvorený štandard. Široko dostupný v produktoch, zabezpečuje veľmi dobrú bezpečnosť. Je podobný EAP-TTLS, vyžaduje iba certifikát na serverovej strane.
- PEAPv0/EAP-MSCHAPv2 — po EAP-TLS je to druhý najrozšírenejší štandard na svete. Používa sa klient-server vzťah v Microsofte, Ciscu, Apple, Linuxe
- PEAPv1/EAP-GTC — vytvorený Ciscom ako alternatíva k PEAPv0/EAP-MSCHAPv2. Nechráni autentifikačné údaje v žiadnom prípade. Nie je podporovaný v operačných systémoch Windows
- EAP-FAST — metóda vyvinutá Ciscom na nápravu nedostatkov LEAP. Používa Protected Access Credential (PAC). Nie je úplne dokončená
Z celej tejto rozmanitosti výber predsa len nie je veľký. Od metódy autentifikácie sa požadovalo: dobrá bezpečnosť, podpora na všetkých zariadeniach (Windows 10, macOS, Linux, Android, iOS) a, vlastne, čím jednoduchšie, tým lepšie. Preto výber padol na EAP-TTLS v spojení s protokolom PAP.
Môže vzniknúť otázka — Prečo teda používať PAP? veď on prenáša heslá v otvorenej forme?
Áno, je to pravda. Komunikácia medzi FreeRadius a FreeIPA bude prebiehať presne takto. V debug režime možno sledovať, ako sa odosielajú meno používateľa a heslo. A nech sa odosielajú, veď len vy máte prístup k serveru FreeRadius.
Viac informácií o práci EAP-TTLS si môžete prečítať
FreeRADIUS
FreeRadius spustíme na CentOS 7.6. Tu nie je nič zložité, nainštalujeme ho bežným spôsobom.
yum install freeradius freeradius-utils freeradius-ldap -yZ balíkov sa inštaluje verzia 3.0.13. Poslednú možno získať na
Po tomto už FreeRadius funguje. Môžete v /etc/raddb/users odkomentovať riadok
steve Cleartext-Password := "testing"Spustíme server v debug režime
freeradius -XA urobíme testovacie pripojenie s localhostom
radtest steve testing 127.0.0.1 1812 testing123Dostali sme odpoveď Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, znamená to, že všetko je v poriadku. Ideme ďalej.
Pripojíme modul ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapA hneď ho zmeníme. Potrebujeme, aby FreeRadius mohol komunikovať s FreeIPA
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}})"
}
...Reštartujeme radius server a kontrolujeme synchronizáciu používateľov LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Upravujeme eap v mods-enabled/eap
Tu pridáme dve inštancie eap. Budú sa líšiť len certifikátmi a kľúčmi. O chvíľu vysvetlím, prečo presne takto
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"
}
}Ďalej editujeme site-enabled/default. Zaujímajú nás sekcie authorize a authenticate.
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
}V sekcii authorize odstraňujeme všetky moduly, ktoré nepotrebujeme. Nechávame len ldap. Pridávame kontrolu klienta podľa username. Práve preto sme vyššie pridali dva inštancie eap.
Multi EAPIde o to, že pri pripájaní niektorých zariadení budeme používať systémové certifikáty a uvádzať doménu. Máme certifikát a kľúč od dôveryhodného certifikačného centra. Z môjho pohľadu je tento spôsob pripájania jednoduchší, ako posielať samopodpísaný certifikát na každé zariadenie. Ale ani bez samopodpísaných certifikátov to nakoniec nešlo. Zariadenia Samsung a Android < 6 verzie nedokážu používať systémové certifikáty. Pre tieto zariadenia vytvárame samostatnú inštanciu eap-guest so samopodpísanými certifikátmi. Pre všetky ostatné zariadenia budeme používať eap-client s dôveryhodným certifikátom. User-Name sa určuje podľa poľa Anonymous pri pripojení zariadenia. Povolené sú len 3 hodnoty: Guest, Client a prázdne pole. Všetko ostatné bude odmietnuté. Toto sa nastavuje v politikách. Príklad uvediem neskôr.
Upravíme sekcie authorize a authenticate v 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
}Ďalej je potrebné v politikách predpísať, aké mená je možné použiť pre anonymný vstup. Upravujeme policy.d/filter.
Musíme nájsť riadky podobné tomuto:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}A nižšie v elsif pridať požadované hodnoty:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Teraz sa musíme presunúť do adresára certs. Sem je potrebné umiestniť kľúč a certifikát od dôveryhodného certifikačného centra, ktorý už máme, a vygenerovať samopodpísané certifikáty pre eap-guest.
Meníme parametre v súbore ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = SK
stateOrProvinceNmae = Štát
localityNmae = Mesto
organizationName = NONAME
emailAddress = admin@admin.sk
commonName = "CA FreeRadius"Tieto isté hodnoty uvádzame v súbore server.cnf. Meníme iba
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = SK
stateOrProvinceNmae = Štát
localityNmae = Mesto
organizationName = NONAME
emailAddress = admin@admin.sk
commonName = "Server Certificate FreeRadius"Vytvárame:
makeHotovo. Získané server.crt a server.key u nás už sú uvedené vyššie v eap-guest.
A nakoniec, pridáme naše prístupové body do súboru client.conf. Mám ich 7. Aby som nemusel pridávať každý bod osobitne, uvedieme iba sieť, v ktorej sa nachádzajú (môj bod prístupu sa nachádza v samostatnom VLAN).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Kontrolér Ubiquiti
Na kontroléri vytvárame samostatnú sieť. Nech to bude 192.168.2.0/24
Prejdeme do nastavení -> profil. Vytvárame nový:
Uvedieme adresu a port radius-servera a heslo, ktoré sme uviedli v súbore clients.conf:
Vytvoríme nové meno bezdrôtovej siete. Ako metódu autentifikácie vyberieme WPA-EAP (Enterprise) a uvedieme vytvorený radius-profil:
Všetko uložíme, použijeme a ideme ďalej.
Nastavenie klientov
Začneme s najťažším!
Windows 10
Zložitosti spočívajú v tom, že Windows zatiaľ nevie pripojiť sa k firemnému WiFi prostredníctvom domény. Preto musíme manuálne pridať náš certifikát do úložiska dôveryhodných certifikátov. Môžeme použiť ako samopodpísaný, tak aj od certifikačného centra. Ja budem používať druhý.
Ďalej treba vytvoriť nové pripojenie. Na to prejdeme do nastavení siete a internetu -> Centrum správy sietí a zdieľania -> Vytvorenie a nastavenie nového pripojenia alebo siete:
Ručne uvedieme názov siete a zmeníme typ zabezpečenia. Potom klikneme na zmeniť nastavenia pripojenia a na karte Bezpečnosť vyberieme overenie siete — EAP-TTLS.
Dostaneme sa do nastavení, uvedieme dôvernosť autentifikácie — client. Ako dôveryhodné certifikačné centrum vyberieme certifikát, ktorý sme pridali, zaškrtávame „Nevyžadovať od používateľa výzvu, ak sa server nedá overiť“ a metódu overenia volíme — nešifrované heslo (PAP).
Potom prejdeme do rozšírených nastavení, zaškrtneme možnosť „Uveďte režim overovania“. Vyberieme položku „Overenie používateľa“ a klikneme na uložiť prihlasovacie údaje. Tu bude potrebné zadať username_ldap a password_ldap
Všetko uložíme, aplikujeme, zatvoríme. Môžeme sa pripojiť k novej sieti.
Linux
Testoval som to na Ubuntu 18.04, 18.10, Fedora 29, 30.
Najprv si stiahneme certifikát. Nenašiel som v Linuxe, či je možné používať systémové certifikáty a či tam vôbec také úložisko existuje.
Budeme sa pripájať cez doménu. Preto je potrebný certifikát certifikačnej autority, od ktorej bol náš certifikát zakúpený.
Celé pripojenie prebieha v jednom okne. Vyberieme našu sieť:
anonymous — client
domain — doména, na ktorú bol certifikát vydaný
Android
non-Samsung
Od verzie 7 pri pripojení WiFi je možné používať systémové certifikáty, ak uvedieme iba doménu:
domain — doména, na ktorú bol certifikát vydaný
anonymous — client
Samsung
Ako som už spomínal, zariadenia Samsung nevedia používať systémové certifikáty pri pripojení WiFi a nemajú možnosť pripojiť sa cez doménu. Preto je potrebné ručne pridať koreňový certifikát certifikačnej autority (ca.pem, berieme na Radius serveri). Tu bude použitý vlastnoručne podpísaný.
Stiahneme si certifikát na zariadenie a nainštalujeme ho.
Inštalácia certifikátu
Pri tom bude potrebné nastaviť obrazovku na odomknutie, PIN kód alebo heslo, ak ešte nebolo nastavené:
Ukázal som zložitú verziu inštalácie certifikátu. Na väčšine zariadení stačí jednoducho kliknúť na stiahnutý certifikát.
Keď je certifikát nainštalovaný, môžeme prejsť k pripojeniu:
certifikát — uvedieme ten, ktorý sme nainštalovali
anonymný používateľ — guest
macOS
Jablkové zariadenia môžu zo základne prihlasovať iba k EAP-TLS, ale aj tak je potrebné im dodať certifikát. Aby ste uviedli iný spôsob pripojenia, musíte použiť Apple Configurator 2. Samozrejme je potrebné ho najskôr stiahnuť na Mac, vytvoriť nový profil a pridať všetky potrebné nastavenia WiFi.
Apple Configurator
Tu uvedieme názov našej siete
Typ zabezpečenia — WPA2 Enterprise
Akceptované typy EAP — TTLS
Používateľské meno a heslo — necháme prázdne
Vnútorné overenie — PAP
Vonku identita — client
Záložka Dôvera. Tu uvedieme našu doménu
Všetko. Profil môžeme uložiť, podpísať a distribuovať na zariadenia
Po dokončení profilu je potrebné ho stiahnuť na Mac a nainštalovať. Počas inštalácie bude potrebné zadať username_ldap a password_ldap používateľa:
iOS
Proces je rovnaký ako na macOS. Je potrebné použiť profil (môže byť presne ten istý ako pre macOS. Ako vytvoriť profil v Apple Configurator, pozrite vyššie).
Sťahujeme profil, inštalujeme, zadávame prihlasovacie údaje, pripojujeme sa:
To je všetko. Nastavili sme Radius server, synchronizovali ho s FreeIPA a určili sme prístupovým bodom Ubiquiti, aby používajú WPA2-EAP.
Možné otázky
A: ako poslať profil/ certifikát zamestnancovi?
O: Všetky certifikáty/profily uchovávam na ftp s prístupom cez web. Vytvoril som hosťovskú sieť s obmedzením rýchlosti a prístupom len do internetu, s výnimkou ftp.
Autentifikácia trvá 2 dni, po čom sa resetuje a klient zostáva bez internetu. Teda, keď sa zamestnanec chce pripojiť k WiFi, najprv sa pripojí k hosťovskej sieti, prejde na ftp, stiahne potrebný certifikát alebo profil, nainštaluje ich a potom sa môže pripojiť k firemnej sieti.
A: prečo nepoužiť schému s MSCHAPv2? je predsa bezpečnejšia!
O: Po prvé, taká schéma dobre funguje na NPS (Windows Network Policy System), v našej implementácii je potrebné dodatočne nakonfigurovať LDAP (FreeIPA) a uchovávať hash hesiel na serveri. Dodatočné nastavenia nie sú žiaduce, pretože to môže viesť k rôznym problémom so synchronizáciou používateľských účtov. Po druhé, hash predstavuje MD4, takže to výrazne nezvyšuje bezpečnosť.
A: je možné autorizovať zariadenia podľa MAC adries?
O: NIE, to nie je bezpečné, útočník môže zmeniť MAC adresy, a navyše autorizácia podľa MAC adries nie je podporovaná na mnohých zariadeniach.
A: načo vlastne používať všetky tieto certifikáty? dá sa predsa pripojiť aj bez nich.
O: Certifikáty sa používajú na autorizáciu servera. T.j. zariadenie pri pripojení kontroluje, či ide o server, ktorému sa dá dôverovať, alebo nie. Ak áno, autentifikácia pokračuje, ak nie, spojenie sa uzavrie. Môžete sa pripojiť aj bez certifikátov, ale ak útočník alebo sused spustí doma radius-server a prístupový bod so rovnakým menom ako máme my, môže ľahko zachytiť autentizačné údaje používateľa (nezabúdajme, že sú odosielané v otvorenej forme). A keď sa používa certifikát, nepriateľ uvidí vo svojich logoch iba naše vymyslené User-Name — guest alebo client a chybu typu — Unknown CA Certificate.
Ešte niečo o macOS.Obvykle sa na macOS reinstalácia systému robí cez internet. Pri obnove musí byť Mac pripojený k WiFi a tu nefunguje ani naša firemná WiFi, ani hosťovská sieť. Osobne som vytvoril ďalšiu sieť, bežnú s WPA2-PSK, skrytú, len pre technické operácie. Alebo je možné vopred vytvoriť bootovateľnú USB kľúč so systémom. Ak je to Mac z roku 2015 a novší, bude potrebné ešte nájsť adaptér pre tento USB kľúč.)
Zdroj: habr.com
