Mõned näited ettevõtte WiFi organisatsioonist on juba kirjeldatud. Siin seletan, kuidas ma sellist lahendust rakendasin ja probleeme, millega pidin silmitsi seisma erinevate seadmete ühendamisel. Kasutame juba olemasolevat LDAP-i registreeritud kasutajatega, seadistame FreeRadius'i ja konfigureerime WPA2-Enterprise Ubnt kontrolleril. Tundub, et kõik on lihtne. Vaatame …
Veidi EAP meetoditest
Enne ülesande täitmisele asumist tuleb otsustada, millist autentimismeetodit meie lahenduses kasutada.
Vikipeediast:
EAP on autentimise raamistik, mida kasutatakse sageli traadita võrkudes ja punkt-punkt ühendustes. Formaati kirjeldati esmakordselt RFC 3748-s ja uuendati RFC 5247-s.
EAP-d kasutatakse autentimismeetodi valimiseks, võtmete edastamiseks ja nende töötlemiseks ühendatud moodulite poolt, mida nimetatakse EAP meetoditeks. On palju EAP meetodeid, nii selliseid, mis on määratletud koos EAP-ga, kui ka eraldi tootjate poolt välja antud. EAP ei defineeri kanalitaset, vaid ainult sõnumite formaadi. Igal EAP-d kasutaval protokollil on oma EAP sõnumite kapseldamise protokoll.
Meetodid:
- LEAP — Proprietary protocol developed by CISCO. Vulnerabilities have been found. Currently not recommended for use.
- EAP-TLS — Well-supported among wireless connection vendors. It's a secure protocol as it is a successor to SSL standards. Client setup is quite complex. A client certificate is required in addition to a password. Supported by many systems.
- EAP-TTLS — Widely supported across many systems, offers good security using PKI certificates only on the authentication server.
- EAP-MD5 — Another open standard. Provides minimal security. Vulnerable, does not support mutual authentication and key generation.
- EAP-IKEv2 — Based on Internet Key Exchange Protocol version 2. Provides mutual authentication and establishes a session key between the client and server.
- PEAP — A joint solution by CISCO, Microsoft, and RSA Security as an open standard. Widely available in products, provides very good security. Similar to EAP-TTLS, requiring only a certificate on the server side.
- PEAPv0/EAP-MSCHAPv2 — pärast EAP-TLS on see teine laialdaselt kasutatav standard maailmas. Kasutatakse kliendi-serveri suhtlust Microsoftis, Cisco's, Apple'is ja Linuxis.
- PEAPv1/EAP-GTC — loodud Cisco poolt PEAPv0/EAP-MSCHAPv2 alternatiivina. Ei kaitse autentimisandmeid igal juhul. Windows OS-is ei toetata.
- EAP-FAST — meetod, mille on väljatöötanud Cisco LEAP'i puuduste parandamiseks. Kasutab Protected Access Credential (PAC). Pole täielikult väljatöötatud.
Sel kogu mitmekesisusel pole valik siiski suur. Autentimismeetodilt oodati head turvalisust, tugi kõigis seadmetes (Windows 10, macOS, Linux, Android, iOS) ja muidugi, mida lihtsam, seda parem. Seetõttu langes valik EAP-TTLS peale koos PAP protokolliga.
Võib tekkida küsimus — miks kasutada PAP-i? sest see edastab paroole avatud kujul?
Jah, kõik on õige. Suhtlemine FreeRadius'e ja FreeIPA vahel toimub tõepoolest nii. Debug-režiimis on võimalik jälgida, kuidas saadetakse kasutajanimi ja parool. Ja las saadetakse, teil on lihtsalt juurdepääs FreeRadius'e serverile.
Rohkem EAP-TTLS töö kohta saab lugeda
FreeRADIUS
FreeRadius käivitame CentOS 7.6-s. Siin pole midagi keerulist, installime tavalise meetodiga.
yum install freeradius freeradius-utils freeradius-ldap -yPakettidest installitakse versioon 3.0.13. Viimase saab võtta
Pärast seda töötab FreeRadius juba. Failis /etc/raddb/users saab kommentaari eemaldada
steve Cleartext-Password := "testing"Käitage serverit silumisrežiimis
freeradius -XJa teeme testiühenduse localhostiga
radtest steve testing 127.0.0.1 1812 testing123Saime vastuse Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, see tähendab, et kõik on korras. Jätkame.
Ühendame mooduli ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapJa muudame seda kohe. Me vajame, et FreeRadius saaks ühendust võtta FreeIPA-ga
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}})"
}
...Taaskäivitage radius-server ja kontrollige LDAP kasutajate sünkroonimist:
radtest user_ldap password_ldap localhost 1812 testing123 Muudame eap failis mods-enabled/eap
Siia lisame kaks eap eksemplari. Need erinevad ainult sertifikaatide ja võtmete poolest. Veidi allpool selgitan, miks just nii.
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"
}
}Edasi toimetamine site-enabled/default. Huvi valdkondade authorize ja authenticate vastu.
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
}Osas authorize eemaldame kõik moodulid, mida me ei vaja. Jätame alles ainult ldap. Lisame kliendi kontrollimise username'i põhjal. Just selleks lisasime varem kaks eap eksemplari.
Multi EAPAsi on selles, et ühendades teatud seadmeid, kasutame me süsteemseid sertifikaate ja näitame domeeni. Meil on sertifikaat ja võti usaldusväärselt sertifitseerimiskeskuselt. Isiklikult arvan, et selline ühendamise protseduur on lihtsam, kui iga seadme jaoks kasutada iseallkirjastatud sertifikaati. Kuid ka ilma iseallkirjastatud sertifikaatideta ei õnnestunud meil siiski loobuda. Samsungi seadmed ja Android versioonid < 6 ei oska kasutada süsteemseid sertifikaate. Seetõttu loome neile eraldi eap-guest eksemplari iseallkirjastatud sertifikaatidega. Kõikide teiste seadmete puhul kasutame eap-clienti usaldusväärse sertifikaadiga. User-Name määratakse Anonymous väljalt, kui seade ühendatakse. Lubatud on kasutada ainult 3 väärtust: Guest, Client ja tühi väli. Kõik muu eemaldatakse. See seadistatakse poliitikates. Näite toome peagi.
Muudame sektsioonide authorize ja authenticate sisu. 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
}Edasi tuleb määrata poliitikates, milliseid nimesid võib kasutada anonüümsesse sisenemisse. Redigeerime. policy.d/filter.
Peame leidma read, mis sarnanevad järgmisele:
if (outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name ei ole anonüümne"
}
reject
}Ja allpool elsif lisame vajalikud väärtused:
elsif (outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name ei ole anonüümne"
}
reject
}Nüüd peame liikuma kausta certs. Siia tuleb panna võtme ja sertifikaadi usaldusväärselt sertifitseerimiselt, mis me juba omame, ja tuleb genereerida enda allkirjastatud sertifikaadid eap-guest jaoks.
Muudame parameetreid failis ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = EE
stateOrProvinceNmae = Osariik
localityNmae = Linn
organizationName = NONAME
emailAddress = admin@admin.ee
commonName = "CA FreeRadius"Samad väärtused kirjutame faili server.cnf. Muudame ainult
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = EE
stateOrProvinceNmae = Osariik
localityNmae = Linn
organizationName = NONAME
emailAddress = admin@admin.ee
commonName = "Server Certificate FreeRadius"Loome:
makeValmis. Saadud server.crt ja server.key on meil juba eespool eap-guest'is määratud.
Ja viimasena lisame meie ligipääsupunktid faili client.conf. Mul on neid 7. Et mitte lisada iga punkti eraldi, nimi, ainult koht, kus need asuvad (mul on juurdepääsupunktid eraldi VLAN-is).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Ubiquiti kontroller
Kontrolleril loome eraldi võrgu. Olgu see 192.168.2.0/24
Liigume seadistustesse -> profiil. Loome uue:
Kandke sisse radius-serveri aadress ja port ning parool, mille sisestame faili clients.conf:
Loome uue traadita võrgu nime. Autentimismeetodina valime WPA-EAP (Enterprise) ja näitame määratud radius-profiili:
Kinnitage kõik, rakendage ja liikuge edasi.
Kliendi seadistamine
Alustame kõige keerulisema osaga!
Windows 10
Keerukus seisneb selles, et Windows ei oska veel корпоративное WiFi-d domeeni kaudu ühendada. Seega tuleb meie sertifikaat käsitsi usaldusväärsete sertifikaatide ladustamiseks lisada. Siin saab kasutada nii iseallkirjastatud kui ka sertifitseerimiskeskuse poolt väljastatud sertifikaati. Mina kasutan teist.
Seejärel tuleb luua uus ühendus. Selleks liigume võrguseadete juurde -> Interneti seaded -> Võrguhalduse juhtimiskeskus -> Uue ühenduse või võrgu loomine ja seadistamine:
Sisestame käsitsi võrgunime ja muudame turvatüübi. Seejärel vajutame ühenduse seadete muutmiseks ja vahekaardil Turvalisus valime võrgu autentimise - EAP-TTLS.
Siseneme seadistustesse, määrame autentimise konfidentsiaalsuse - client. Usaldusväärse sertifikaadi keskuse valimisel valime lisatud sertifikaadi, paneme linnukese "Ärge esitage kasutajale kutset, kui serverit ei saa autoriseerida" ja autentimise meetodiks valime - krüpteerimata parool (PAP).
Seejärel läheme täiendavatesse seadetesse, paneme linnukese "Määrake autentimise režiim". Valime punkti "Kasutaja autentimine" ja vajutame salvesta mandaadid. Siin tuleb sisestada username_ldap ja password_ldap.
Kogu info salvestame, rakendame, sulgeme. Võime uuele võrgule ühendada.
Linux
Olen proovinud Ubuntu 18.04, 18.10, Fedora 29, 30 peal.
Esiteks, laadime alla sertifikaadi. Ma ei leidnud Linuxis võimalust kasutada süsteemise sertifikaate ja kas seal on üldse selline säilitamine.
Ühendame oma domeeni kaudu. Seetõttu on vajalik sertifikaat, mille väljastas sertifitseerimiskeskus, kus meie sertifikaat on ostetud.
Kogu ühendamine toimub ühes aknas. Valime meie võrgu:
anonüümne — klient
domeen — domeen, millele sertifikaat on välja antud
Android
mitte-Samsung
Alates C 7 versioonist saab WiFi ühendamisel kasutada süsteemsertifikaate, märkides ainult domeeni:
domeen — domeen, millele sertifikaat on välja antud
anonüümne — klient
Samsung
Nagu eespool mainitud, ei oska Samsungi seadmed süsteemsertifikaate WiFi ühendamisel kasutada, ning neil puudub võimalus domeeni kaudu ühenduda. Seetõttu tuleb käsitsi lisada sertifitseerimiskeskuse juuresoleku sertifikaat (ca.pem, võtame Radius serverist). Siin kasutatakse isesigneeritud sertifikaati.
Laadige sertifikaat oma seadmesse ja installige see.
Sertifikaadi installimine
Selleks peate seadistama ekraani lukustuspildi, PIN-koodi või parooli, kui see pole veel seadistatud:
Näitasin sertifikaadi keerulist installimist. Enamikul seadmetest piisab, kui lihtsalt klõpsata allalaaditud sertifikaadil.
Kui sertifikaat on installitud, saab minna ühenduse loomise juurde:
sertifikaat — määrame selle, mille installisime
anonüümne kasutaja — külaline
macOS
Apple'i seadmed saavad ühenduda EAP-TLS-iga ainult karbist võttes, kuid sertifikaat tuleb neile ikkagi edastada. Teise ühendusmeetodi määramiseks tuleb kasutada Apple Configurator 2. Seega tuleb see eelnevalt Macile alla laadida, luua uus profiil ja lisada kõik vajalikud WiFi seaded.
Apple Configurator
Siin sisestame oma võrgu nime
Turbetüüp — WPA2 Enterprise
Aktsepteeritud EAP tüübid — TTLS
Kasutajatunnus ja parool — jätame tühjaks
Sisemine autentimine — PAP
Väline identiteet — client
Usaldusvahekaart. Siin määrame oma domeeni
Kõik. Profiili saab salvestada, allkirjastada ja jagada seadmetele
Pärast profiili valmimist tuleb see alla laadida Macile ja installida. Installimise protsessis tuleb sisestada kasutajanimi (username_ldap) ja parool (password_ldap) kasutaja jaoks:
iOS
Protsess sarnaneb macOS-iga. Tuleb kasutada profiili (võib olla täpselt sama nagu macOS-i jaoks). Kuidas luua profiili Apple Configurator'is, vaata ülevalt.
Laadime profiili alla, installime, sisestame kontoandmed ja ühendume:
Sellega ongi kõik. Oletasime Radius serveri ja sünkroniseerisime selle FreeIPA-ga ning määrasime Ubiquiti juurdepääsupunktidele kasutama WPA2-EAP.
Võimalikud küsimused
K: kuidas edastada profiil/sertifikaat töötajale?
A: Kõik sertifikaadid/profiilid hoian FTP-s, millele pääseb veebist. Olen loonud külalisvõrgu, millel on kiiruspiirang ja juurdepääs ainult internetile, välja arvatud FTP.
Autentimine kehtib 2 päeva, pärast mida see tühistatakse ja klient jääb ilma internetita. Seega, kui töötaja soovib WiFi-ühendust, peab ta esmalt ühenduma külalisvõrguga, minema FTP-sse, allalaadima vajalikud sertifikaadid või profiilid, installima need ja pärast seda saab ta ühenduda ettevõtte võrku.
K: Miks mitte kasutada skeemi MSCHAPv2? See on ju turvalisem!
A: Esiteks töötab selline skeem hästi NPS-is (Windows Network Policy System), meie rakenduses on vaja täiendavalt seadistada LDAP (FreeIpa) ja hoida paroolide krüpto serveris. Täiendavad seadistused pole soovitatavad, kuna need võivad põhjustada erinevaid sünkroonimisprobleeme. Teiseks on hash MD4, seega ei suurenda see eriti turvalisust.
K: Kas seadmeid saab autoriseerida MAC-aadresside järgi?
A: EI, see ei ole turvaline, ründaja võib MAC-aadresse valehäbida, samuti ei toetata MAC-aadresside järgi autoriseerimist paljudes seadmetes.
K: Miks üldse neid sertifikaate kasutada? Saaks ju ka ilma nendeta ühenduda.
A: Sertifikaate kasutatakse serveri autentimiseks. See tähendab, et seade kontrollib ühenduse loomisel, kas see on usaldusväärne server või mitte. Kui on, siis autentimine jätkub; kui ei, siis ühendus katkestatakse. Saaks ka ilma sertifikaatideta ühenduda, kuid kui ründaja või naaber seadistab kodus RADIUS-serveri ja ühenduspunkti sama nimega nagu meil, suudab ta hõlpsasti kasutaja mandaadi varastada (ärgem unustagem, et need edastatakse selgelt). Ja kui kasutada sertifikaati, näeb vaenlane oma logides ainult meie väljamõeldud kasutajanimesid — külaline või klient — ja tõrget tüüpi — Unknown CA Certificate.
Veidi veel macOS-ist.Tavaliselt tehakse macOS-is süsteemi uuendamine interneti kaudu. Taastamisrežiimis peab Mac olema ühendatud WiFi-ga, kuid meie ettevõtte WiFi ega külalisvõrk ei toimi siin. Isiklikult lõin veel ühe võrgu, mis on WPA2-PSK, peidetud, ainult tehniliste toimingute jaoks. Teine võimalus on eelnevalt valmistada käivitatav USB-mälu süsteemiga. Kuid kui Mac on pärast 2015. aastat, tuleb veel leida adapter selle mälupulga jaoks.)
Allikas: habr.com
