Der er allerede blevet beskrevet nogle eksempler på organisationen af virksomheders WiFi. Her vil jeg forklare, hvordan jeg implementerede en lignende løsning, samt de problemer, jeg stødte på ved tilslutning af forskellige enheder. Vi vil bruge den eksisterende LDAP med oprettede brugere, opsætte FreeRadius og konfigurere WPA2-Enterprise på Ubnt-kontrolløren. Det virker simpelt nok. Lad os se…
Lidt om EAP-metoder
Før vi går i gang med opgaven, skal vi beslutte, hvilken godkendelsesmetode vi vil bruge i vores løsning.
Fra Wikipedia:
EAP – en godkendelsesramme, der ofte anvendes i trådløse netværk og punkt-til-punkt-forbindelser. Formatet blev først beskrevet i RFC 3748 og opdateret i RFC 5247.
EAP bruges til at vælge godkendelsesmetode, overføre nøgler og behandle disse nøgler med tilsluttede moduler kaldet EAP-metoder. Der findes mange EAP-metoder, både dem der er defineret sammen med EAP selv, og dem, der er udgivet af forskellige producenter. EAP definerer ikke lagernetværket, det definerer kun formatet for meddelelser. Hver protokol, der bruger EAP, har sin egen EAP-meddelelsesindkapslingsprotokol.
Metoderne selv:
- LEAP – en proprietær protokol, udviklet af CISCO. Der er blevet fundet sårbarheder. Anbefales ikke til brug i øjeblikket.
- EAP-TLS – velunderstøttet blandt leverandører af trådløse forbindelser. Det er en sikker protokol, da det er en efterfølger til SSL-standarderne. Klientopsætning er forholdsvis kompleks. En klientcertifikat er påkrævet, ud over adgangskoden. Understøttes i mange systemer.
- EAP-TTLS – bredt understøttet i mange systemer, tilbyder god sikkerhed ved at bruge PKI-certifikater kun på godkendelsesserveren.
- EAP-MD5 – en anden åben standard. Tilbyder minimal sikkerhed. Sårbar, understøtter ikke gensidig godkendelse eller nøglegenerering.
- EAP-IKEv2 – baseret på Internet Key Exchange Protocol version 2. Giver gensidig godkendelse og etablering af sessionsnøglen mellem klienten og serveren.
- PEAP – en fælles løsning fra CISCO, Microsoft og RSA Security som en åben standard. Bredt tilgængelig i produkter, tilbyder meget god sikkerhed. Minder om EAP-TTLS, kræver kun certifikat på serversiden.
- PEAPv0/EAP-MSCHAPv2 — efter EAP-TLS, er dette den næstmest anvendte standard i verden. Den anvender en klient-server forbindelse i Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC — udviklet af Cisco som et alternativ til PEAPv0/EAP-MSCHAPv2. Beskytter ikke autentifikationsdata i nogen situation. Understøttes ikke i Windows OS
- EAP-FAST — en metode udviklet af Cisco for at rette manglerne i LEAP. Anvender Protected Access Credential (PAC). Er ikke fuldt udviklet
Af alt dette udvalg er valget dog ikke stort. Metoden til autentificering krævede: god sikkerhed, support på alle enheder (Windows 10, macOS, Linux, Android, iOS) og, selvfølgelig, jo simplere, jo bedre. Derfor faldt valget på EAP-TTLS i kombination med PAP-protokollen.
Der kan opstå et spørgsmål — hvorfor bruge PAP? Beskytter det ikke adgangskoder i klar tekst?
Ja, det er korrekt. Kommunikationen mellem FreeRadius og FreeIPA vil finde sted netop sådan. I debug-tilstand kan man spore, hvordan brugernavn og adgangskode sendes. Og lad dem blot sendes, så længe du har adgang til FreeRadius-serveren.
Du kan læse mere om EAP-TTLSs funktion her
FreeRADIUS
Vi vil opsætte FreeRadius på CentOS 7.6. Her er der ikke noget besværligt, vi installererer det på den sædvanlige måde.
yum install freeradius freeradius-utils freeradius-ldap -yFra pakkerne installeres version 3.0.13. Den nyeste kan hentes fra
Efter dette kører FreeRadius allerede. Man kan i /etc/raddb/users afkommentere linjen
steve Cleartext-Password := "testing"Start serveren i debug-tilstand
freeradius -XOg lav en testforbindelse fra localhost
radtest steve testing 127.0.0.1 1812 testing123Vi fik svaret Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, så det er godt. Lad os gå videre.
Tilslut modulet ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapOg lad os straks ændre det. Vi har brug for, at FreeRadius kan kommunikere med 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}})"
}
...Genstart radius-serveren og kontroller synkroniseringen af LDAP-brugere:
radtest user_ldap password_ldap localhost 1812 testing123 Rediger eap i mods-enabled/eap
Her tilføjer vi to forekomster af eap. De vil kun adskille sig ved certifikater og nøgler. Jeg vil snart forklare, hvorfor netop på den måde
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"
}
}Derefter redigerer vi site-enabled/default. Vi er interesserede i sektionerne authorize og 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
}I sektionen authorize fjerner vi alle moduler, som vi ikke har brug for. Vi beholder kun ldap. Vi tilføjer en kontrol af klienten baseret på brugernavnet. Det er netop derfor, vi ovenfor har tilføjet to instanser af eap.
Multi EAPDet er sådan, at når vi tilslutter nogle enheder, vil vi bruge systemcertifikater og angive domænet. Vi har et certifikat og en nøgle fra et betroet certifikatcenter. Personligt mener jeg, at denne forbindelsesprocedure er lettere end at smide et selvunderskrevet certifikat på hver enhed. Men uden selvunderskrevne certifikater kunne vi heller ikke undgå det. Samsung-enheder og Android <= version 6 kan ikke bruge systemcertifikater. Derfor opretter vi et separat eap-guest med selvunderskrevne certifikater for dem. For alle andre enheder vil vi bruge eap-client med et betroet certifikat. User-Name bestemmes via feltet Anonymous ved tilslutning af enheden. Der er kun tilladt tre værdier: Guest, Client og et tomt felt. Alt andet kasseres. Dette indstilles i politikkerne. Jeg vil give et eksempel lidt senere.
Vi redigerer sektionerne authorize og authenticate i 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
}Derefter skal vi angive i politikkerne, hvilke navne der kan bruges til anonym adgang. Vi redigerer policy.d/filter.
Vi skal finde linjer, der ligner dette:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Og nedenfor i elsif tilføje de nødvendige værdier:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Nu skal vi bevæge os ind i mappen certs. Her skal vi lægge nøglen og certifikatet fra det betroede certifikatcenter, som vi allerede har, og generere selvunderskrevne certifikater for eap-guest.
Ændrer parametre i filen ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = Stat
localityNmae = By
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "CA FreeRadius"Tilsvarende værdier skrives i filen server.cnf. Ændrer kun
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = Stat
localityNmae = By
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "Server Certificate FreeRadius"Opretter:
makeFærdig. De modtagne server.crt og server.key er allerede angivet ovenfor i eap-guest.
Og til sidst, lad os tilføje vores adgangspunkter i filen client.conf. Jeg har 7. For ikke at skulle tilføje hvert adgangspunkt individuelt, angiver vi kun netværket, som de er i (mine adgangspunkter er i et separat VLAN).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Ubiquiti Controller
På controlleren opretter vi et separat netværk. Lad os sige 192.168.2.0/24
Gå til indstillinger -> profil. Opretter en ny:
Angiver adresse og port for radius-serveren samt adgangskoden, som vi skrev i filen clients.conf:
Opretter et nyt navn til det trådløse netværk. Som autentificeringsmetode vælger vi WPA-EAP (Enterprise) og angiver den oprettede radius-profil:
Gemmer alt, anvender og går videre.
Konfiguration af klienter
Lad os starte med det sværeste!
Windows 10
Udfordringen er, at Windows endnu ikke kan oprette forbindelse til virksomheds-WiFi via domænet. Derfor skal vi manuelt kopiere vores certifikat til det betroede certifikatlager. Her kan både selvsignerede og certifikat fra certifikationscentret anvendes. Jeg vil bruge den anden.
Dernæst skal vi oprette en ny forbindelse. For at gøre dette går vi til netværksindstillinger -> Centrum for netværksstyring og deling -> Oprettelse og konfiguration af en ny forbindelse eller netværk:
Indtaster manuelt netværksnavnet og ændrer sikkerhedstypen. Derefter trykker vi på ændre kontaktindstillinger og på fanen Sikkerhed vælger vi netværksgodkendelse — EAP-TTLS.
Går ind i indstillingerne, angiver konfidensialitet for autentifikation — client. Vælger det tilføjede certifikat som betroet certifikatcenter, sætter kryds i "Giv ikke brugeren en invitation, hvis serveren ikke kan godkendes" og vælger godkendelsesmetoden — ukrypteret adgangskode (PAP).
Gå herefter ind i de avancerede indstillinger, sæt flueben ved «Angiv godkendelsesmetode». Vælg punktet «Brugergodkendelse» og klik på gemme legitimationsoplysninger. Her skal du indtaste username_ldap og password_ldap
Vi gemmer alt, anvender, lukker. Nu kan du oprette forbindelse til det nye netværk.
Linux
Jeg har testet det på Ubuntu 18.04, 18.10, Fedora 29, 30.
Først downloader vi certifikatet. Jeg fandt ikke ud af, om der i Linux er en mulighed for at bruge systemcertifikater, og om der overhovedet er et sådant lager.
Vi vil oprette forbindelse via domænet. Derfor har vi brug for et certifikat fra det certifikationscenter, hvor vores certifikat blev købt.
Hele forbindelsen foregår i ét vindue. Vælg vores netværk:
anonymous — klient
domain — domænet, certifikatet er udstedt til
Android
non-Samsung
Fra version 7 kan man ved WiFi-forbindelse bruge systemcertifikater ved kun at angive domænet:
domain — domænet, certifikatet er udstedt til
anonymous — klient
Samsung
Som nævnt tidligere kan Samsung-enheder ikke bruge systemcertifikater ved WiFi-forbindelse, og de har ikke mulighed for at oprette forbindelse via domænet. Derfor skal man manuelt tilføje rodcertifikatet fra certifikationscentret (ca.pem, hentes fra Radius-serveren). Her vil der blive brugt et selvsigneret.
Download certifikatet til din enhed og installer det.
Installation af certifikat
Derudover skal der indstilles en skærmlås, PIN-kode eller adgangskode, hvis det endnu ikke er oprettet:
Jeg viste den komplekse metode til installation af certifikatet. På de fleste enheder er det tilstrækkeligt blot at klikke på det downloadede certifikat.
Når certifikatet er installeret, kan du fortsætte med forbindelsen:
certifikat — angiv det, som vi installerede
anonym bruger — gæst
macOS
Apple-enheder kan som standard kun oprette forbindelse til EAP-TLS, men det er stadig nødvendigt at overføre et certifikat til dem. For at angive en anden forbindelsesmetode skal du bruge Apple Configurator 2. Derfor skal du først downloade det til din Mac, oprette en ny profil og tilføje alle nødvendige WiFi-indstillinger.
Apple Configurator
Her angiver vi navnet på vores netværk
Sikkerhedstype — WPA2 Enterprise
Akceptér EAP-typer — TTLS
Brugernavn og adgangskode — lad dem stå tomme
Indre godkendelse — PAP
Ydre identitet — klient
Fanen Tillid. Her angiver vi vores domæne
Det er det. Profilen kan gemmes, signeres og distribueres til enhederne
Når profilen er klar, skal den downloades til Mac og installerers. Under installationen skal der angives username_ldap og password_ldap for brugeren:
iOS
Processen er den samme som i macOS. Du skal bruge profilen (den kan være helt den samme som til macOS. Hvordan man opretter en profil i Apple Configurator, se ovenfor).
Download profilen, installer den, indtast loginoplysningerne, og forbindelse etableres:
Det er alt. Vi har konfigureret Radius-serveren, synkroniseret den med FreeIPA og angivet, at Ubiquiti-adgangspunkterne skal bruge WPA2-EAP.
Mulige spørgsmål
Q: hvordan sender jeg profilen / certifikatet til medarbejderen?
A: Jeg opbevarer alle certifikater / profiler på FTP med adgang via nettet. Jeg har opsat et gæstenetværk med hastighedsbegrænsning og adgang kun til internettet, med undtagelse af FTP.
Godkendelsen gælder i 2 dage, hvorefter den bliver nulstillet, og klienten står uden internetforbindelse. Så når medarbejderen ønsker at forbinde til WiFi, skal de først tilslutte sig gæstenetværket, gå til FTP, downloade det ønskede certifikat eller profil, installere dem, og derefter kan de tilslutte sig det virksomhedsnetværk.
Q: hvorfor ikke bruge MSCHAPv2-ordningen? Det er mere sikkert!
A: For det første fungerer denne ordning godt på NPS (Windows Network Policy System), i vores implementering kræves der yderligere konfiguration af LDAP (FreeIpa) og opbevaring af password-hashes på serveren. Yderligere konfigurationer anbefales ikke, da de kan føre til forskellige synkroniseringsproblemer. For det andet er hash'en MD4, så det øger ikke sikkerheden særligt.
Q: Kan enheder godkendes via MAC-adresser?
A: NEJ, det er ikke sikkert, en angriber kan ændre MAC-adresserne, og desuden understøttes godkendelse via MAC-adresser ikke på mange enheder.
Q: Hvorfor skal man overhovedet bruge alle disse certifikater? Man kan jo også forbinde uden dem.
A: Certifikater bruges til at autenticere serveren. Det vil sige, at enheden ved tilslutning kontrollerer, om det er den server, som man kan stole på. Hvis det er den, fortsætter autentificeringen, hvis ikke, lukkes forbindelsen. Man kan tilslutte uden certifikater, men hvis en angriber eller nabo opretter en radius-server og et access point med samme navn som vores, kan de nemt opsnappe brugeroplysningerne (vi skal huske, at de sendes i klartekst). Når der bruges et certifikat, vil fjenden kun kunne se vores fiktive brugernavne – guest eller client – og en fejltype som - Unknown CA Certificate.
Lidt mere om macOSNormalt foretages geninstallation af systemet på macOS via internettet. Under genoprettelsesstanden skal man forbinde til WiFi, og hverken vores virksomheds-WiFi eller gæstenetværket vil fungere. Personligt har jeg oprettet et andet netværk, almindeligt med WPA2-PSK, skjult, kun til tekniske operationer. Alternativt kan man forberede en bootbar USB-nøgle med systemet på forhånd. Men hvis mac'en er fra 2015 eller senere, skal man også finde en adapter til den USB-nøgle.)
Kilde: habr.com
