Poniższe howto ma na celu stworzenie infrastruktury WiFi w oparciu o oprogramowanie freeradius zainstalowane na routerze TP-Link Archer C7 v2 , na którym jest wgrane OpenWRT Barrier Breaker. Zostanie tutaj opisane dokładnie jak wdrożyć protokół WPA2 Enterprise z obsługą trzech metod uwierzytelniania -- EAP-TLS, EAP-TTLS oraz PEAP (v0) . Będziemy również potrzebować kilku certyfikatów -- proces ich tworzenia został opisany w tym wątku.
Logujemy się zatem na router via SSH i instalujemy tam poniższe pakiety:
morfik:~$ ssh root@192.168.1.1
...
# opkg update
# opkg install freeradius2 \
freeradius2-mod-eap \
freeradius2-mod-eap-mschapv2 \
freeradius2-mod-eap-peap \
freeradius2-mod-eap-tls \
freeradius2-mod-eap-ttls \
freeradius2-mod-files \
freeradius2-mod-mschap \
freeradius2-mod-radutmp \
freeradius2-mod-realm \
freeradius2-mod-exec \
freeradius2-mod-pap \
freeradius2-mod-chap \
freeradius2-mod-sql \
freeradius2-mod-logintime
Musimy także wymienić nieco oprogramowania, bo domyślnie zainstalowany pakiet wpad-mini nie zawiera obsługi WPA2 Enterprise. Jeśli chcemy mieć obsługę WPA2 Enterprise, to musimy doinstalować pakiet wpad uprzednio usuwając pakiet wpad-mini:
# opkg remove wpad-mini
# opkg install wpad
Do katalogu /etc/freeradius2/certs/ na routerze musimy wgrać wcześniej utworzone certyfikaty:
root:~# scp /etc/CA_RADIUS/keys/{192.168.1.1_radius.key,192.168.1.1_radius.crt,ca.key,dh2048.pem} root@192.168.1.1:/etc/freeradius2/certs
root@192.168.1.1's password:
192.168.1.1_radius.key 100% 1704 1.7KB/s 00:00
192.168.1.1_radius.crt 100% 5735 5.6KB/s 00:00
ca.crt 100% 1789 1.8KB/s 00:0
dh2048.pem 100% 424 0.4KB/s 00:00
W pliku /etc/freeradius/radiusd.conf musimy dostosować odpowiednie parametry dotyczące interfejsu, adresu i portów na jakich będzie operował freeradius:
...
listen {
type = auth
port = 0
ipaddr = 127.0.0.1
interface = lo
...
listen {
type = acct
port = 0
ipaddr = 127.0.0.1
interface = lo
...
Port 0 w tym wypadku oznacza port domyślny, a jego wartość jest czytana z pliku /etc/services -- są to 1812 (auth) i 1813 (acct).
Jest wiele metod uwierzytelniania EAP i nas interesować będą trzy z nich EAP-TLS, EAP-TTLS i PEAP. Metoda EAP-TLS, w odróżnieniu od EAP-TTLS i PEAP, wymaga wzajemnej weryfikacji certyfikatów na linii serwer-klient. Z kolei EAP-TTLS i PEAP zbytnio się nie różnią między sobą, no może za wyjątkiem wsparcia -- ten drugi jest rozwijany przez MS. Obie te metody wykorzystują szyfrowany tunel TLS, który jest również podstawą dla uwierzytelniania przy EAP-TLS i by korzystać z EAP-TTLS lub PEAP, trzeba po części skonfigurować uwierzytelnianie EAP-TLS. Same certyfikaty klienckie w przypadku EAP-TTLS i PEAP są nieobowiązkowe i uwierzytelnianie klienta odbywać się będzie przy pomocy loginu i hasła, co znacznie upraszcza wdrożenie protokołu WPA2 Enterprise.
Jeśli chodzi jeszcze o porównanie EAP-TTLS/PEAP w stosunku do EAP-TLS, to proces uwierzytelniania w przypadku tych pierwszych odbywa się w dwóch fazach. EAP-TLS ma tylko jedną fazę, podczas której wymieniane są klucze publiczne i zestawiany jest tunel TLS. Sam tunel tworzony jest na podobnej zasadzie co w przypadku SSL na stronach www. W EAP-TTLS/PEAP występują dwie tożsamości -- zewnętrzna i wewnętrzna (szyfrowana wewnątrz tunelu TLS). Zewnętrzna tożsamość w EAP-TTLS/PEAP odpowiada tożsamości w TLS i w obu przypadkach ta tożsamość widnieje w pakietach sieciowych. Dlatego jeśli zależy nam na anonimowości klientów, nie możemy korzystać z EAP-TLS. Niemniej jednak ta metoda jest najbezpieczniejsza ze wszystkich dostępnych na rynku.
W protokołach EAP-TTLS/PEAP, wewnątrz tunelu TLS, wykorzystywane są inne protokoły EAP, którymi przesyłane są login i hasło. Trzeba rozróżnić te dwie kwestie -- wykorzystanie np. EAP-MD5 przy uwierzytelnianiu jest poważnym ryzykiem, bo hasło w postaci hasha md5 jest przesyłane przez sieć, a ten protokół w obecnych czasach nie daje już gwarancji bezpieczeństwa. Natomiast jeśli wykorzystujemy tunel TLS, to typ zastosowanej metody wewnątrz tunelu nie ma już dla nas większego znaczenia. Nawet możemy puścić hasło otwartym tekstem i tunel TLS daje nam gwarancję poufności danych wewnątrz niego i dlatego nie trzeba tych danych dodatkowo szyfrować.
EAP-TTLS nie jest obsługiwany przez systemy operacyjne spod znaku MS -- te korzystają z rozwijanego przez MS protokołu PEAP. Jeśli się chce korzystać z EAP-TTLS, to albo trzeba zmienić system, albo klienta WiFi, na taki który potrafi obsłużyć EAP-TTLS jako metodę uwierzytelniania.
Serwer RADIUS
W tym przypadku router będzie robił zarówno za AP jak i za serwer RADIUSa , musimy zatem odpowiednio zmienić plik /etc/freeradius2/clients.conf . To w tym pliku określamy hosty, które mogą przesyłać zapytania do serwera RADIUS. Domyślna jego konfiguracja już wskazuje na adres 127.0.0.1 , zatem jedyne co musimy zrobić, to określić parametr secret :
client localhost {
ipaddr = 127.0.0.1
secret = 1846445a84caa742f082efed78e786d9f
require_message_authenticator = yes
nastype = other # localhost isn't usually a NAS...
}
Edytujemy teraz konfigurację WiFi routera, która jest dostępna w pliku /etc/config/wireless i dopisujemy na jej końcu poniższy blok:
config wifi-iface
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'Ever_Vigilant'
option encryption 'wpa2+aes'
option key '1846445a84caa742f082efed78e786d9f'
option server '127.0.0.1'
option port '1812'
option disabled '0'
option hidden '0'
option isolate '0'
Wszystkie wyżej wymienione opcje zostały opisane w tym wątku, zatem jeśli coś wymaga wyjaśnienia, to zapraszam do lektury tamtego posta.
To na co musimy zwrócić uwagę, to na opcję key , której wartość wskazuje na sekret określony wyżej w /etc/freeradius2/clients.conf -- muszą do siebie pasować. Dodatkowo, jeśli korzystaliśmy wcześniej z WPA2-PSK, przydałoby się go wyłączyć zostawiając tym samym jeden aktywny blok z konfiguracją sieci WiFi.
Klienci WiFi
Jeśli chodzi zaś o konta użytkowników, którzy będą mieli prawo łączyć się do naszej sieci, do definiujemy ich w pliku /etc/freeradius2/users . Poniżej przykładowe wpisy dla kont dla konfiguracji EAP-TTLS i PEAP:
"anonymous" Auth-type := EAP
"morfik" Cleartext-Password := "e6a664c54f6427"
Reply-Message = "Witaj, %{User-Name}"
Niżej zaś jest konfiguracja dla kont EAP-TLS:
"morfik_laptop" Auth-type := EAP
Reply-Message = "Witaj, Morfiku!"
Niżej zaś jest określona domyślna akcja, która zostanie podjęta jeśli żaden użytkownik nie zostanie dopasowany:
DEFAULT Auth-type := Reject
Reply-Message := "SPADAJ NA DRZEWO!"
Konfiguracja EAP-TLS, EAP-TTLS, PEAP
Edytujemy plik /etc/freeradius2/eap.conf i ustawiamy odpowiednie ścieżki do certyfikatów. W zależności od tego czy wybieraliśmy opcje szyfrowania plików, będziemy musieli także określić hasło do certyfikatów. W tym przypadku, wszystkie certyfikaty są bez haseł, zatem pole od hasła w konfiguracji freeradiusa pozostaje puste:
tls {
...
private_key_password =
private_key_file = ${certdir}/192.168.1.1_radius.key
certificate_file = ${certdir}/192.168.1.1_radius.crt
CA_file = ${cadir}/ca.crt
dh_file = ${certdir}/dh2048.pem
...
Mając tunel TLS, możemy skonfigurować także EAP-TTLS -- jest trochę niżej:
ttls {
default_eap_type = md5
copy_request_to_tunnel = yes
use_tunneled_reply = yes
}
I podobnie postępujemy z PEAP -- opcje są jeszcze niżej:
peap {
default_eap_type = mschapv2
copy_request_to_tunnel = yes
use_tunneled_reply = yes
}
Zapisujemy zmiany i testujemy wstępnie serwer odpalając go w trybie debug via freeradius -XXX . Wygeneruje to dość spory log, na którego końcu powinniśmy ujrzeć:
Sun Oct 26 06:06:43 2014 : Debug: Listening on authentication interface lo address 127.0.0.1 port 1812
Sun Oct 26 06:06:43 2014 : Debug: Listening on accounting interface lo address 127.0.0.1 port 1813
Sun Oct 26 06:06:43 2014 : Info: Ready to process requests.
Teraz trzeba zaprzęgnąć do pracy jakąś maszynę kliencką i odpowiednio skonfigurować jej profile WiFi w celu przetestowania wszystkich trzech metod uwierzytelniających.
Poniżej są 3 zwrotki dla wpasupplicanta , czyli standardowego narzędzia linuxowego obsługującego połączenia bezprzewodowe.
EAP-TLS
network={
id_str="home_wifi_static"
priority=10
ssid="Winter Is Coming"
bssid=E8:94:F6:68:79:EF
proto=RSN
key_mgmt=WPA-EAP
eap=TLS
pairwise=CCMP
group=CCMP
auth_alg=OPEN
identity="morfik_laptop"
ca_cert="/etc/CA_RADIUS/keys/ca.crt"
client_cert="/etc/CA_RADIUS/keys/morfik_laptop.crt"
private_key="/etc/CA_RADIUS/keys/morfik_laptop.key"
# private_key="/etc/CA_RADIUS/keys/morfik_laptop.p12"
# private_key_passwd="jakies-haslo-client"
scan_ssid=0
disabled=0
}
EAP-TTLS
network={
id_str="home_wifi_static"
priority=10
ssid="Winter Is Coming"
bssid=E8:94:F6:68:79:EF
proto=RSN
key_mgmt=WPA-EAP
eap=TTLS
pairwise=CCMP
group=CCMP
auth_alg=OPEN
phase1="peaplabel=1"
phase2="auth=MD5"
anonymous_identity="anonymous"
identity="morfik"
password="e6a664c54f6427"
ca_cert="/etc/CA_RADIUS/keys/ca.crt"
scan_ssid=0
disabled=0
}
PEAP
network={
id_str="home_wifi_static"
priority=15
ssid="Winter Is Coming"
bssid=E8:94:F6:68:79:EF
proto=RSN
key_mgmt=WPA-EAP
eap=PEAP
pairwise=CCMP
group=CCMP
auth_alg=OPEN
phase2="auth=MSCHAPV2"
anonymous_identity="anonymous"
identity="morfik"
password="e6a664c54f6427"
ca_cert="/etc/CA_RADIUS/keys/ca.crt"
scan_ssid=0
disabled=0
}
Interesują nas głównie linijki zawierające ca_cert , client_cert , private_key , private_key_passwd . Z tym, że w zależności od konfiguracji, nie wszystkie bloki posiadają każdy z tych parametrów. Jeśli nie szyfrujemy kluczy, parametr private_key_passwd może zostać wykomentowany. W przypadku protokołów EAP-TTLS oraz PEAP mamy możliwość sprecyzowania w pliku konfiguracyjnym wpasupplicanta parametru anonymous_identity -- zwykle przyjmuje on wartość anonymous . Jest to nic innego jak zewnętrzna tożsamość używana do zestawiania tunelu TLS. W przypadku gdybyśmy nie podali w konfiguracji tego parametru, zostanie użyta realna tożsamość -- ta, która służy do logowania się do sieci.
Powyższe ustawienia dla protokołów EAP-TTLS i PEAP dają gwarancję, że nie da się podsłuchać realnych tożsamości używanych przy logowaniu się do sieci wifi -- atakujący jedyne co zobaczy węsząc w sieci, to login anonymous, z którym nic nie da się zrobić.
Jeśli chodzi jeszcze o protokoły EAP-TTLS oraz PEAP nie trzeba definiować parametru ca_cert
w konfiguracji wpasupplicanta. W przypadku gdy tego nie zrobimy, nie zweryfikujemy tym samym
certyfikatu serwera RADIUS. Jeśli mamy podaną ścieżkę do certyfikatu serwera w konfiguracji, to w
przypadku niezgodności certyfikatu serwera, zostaniemy o tym poinformowani. Jeśli nie
przeprowadzimy weryfikacji certyfikatu serwera (brak parametru ca_cert), zostaniemy podłączeni do
sieci jak gdyby nigdy nic. Jeśli ktoś w takiej sytuacji spróbuje postawić AP/NAS, na którym będzie
miał taką samą sieć jak nasza - ten sam BSSID i ESSID -- istnieje spore prawdopodobieństwo, że
podłączymy się do infrastruktury tego kogoś i wszystkie dane logowania do naszego konta w naszej
sieci podamy mu jak na tacy.