Mõned näited ettevõtte WiFi korraldamisest on juba kirjeldatud. Siin kirjeldan, kuidas ma sarnase lahenduse rakendasin ja probleeme, millega pidin erinevate seadmete ühendamisel silmitsi seisma. Kasutame registreeritud kasutajatega juba olemasolevat LDAP-i, tõstame FreeRadiuse ja konfigureerime Ubnt-kontrolleris WPA2-Enterprise. Kõik tundub lihtne. Vaatame…
Natuke EAP meetoditest
Enne ülesandega jätkamist peame otsustama, millist autentimismeetodit oma lahenduses kasutame.
Wikipediast:
EAP on autentimisraamistik, mida kasutatakse sageli traadita võrkudes ja punkt-punkti ühendustes. Vormingut kirjeldati esmakordselt standardis RFC 3748 ja seda värskendati standardis RFC 5247.
EAP-d kasutatakse autentimismeetodi valimiseks, võtmete edastamiseks ja nende võtmete töötlemiseks pistikprogrammidega, mida nimetatakse EAP-meetoditeks. EAP-meetodeid on palju, nii EAP-i endaga määratletud kui ka üksikute tarnijate poolt välja antud. EAP ei määratle lingikihti, vaid määrab ainult sõnumi vormingu. Igal EAP-d kasutaval protokollil on oma EAP-sõnumite kapseldamise protokoll.
Meetodid ise:
- LEAP on patenteeritud protokoll, mille on välja töötanud CISCO. Leitud haavatavused. Hetkel ei soovitata kasutada
- EAP-TLS on traadita side tarnijate seas hästi toetatud. See on turvaline protokoll, kuna see on SSL-i standardite järglane. Kliendi seadistamine on üsna keeruline. Lisaks paroolile vajate kliendi sertifikaati. Toetatud paljudes süsteemides
- EAP-TTLS - paljudes süsteemides laialdaselt toetatud, pakub head turvalisust, kasutades PKI-sertifikaate ainult autentimisserveris
- EAP-MD5 on veel üks avatud standard. Pakub minimaalset turvalisust. Haavatav, ei toeta vastastikust autentimist ja võtme genereerimist
- EAP-IKEv2 – põhineb Interneti-võtmevahetusprotokolli versioonil 2. Pakub vastastikust autentimist ja seansivõtme loomist kliendi ja serveri vahel
- PEAP on CISCO, Microsofti ja RSA Security ühislahendus avatud standardina. Toodetes laialdaselt saadaval, tagab väga hea turvalisuse. Sarnaselt EAP-TTLS-iga, mis nõuab ainult serveripoolset sertifikaati
- PEAPv0/EAP-MSCHAPv2 – EAP-TLSi järel on see maailmas teine laialt levinud standard. Kasutatud klient-server suhet Microsoftis, Ciscos, Apple'is, Linuxis
- PEAPv1/EAP-GTC – loodud Cisco poolt PEAPv0/EAP-MSCHAPv2 alternatiivina. Ei kaitse mingil moel autentimisandmeid. Ei toetata Windows OS-is
- EAP-FAST on Cisco poolt välja töötatud tehnika LEAPi puuduste parandamiseks. Kasutab kaitstud juurdepääsu mandaati (PAC). Täiesti lõpetamata
Kogu sellest mitmekesisusest pole valik ikkagi suur. Vaja oli autentimismeetodit: hea turvalisus, tugi kõikides seadmetes (Windows 10, macOS, Linux, Android, iOS) ja tegelikult, mida lihtsam, seda parem. Seetõttu langes valik EAP-TTLS-ile koos PAP-protokolliga.
Võib tekkida küsimus – Miks kasutada PAP-i? sest ta edastab paroole selge?
Jah see on õige. FreeRadiuse ja FreeIPA vaheline suhtlus toimub täpselt nii. Silumisrežiimis saate jälgida, kuidas kasutajanimi ja parool saadetakse. Jah, ja laske neil minna, ainult teil on juurdepääs FreeRadiuse serverile.
Täpsemalt saab lugeda EAP-TTLSi tööst
FreeRADIUS
FreeRadius tõstetakse CentOS 7.6-s. Siin pole midagi keerulist, me seadistame selle tavapärasel viisil.
yum install freeradius freeradius-utils freeradius-ldap -y
Pakettidest on installitud versioon 3.0.13. Viimast saab võtta kl
Pärast seda FreeRadius juba töötab. Saate rea kommentaaride tühistada failis /etc/raddb/users
steve Cleartext-Password := "testing"
Käivitage silumisrežiimis serverisse
freeradius -X
Ja looge localhostist testühendus
radtest steve testing 127.0.0.1 1812 testing123
Saime vastuse Vastu võetud juurdepääsu-aktsepti ID 115 vahemikus 127.0.0.1:1812 kuni 127.0.0.1:56081 pikkus 20, see tähendab, et kõik on korras. Lase käia.
Mooduli ühendamine ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap
Ja me muudame seda kohe. FreeIPA-le juurdepääsuks vajame FreeRadiust
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 raadiuse server ja kontrollige LDAP-i kasutajate sünkroonimist:
radtest user_ldap password_ldap localhost 1812 testing123
Redigeerimine eap sisse mods-enabled/eap
Lisame siia kaks eap-i eksemplari. Need erinevad ainult sertifikaatide ja võtmete poolest. Allpool selgitan, miks see nii on.
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"
}
}
Edasine toimetamine saidi lubatud/vaikeseade. Huvi pakuvad autoriseerimis- ja autentimisjaotised.
saidi lubatud/vaikeseade
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
}
Autoriseerimise jaotises eemaldame kõik moodulid, mida me ei vaja. Jätame ainult ldapi. Lisage kliendi kinnitus kasutajanime järgi. Seetõttu lisasime eespool kaks eap-i eksemplari.
Mitu EAPFakt on see, et mõne seadme ühendamisel kasutame süsteemisertifikaate ja määrame domeeni. Meil on usaldusväärse sertifitseerimisasutuse sertifikaat ja võti. Isiklikult on minu meelest selline ühendamisprotseduur lihtsam, kui igale seadmele omaallkirjastatud sertifikaadi viskamine. Kuid isegi ilma ise allkirjastatud sertifikaatideta see ikkagi ei õnnestunud. Samsungi seadmed ja Android =< 6 versiooni ei saa kasutada süsteemisertifikaate. Seetõttu loome nende jaoks eraldi eap-guesti eksemplari iseallkirjastatud sertifikaatidega. Kõigi muude seadmete puhul kasutame usaldusväärse sertifikaadiga eap-klienti. Kasutajanimi määratakse välja Anonüümse abil, kui seade on ühendatud. Lubatud on ainult 3 väärtust: külaline, klient ja tühi väli. Kõik muu visatakse kõrvale. See konfigureeritakse poliitikutes. Toon näite veidi hiljem.
Redigeerime autoriseerimise ja autentimise jaotisi saidi lubatud/sisemine tunnel
saidi lubatud/sisemine 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
}
Järgmiseks tuleb reeglites määrata, milliseid nimesid saab kasutada anonüümseks sisselogimiseks. Redigeerimine policy.d/filter.
Peate leidma sarnased read:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}
Ja allpool elsif lisage soovitud väärtused:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}
Nüüd peame liikuma kataloogi sertifikaadid. Siia tuleb panna võti ja sertifikaat usaldusväärselt sertifitseerimisasutuselt, mis meil juba on ja mis tuleb genereerida eap-guesti jaoks iseallkirjastatud sertifikaadid.
Muutke failis olevaid parameetreid ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "CA FreeRadius"
Kirjutame faili samad väärtused server.cnf. Meie ainult muutume
tavanimi:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "Server Certificate FreeRadius"
Loo:
make
Valmis. Vastu võetud server.crt и server.key oleme juba eespool eap-külalises registreerunud.
Ja lõpuks lisame failile meie pääsupunktid klient.conf. Mul on neid 7. Et mitte iga punkti eraldi lisada, kirjutame ainult võrgu, milles need asuvad (minu pöörduspunktid on eraldi VLAN-is).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}
Ubiquiti kontroller
Tõstame kontrollerile eraldi võrgu. Olgu selleks 192.168.2.0/24
Avage seaded -> profiil. Loome uue:
Kirjutame raadiusserveri aadressi ja pordi ning parooli, mis faili oli kirjutatud clients.conf:
Looge uus traadita võrgu nimi. Valige autentimismeetodiks WPA-EAP (Enterprise) ja määrake loodud raadiuse profiil:
Salvestame kõik, kandideerime ja liigume edasi.
Klientide seadistamine
Alustame kõige raskemast!
Windows 10
Raskus seisneb selles, et Windows ei tea veel, kuidas domeeni kaudu ettevõtte WiFi-ga ühendust luua. Seetõttu peame oma sertifikaadi käsitsi usaldusväärsesse sertifikaadisalve üles laadima. Siin saate kasutada nii iseallkirjastatud kui ka sertifitseerimisasutuselt. Ma kasutan teist.
Järgmiseks peate looma uue ühenduse. Selleks avage võrgu- ja Interneti-seaded -> Võrgu- ja ühiskasutuskeskus -> Loo ja konfigureerige uus ühendus või võrk:
Sisestage käsitsi võrgu nimi ja muutke turbe tüüpi. Pärast seda, kui klõpsame muuta ühenduse seadeid ja vahekaardil Turvalisus valige võrgu autentimine – EAP-TTLS.
Minge seadetesse, määrake autentimise konfidentsiaalsus - klient. Usaldusväärse sertifitseerimisasutusena valige meie lisatud sertifikaat, märkige ruut "Ära väljasta kasutajale kutset, kui serverit ei saa autoriseerida" ja valige autentimisviis - krüptimata parool (PAP).
Järgmisena minge täpsematesse seadetesse, märkige ruut "Määrake autentimisrežiim". Valige "Kasutaja autentimine" ja klõpsake nuppu salvestage mandaadid. Siin peate sisestama kasutajanimi_ldap ja parool_ldap
Salvestame kõik, taotleme, sulgeme. Saate luua ühenduse uue võrguga.
Linux
Testisin Ubuntu 18.04, 18.10, Fedora 29, 30 peal.
Kõigepealt laadime alla oma sertifikaadi. Ma ei leidnud Linuxis, kas süsteemisertifikaate saab kasutada ja kas sellist poodi üldse on.
Ühendame domeeniga. Seetõttu vajame sertifikaati sertifitseerimisasutuselt, kust meie sertifikaat osteti.
Kõik ühendused tehakse ühes aknas. Valige meie võrk:
anonüümne klient
domeen — domeen, mille jaoks sertifikaat väljastati
Android
mitte Samsung
Alates versioonist 7 saate WiFi ühendamisel kasutada süsteemisertifikaate, määrates ainult domeeni:
domeen — domeen, mille jaoks sertifikaat väljastati
anonüümne klient
Samsung
Nagu eespool kirjutasin, ei oska Samsungi seadmed WiFi-ga ühenduse loomisel süsteemisertifikaate kasutada ja neil puudub ka võimalus domeeni kaudu ühendust luua. Seetõttu peate käsitsi lisama sertifitseerimisasutuse juursertifikaadi (ca.pem, võtame selle Radiuse serverisse). Siin kasutatakse iseallkirja.
Laadige sertifikaat oma seadmesse alla ja installige see.
Sertifikaadi paigaldamine
Samal ajal peate määrama ekraani avamise mustri, PIN-koodi või parooli, kui see pole veel määratud:
Näitasin sertifikaadi installimise keerulist versiooni. Enamikus seadmetes klõpsake lihtsalt allalaaditud sertifikaadil.
Kui sertifikaat on installitud, saate jätkata ühenduse loomist:
sertifikaat - märkige installitud sertifikaat
anonüümne kasutaja – külaline
macOS
Apple'i seadmed saavad karbist välja võtta ainult EAP-TLS-iga ühenduse, kuid peate neile siiski sertifikaadi välja andma. Erineva ühendusviisi määramiseks tuleb kasutada Apple Configurator 2. Sellest lähtuvalt tuleb see esmalt oma Maci alla laadida, luua uus profiil ja lisada kõik vajalikud WiFi seaded.
Apple Configurator
Sisestage siia oma võrgu nimi
Turvatüüp – WPA2 Enterprise
Aktsepteeritud EAP-tüübid – TTLS
Kasutajanimi ja parool – jätke tühjaks
Sisemine autentimine – PAP
Väline identiteet-klient
Usalduse vahekaart. Siin täpsustame oma domeeni
Kõik. Profiili saab salvestada, allkirjastada ja seadmetesse levitada
Kui profiil on valmis, peate selle mooni alla laadima ja installima. Installimise ajal peate määrama kasutaja kasutajatunnused usernmae_ldap ja password_ldap:
iOS
Protsess on sarnane macOS-iga. Peate kasutama profiili (saate kasutada sama mis macOS-i puhul. Kuidas Apple Configuratoris profiili luua, vt ülalt).
Laadige profiil alla, installige, sisestage mandaadid, ühendage:
See on kõik. Seadistasime Radiuse serveri, sünkroonisime selle FreeIPA-ga ja käskisime Ubiquiti AP-del kasutada WPA2-EAP-i.
Võimalikud küsimused
Sisse: kuidas töötajale profiili/tunnistust üle anda?
Umbes: Ma salvestan kõik sertifikaadid/profiilid veebijuurdepääsuga ftp-le. Tõstas külalisvõrgu kiiruspiiranguga ja juurdepääsuga ainult Internetile, välja arvatud ftp.
Autentimine kestab 2 päeva, misjärel see lähtestatakse ja klient jääb ilma internetita. See. Kui töötaja soovib WiFi-ga ühendust luua, loob ta esmalt ühenduse külalisvõrguga, logib FTP-sse, laadib alla vajaliku sertifikaadi või profiili, installib need ja saab seejärel luua ühenduse ettevõtte võrguga.
Sisse: miks mitte kasutada skeemi MSCHAPv2-ga? Ta on turvalisem!
Umbes: Esiteks töötab selline skeem hästi NPS-is (Windows Network Policy System), meie juurutamisel on vaja lisaks konfigureerida LDAP (FreeIpa) ja salvestada serverisse parooliräsi. Lisama. ei ole soovitav seadistusi teha, sest. see võib põhjustada erinevaid probleeme ultraheli sünkroniseerimisel. Teiseks on räsi MD4, nii et see ei lisa palju turvalisust.
Sisse: kas seadmeid on võimalik autoriseerida mac-aadresside järgi?
Umbes: EI, see pole ohutu, ründaja võib MAC-aadresse muuta ja veelgi enam, MAC-aadresside autoriseerimist ei toetata paljud seadmed
Sisse: mida üldiselt kõigi nende sertifikaatide jaoks kasutada? kas saate ilma nendeta liituda?
Umbes: sertifikaate kasutatakse serveri autoriseerimiseks. Need. seade kontrollib ühenduse loomisel, kas tegemist on serveriga, mida saab usaldada või mitte. Kui jah, siis autentimine jätkub; kui ei, siis ühendus suletakse. Saate luua ühenduse ilma sertifikaatideta, kuid kui ründaja või naaber seadistab kodus meiega sama nimega raadiuse serveri ja pääsupunkti, saab ta hõlpsalt kasutaja mandaadid pealt kuulata (ärge unustage, et need edastatakse selge tekstina) . Ja kui sertifikaati kasutatakse, näeb vaenlane oma logides ainult meie fiktiivset kasutajanime – külaline või klient ja tüübiviga – tundmatu CA sertifikaat
natuke rohkem macOS-i kohtaTavaliselt toimub macOS-is süsteemi uuesti installimine Interneti kaudu. Taasterežiimis peab Mac olema ühendatud WiFi-ga ja siin ei tööta meie ettevõtte WiFi ega külaliste võrk. Isiklikult tõstsin teise võrgu, tavalise WPA2-PSK, peidetud, ainult tehniliste toimingute jaoks. Või saate siiski süsteemiga eelnevalt teha alglaaditava USB-mälupulga. Aga kui moon on pärast 2015. aastat, peate ikkagi selle välkmäluseadme jaoks adapteri leidma)
Allikas: www.habr.com