Już wcześniej opisano kilka przykładów organizacji korporacyjnego WiFi. Tutaj opiszę, jak zrealizowałem podobne rozwiązanie oraz problemy, z którymi się zmierzyłem przy podłączaniu różnych urządzeń. Będziemy korzystać z już istniejącego LDAP z dodanymi użytkownikami, uruchomimy FreeRadius i skonfigurujemy WPA2-Enterprise na kontrolerze Ubnt. Wydaje się proste. Zobaczymy…
Trochę o metodach EAP
Zanim przystąpimy do wykonania zadania, musimy określić, jaką metodę autoryzacji będziemy stosować w naszym rozwiązaniu.
Z Wikipedii:
EAP to ramy autoryzacji, które często są używane w sieciach bezprzewodowych oraz w połączeniach punkt-punkt. Format został po raz pierwszy opisany w RFC 3748 i zaktualizowany w RFC 5247.
EAP jest używane do wyboru metody autoryzacji, wymiany kluczy oraz przetwarzania tych kluczy przez podłączane moduły zwane metodami EAP. Istnieje wiele metod EAP, zarówno określonych razem z samym EAP, jak i wydanych przez różnych producentów. EAP nie definiuje poziomu łącza; określa tylko format wiadomości. Każdy protokół korzystający z EAP ma swój własny protokół enkapsulacji wiadomości EAP.
Same metody:
- LEAP to protokół proprietarny opracowany przez firmę CISCO. Znaleziono w nim luki. Obecnie nie jest zalecane jego używanie.
- EAP-TLS jest dobrze wspierany przez dostawców rozwiązań bezprzewodowych. Jest protokołem bezpiecznym, ponieważ jest następcą standardów SSL. Konfiguracja klienta jest dość skomplikowana. Potrzebny jest certyfikat klienta poza hasłem. Obsługiwany w wielu systemach.
- EAP-TTLS jest szeroko wspierany w wielu systemach, oferując dobrą bezpieczeństwo, wykorzystując certyfikaty PKI tylko na serwerze autoryzacji.
- EAP-MD5 to inny otwarty standard. Oferuje minimalne bezpieczeństwo. Jest podatny na ataki, nie wspiera wzajemnej autoryzacji ani generowania kluczy.
- EAP-IKEv2 oparty jest na protokole wymiany kluczy Internet Key Exchange version 2. Zapewnia wzajemną autoryzację i ustanawianie klucza sesyjnego między klientem a serwerem.
- PEAP to wspólne rozwiązanie CISCO, Microsoftu i RSA Security jako otwarty standard. Szeroko dostępne w produktach, zapewnia bardzo dobre bezpieczeństwo. Podobne do EAP-TTLS, wymaga jedynie certyfikatu po stronie serwera.
- PEAPv0/EAP-MSCHAPv2 — po EAP-TLS to drugi najszerzej używany standard na świecie. Używa połączenia klient-serwer w Microsoft, Cisco, Apple, Linux
- PEAPv1/EAP-GTC — stworzony przez Cisco jako alternatywa dla PEAPv0/EAP-MSCHAPv2. Nie chroni danych uwierzytelniających w żadnym przypadku. Nie są obsługiwane w systemie Windows
- EAP-FAST — metoda opracowana przez Cisco, aby naprawić niedociągnięcia LEAP. Używa Protected Access Credential (PAC). Całkowicie nieukończona
Z całej tej różnorodności wybór i tak nie jest wielki. Metoda uwierzytelniania powinna zapewniać: dobrą bezpieczeństwo, wsparcie na wszystkich urządzeniach (Windows 10, macOS, Linux, Android, iOS) i, oczywiście, im prościej, tym lepiej. Dlatego wybór padł na EAP-TTLS w połączeniu z protokołem PAP.
Może pojawić się pytanie — po co używać PAP? Przecież przesyła hasła w otwartym tekście?
Tak, to prawda. Komunikacja między FreeRadius a FreeIPA będzie przebiegać właśnie w ten sposób. W trybie debugowania można śledzić, jak wysyłane są username i password. I niech się wysyłają, tylko macie dostęp do serwera FreeRadius.
Więcej o działaniu EAP-TTLS można przeczytać
FreeRADIUS
Będziemy uruchamiać FreeRadius na CentOS 7.6. To nie jest skomplikowane, instalujemy w zwykły sposób.
yum install freeradius freeradius-utils freeradius-ldap -yZ pakietów instalowana jest wersja 3.0.13. Najnowszą można pobrać z
Po tym FreeRadius już działa. Można w /etc/raddb/users odkomentować linię
steve Cleartext-Password := "testing"Uruchomić serwer w trybie debugowania
freeradius -XI wykonujemy testowe połączenie z localhost
radtest steve testing 127.0.0.1 1812 testing123Otrzymaliśmy odpowiedź Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, więc wszystko w porządku. Idziemy dalej.
Podłączamy moduł ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapI od razu go zmieniamy. Musimy, aby FreeRadius mógł komunikować się z 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}})"
}
...Restartujemy serwer radius i sprawdzamy synchronizację użytkowników LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Edycja eap w mods-enabled/eap
Tutaj dodamy dwa wystąpienia eap. Będą się różnić tylko certyfikatami i kluczami. Trochę niżej wyjaśnię, dlaczego właśnie tak
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"
}
}Następnie edytujemy site-enabled/default. Interesują nas sekcje authorize i 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
}W sekcji authorize usuwamy wszystkie moduły, które nie są nam potrzebne. Zostawiamy tylko ldap. Dodajemy sprawdzenie klienta po nazwie użytkownika. Właśnie w tym celu dodaliśmy wcześniej dwa przypadki eap.
Multi EAPChodzi o to, że podłączając niektóre urządzenia będziemy używać certyfikatów systemowych i wskazywać domenę. Mamy certyfikat i klucz z zaufanego centrum certyfikacji. Moim zdaniem taka procedura podłączenia jest prostsza niż instalowanie samopodpisanych certyfikatów na każde urządzenie. Ale i bez samopodpisanych certyfikatów nie da się jednak obejść. Urządzenia Samsung i Android < 6 wersji nie potrafią używać certyfikatów systemowych. Dlatego dla nich tworzymy oddzielny przypadek eap-guest z samopodpisanymi certyfikatami. Dla wszystkich innych urządzeń używać będziemy eap-client z zaufanym certyfikatem. User-Name określane jest na podstawie pola Anonymous przy podłączaniu urządzenia. Dozwolone jest używanie tylko 3 wartości: Guest, Client i puste pole. Wszystkie inne są odrzucane. Ustawiane jest to w politykach. Przykład podam trochę później.
Edytujemy sekcje authorize i authenticate w 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
}Następnie należy wpisać w politykach, jakie nazwy można używać do anonimowego logowania. Edytujemy policy.d/filter.
Musimy znaleźć linie podobne do tych:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}I poniżej w elsif dodać potrzebne wartości:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Teraz musimy przejść do katalogu certs. Tutaj należy umieścić klucz i certyfikat z zaufanego centrum certyfikacji, które już mamy, oraz wygenerować samopodpisane certyfikaty dla eap-guest.
Zmiana parametrów w pliku ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = Stan
localityNmae = Miasto
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "CA FreeRadius"Te same wartości umieszczamy w pliku server.cnf. Zmienić należy tylko
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = Stan
localityNmae = Miasto
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "Certyfikat Serwera FreeRadius"Tworzymy:
makeGotowe. Otrzymane server.crt i server.key są już podane powyżej w eap-guest.
I na koniec dodamy nasze punkty dostępu w pliku client.conf. Mam ich 7. Aby nie dodawać każdego punktu osobno, podamy tylko sieć, w której się znajdują (moje punkty dostępu znajdują się w osobnym VLAN).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Kontroler Ubiquiti
Na kontrolerze tworzymy osobną sieć. Niech będzie 192.168.2.0/24
Przechodzimy do ustawień -> profil. Tworzymy nowy:
Podajemy adres i port serwera radius oraz hasło, które były podane w pliku clients.conf:
Tworzymy nową nazwę sieci bezprzewodowej. Jako metodę autoryzacji wybieramy WPA-EAP (Enterprise) i wskazujemy stworzony profil radius:
Wszystko zapisujemy, stosujemy i idziemy dalej.
Konfiguracja klientów
Zaczniemy od najtrudniejszego!
Windows 10
Trudność polega na tym, że Windows jeszcze nie potrafi łączyć się z korporacyjnym WiFi przez domenę. Dlatego trzeba ręcznie załadować nasz certyfikat do magazynu zaufanych certyfikatów. Można użyć zarówno samopodpisanego, jak i certyfikatu z centrum certyfikacji. Ja użyję drugiego.
Następnie trzeba utworzyć nowe połączenie. W tym celu przechodzimy do ustawień sieci i internetu -> Centrum zarządzania sieciami i wspólnym dostępem -> Utwórz i skonfiguruj nowe połączenie lub sieć:
Ręcznie podajemy nazwę sieci i zmieniamy typ zabezpieczeń. Następnie klikamy zmień ustawienia połączenia i na zakładce Bezpieczeństwo wybieramy uwierzytelnianie sieci — EAP-TTLS.
Wchodzimy w ustawienia, wpisujemy prywatność uwierzytelnienia — client. Jako zaufane centrum certyfikacji wybieramy dodany przez nas certyfikat, zaznaczamy opcję „Nie pytaj użytkownika, jeśli nie uda się uwierzytelnienie serwera”, a jako metodę weryfikacji wybieramy — niezaszyfrowane hasło (PAP).
Następnie przechodzimy do dodatkowych ustawień, zaznaczamy pole „Określ tryb uwierzytelniania”. Wybieramy opcję „Uwierzytelnianie użytkownika” i klikamy na zapisz dane logowania. Tutaj należy wprowadzić username_ldap i password_ldap
Wszystko zapisujemy, stosujemy, zamykamy. Można podłączyć się do nowej sieci.
Linuxa
Sprawdzałem na Ubuntu 18.04, 18.10, Fedora 29, 30.
Na początek pobieramy certyfikat. Nie znalazłem w Linux, czy istnieje możliwość użycia certyfikatów systemowych i czy w ogóle jest tam takie repozytorium.
Będziemy łączyć się przez domenę. Dlatego potrzebny jest certyfikat centrum certyfikacji, od którego zakupiliśmy nasz certyfikat.
Całe połączenie odbywa się w jednym oknie. Wybieramy naszą sieć:
anonymous — client
domain — domena, dla której wydano certyfikat
Android
non-Samsung
Od wersji 7 przy łączeniu WiFi można używać certyfikatów systemowych, podając tylko domenę:
domain — domena, dla której wydano certyfikat
anonymous — client
Samsung
Jak już wcześniej pisałem, urządzenia Samsung nie potrafią używać certyfikatów systemowych podczas łączenia WiFi i nie mają możliwości łączenia się przez domenę. Dlatego należy ręcznie dodać certyfikat główny centrum certyfikacji (ca.pem, pobieramy na serwerze Radius). Tutaj będziemy używać samopodpisanego.
Pobieramy certyfikat na urządzenie i go instalujemy.
Instalacja certyfikatu
Przy tym trzeba będzie ustawić rysunek odblokowania ekranu, pin lub hasło, jeśli jeszcze nie jest ustawione:
Pokazałem skomplikowaną wersję instalacji certyfikatu. Na większości urządzeń wystarczy po prostu kliknąć na pobrany certyfikat.
Po zainstalowaniu certyfikatu można przejść do łączenia:
certyfikat — wskazujemy ten, który instalowaliśmy
anonimowy użytkownik — guest
macOS
Urządzenia Apple z pudełka mogą łączyć się tylko z EAP-TLS, ale i tak trzeba im wgrać certyfikat. Aby wskazać inną metodę połączenia, należy skorzystać z Apple Configurator 2. Odpowiednio należy wcześniej pobrać go na Maca, stworzyć nowy profil i dodać wszystkie potrzebne ustawienia WiFi.
Apple Configurator
Tutaj podajemy nazwę naszej sieci
Typ zabezpieczeń — WPA2 Enterprise
Akceptowane typy EAP — TTLS
Nazwa użytkownika i hasło — pozostawiamy puste
Wewnętrzna autoryzacja — PAP
Zewnętrzna tożsamość — client
Zakładka Zaufanie. Tutaj podajemy naszą domenę
Wszystko. Profil można zapisać, podpisać i rozpowszechniać na urządzenia
Po przygotowaniu profilu należy go pobrać na Maca i zainstalować. W trakcie instalacji trzeba będzie podać username_ldap oraz password_ldap użytkownika:
iOS
Proces jest analogiczny do macOS. Należy użyć profilu (można taki sam jak dla macOS. Jak stworzyć profil w Apple Configurator, patrz wyżej).
Pobieramy profil, instalujemy, wprowadzamy dane logowania, łączymy się:
Na tym kończymy. Skonfigurowaliśmy serwer Radius, zsynchronizowaliśmy go z FreeIPA i wskazaliśmy punktom dostępowym Ubiquiti użycie WPA2-EAP.
Możliwe pytania
P: jak przekazać profil/ certyfikat pracownikowi?
O: Wszystkie certyfikaty/ profile przechowuję na FTP z dostępem przez sieć. Uruchomiłem sieć gościnną z ograniczeniem prędkości i dostępem tylko do internetu, z wyjątkiem FTP.
Autoryzacja trwa 2 dni, po czym jest resetowana i klient zostaje bez internetu. Tak więc, gdy pracownik chce połączyć się z WiFi, najpierw łączy się z siecią gościną, wchodzi na FTP, pobiera potrzebny certyfikat lub profil, instaluje je, a następnie może połączyć się z siecią korporacyjną.
P: dlaczego nie użyć schematu z MSCHAPv2? przecież jest bardziej bezpieczny!
O: Po pierwsze, taki schemat działa dobrze na NPS (Windows Network Policy System), w naszej realizacji konieczne jest dodatkowe skonfigurowanie LDAP (FreeIpa) i przechowywanie hashy haseł na serwerze. Dodatkowe ustawienia są niepożądane, ponieważ mogą prowadzić do różnych problemów z synchronizacją użytkowników. Po drugie, hasz to MD4, więc to nie znacząco zwiększa bezpieczeństwa.
P: czy można autoryzować urządzenia po adresach MAC?
O: NIE, to niebezpieczne, haker może podmienić adresy MAC, a autoryzacja po adresach MAC nie jest obsługiwana w wielu urządzeniach.
P: po co w ogóle używać wszystkich tych certyfikatów? można się łączyć i bez nich.
O: Certyfikaty są używane do autoryzacji serwera. To znaczy, że urządzenie podczas podłączenia sprawdza, czy to serwer, któremu można zaufać. Jeśli tak, to autoryzacja przebiega dalej, jeśli nie, połączenie jest zamykane. Można łączyć się bez certyfikatów, ale jeśli osoba trzecia lub sąsiad uruchomi własny serwer RADIUS i punkt dostępowy o tej samej nazwie, co nasz, łatwo będzie mu przechwycić dane logowania użytkownika (pamiętajmy, że są one przesyłane w postaci otwartej). Gdy używany jest certyfikat, wróg zobaczy tylko wymyślone nazwy użytkowników – guest lub client i błąd typu – Unknown CA Certificate.
Jeszcze trochę o macOS.Zwykle w macOS ponowna instalacja systemu odbywa się przez Internet. W trybie odzyskiwania Maca należy podłączyć do WiFi, a tutaj nie zadziała ani nasza korporacyjna sieć WiFi, ani sieć gościnna. Osobiście utworzyłem jeszcze jedną sieć, standardową WPA2-PSK, ukrytą, tylko do operacji technicznych. Można także wcześniej stworzyć bootowalny pendrive z systemem. Ale jeśli Mac jest po 2015 roku, trzeba jeszcze znaleźć adapter do tego pendrive'a.)
Źródło: habr.com
