Byly popsány některé příklady organizace podnikové WiFi. Zde popíšu, jak jsem implementoval podobné řešení a problémy, se kterými jsem se setkal při připojování na různých zařízeních. Budeme používat již existující LDAP s registrovanými uživateli, nasadíme FreeRadius a nastavíme WPA2-Enterprise na ovladači Ubnt. Vypadá to jednoduché. Uvidíme...
Něco o metodách EAP
Předtím, než se pustíme do úkolu, je třeba určít, jakou metodu autentizace budeme používat v našem řešení.
Z wikipedie:
EAP je autentizační rámec, který se často používá v bezdrátových sítích a připojeních point-to-point. Formát byl poprvé popsán v RFC 3748 a aktualizován v RFC 5247.
EAP se používá k výběru metody autentizace, přenosu klíčů a zpracování těchto klíčů modulárními metodami EAP. Existuje mnoho metod EAP, jak definovaných společně s EAP, tak vydaných jednotlivými výrobci. EAP nedefinuje kanálovou úroveň, pouze určuje formát zpráv. Každý protokol používající EAP má svůj vlastní protokol pro enkapsulaci EAP zpráv.
Samotné metody:
- LEAP - proprietární protokol vyvinutý CISCO. Byly nalezeny zranitelnosti. V současnosti se nedoporučuje používat.
- EAP-TLS - dobře podporovaný mezi dodavateli bezdrátových spojení. Je to bezpečný protokol, jelikož je nástupcem SSL standardů. Nastavení klienta je poměrně složité. Vyžaduje klientský certifikát vedle hesla. Je podporováno v mnoha systémech.
- EAP-TTLS - široce podporováno v mnoha systémech, nabízí dobrou bezpečnost, používající PKI certifikáty pouze na serveru autentizace.
- EAP-MD5 - další otevřený standard. Nabízí minimální úroveň bezpečnosti. Je zranitelný, nepodporuje vzájemnou autentizaci a generaci klíčů.
- EAP-IKEv2 - vychází z Internet Key Exchange Protocol verze 2. Zajišťuje vzájemnou autentizaci a vytvoření session key mezi klientem a serverem.
- PEAP - společné řešení CISCO, Microsoft a RSA Security jako otevřený standard. Široce dostupné v produktech, poskytuje velmi dobrou bezpečnost. Podobá se EAP-TTLS, vyžaduje pouze certifikát na serverové straně.
- PEAPv0/EAP-MSCHAPv2 — po EAP-TLS je to druhý nejširše používaný standard na světě. Používá vztah klient-server v Microsoftu, Cisco, Apple, Linux.
- PEAPv1/EAP-GTC — byl vytvořen společností Cisco jako alternativa PEAPv0/EAP-MSCHAPv2. V žádném případě nechrání autentizační údaje. Nejsou podporovány v operačním systému Windows.
- EAP-FAST — metoda vyvinutá společností Cisco k odstranění nedostatků LEAP. Používá Protected Access Credential (PAC). Není plně vyvinutá.
Z celé této rozmanitosti však volba není příliš velká. Od metody autentizace se vyžadovalo: dobrá bezpečnost, podpora na všech zařízeních (Windows 10, macOS, Linux, Android, iOS), a vlastně, čím jednodušší, tím lepší. Proto byla volba dána na EAP-TTLS v kombinaci s protokolem PAP.
Může se objevit otázka — proč používat PAP? Vždyť přece přenáší hesla v nešifrované podobě?
Ano, je to pravda. Komunikace mezi FreeRadius a FreeIPA proběhne tímto způsobem. V režimu ladění můžete sledovat, jak se odesílají uživatelské jméno a heslo. A ať se klidně posílají, jen vy máte přístup na server FreeRadius.
Podrobněji o fungování EAP-TTLS si můžete přečíst.
FreeRADIUS
FreeRadius budeme zprovozňovat na CentOS 7.6. Není to nic složitého, nainstalujeme to standardním způsobem.
yum install freeradius freeradius-utils freeradius-ldap -yZ balíčků se instaluje verze 3.0.13. Nejnovější si můžete stáhnout na
Poté už FreeRadius funguje. Můžete v /etc/raddb/users odkomentovat řádek
steve Cleartext-Password := "testing"Spusťte server v režimu ladění.
freeradius -XA proveďte testovací připojení na localhost.
radtest steve testing 127.0.0.1 1812 testing123Obdrželi jsme odpověď. Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20., takže vše je v pořádku. Pokračujeme dál.
Připojíme modul. ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapA ihned ho změníme. Potřebujeme, aby FreeRadius mohl komunikovat s 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}})"
}
...Restartujeme radius-server a kontrolujeme synchronizaci uživatelů LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Upravíme eap v mods-enabled/eap
Zde přidáme dvě instance eap. Ty se budou lišit pouze certifikáty a klíči. Později vysvětlím, proč právě tímto způsobem.
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"
}
}Dále upravujeme site-enabled/default. Zajímáme se o sekce authorize a 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
}V sekci authorize odstraníme všechny moduly, které nepotřebujeme. Necháme pouze ldap. Přidáme kontrolu klienta podle uživatelského jména. Právě pro to jsme přidali výše dva instance eap.
Multi EAPO co jde, je, že při připojování některých zařízení budeme používat systémové certifikáty a uvádět doménu. Máme certifikát a klíč od důvěryhodného certifikačního úřadu. Osobně si myslím, že takový postup připojení je jednodušší, než mít na každém zařízení samostatně podepsaný certifikát. Ale ani bez samostatně podepsaných certifikátů se nám to nepodařilo. Zařízení Samsung a Android <= 6 verze neumějí používat systémové certifikáty. Proto pro ně vytváříme samostatnou instanci eap-guest se samostatně podepsanými certifikáty. Pro všechna ostatní zařízení budeme používat eap-client s důvěryhodným certifikátem. User-Name se určuje podle pole Anonymous při připojení zařízení. Je povoleno použít pouze 3 hodnoty: Guest, Client a prázdné pole. Všechno ostatní bude odmítnuto. To se nastavuje v politikách. Příklad uvedu o něco později.
Upravíme sekce authorize a authenticate v 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
}Dále je potřeba definovat v politikách, jaká jména mohou být použita pro anonymní přihlášení. Upravíme policy.d/filter.
Je nutné najít řádky podobné tomu:
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}A níže v elsif přidat potřebné hodnoty:
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Nyní se musíme přesunout do adresáře certs. Sem je potřeba umístit klíč a certifikát od důvěryhodného certifikačního úřadu, který již máme, a je třeba vygenerovat samostatně podepsané certifikáty pro eap-guest.
Upravujeme parametry v souboru ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = CZ
stateOrProvinceNmae = Kraj
localityNmae = Město
organizationName = NONAME
emailAddress = admin@admin.cz
commonName = "CA FreeRadius"Stejné hodnoty zapisujeme do souboru server.cnf. Měníme pouze
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = CZ
stateOrProvinceNmae = Kraj
localityNmae = Město
organizationName = NONAME
emailAddress = admin@admin.cz
commonName = "Server Certificate FreeRadius"Vytváříme:
makeHotovo. Obdrželi jsme server.crt a server.key už máme zapsané výše v eap-guest.
A nakonec přidáme naše přístupové body do souboru client.conf. Mám jich 7. Abychom nemuseli přidávat každý bod zvlášť, zapíšeme pouze síť, ve které se nacházejí (mám přístupové body ve zvláštním VLAN).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}Ubiquiti Controller
Na controlleru vytvoříme zvláštní síť. Nechme to být 192.168.2.0/24
Přejdeme do nastavení -> profil. Vytvoříme nový:
Zapíšeme adresu a port radius-serveru a heslo, které jsme uvedli v souboru clients.conf:
Vytvoříme nové jméno bezdrátové sítě. Jako metodu autentizace vybereme WPA-EAP (Enterprise) a uvedeme vytvořený radius profil:
Vše uložíme, použijeme a jdeme dál.
Nastavení klientů
Začneme s tím nejtěžším!
Windows 10
Obtížnost spočívá v tom, že Windows zatím neumí připojit k podnikové WiFi podle domény. Proto je nutné ručně vložit náš certifikát do úložiště důvěryhodných certifikátů. Můžeme použít jak samopodepsaný, tak certifikát od certifikační autority. Já použiji druhý.
Dále je třeba vytvořit nové připojení. K tomu přejdeme do nastavení sítě a internetu -> Centrum správy sítí a sdílení -> Vytvoření a nastavení nového připojení nebo sítě:
Ručně zapisujeme jméno sítě a měníme typ zabezpečení. Poté klikneme na změnit parametry připojení a v záložce Bezpečnost vybereme ověřování sítě — EAP-TTLS.
Přejdeme do nastavení, zapíšeme důvěrnost autentizace — client. Jako důvěryhodnou certifikační autoritu vybereme námi přidaný certifikát, zaškrtneme políčko „Nepodávat uživateli výzvu, pokud se nepodaří autorizovat server“ a metodu ověřování vybereme — nešifrované heslo (PAP).
Dále se dostaneme do pokročilých parametrů, zaškrtneme „Uveďte režim ověřování“. Vybereme možnost „Ověření uživatele“ a klikneme na uložit přihlašovací údaje. Zde je třeba zadat username_ldap a password_ldap
Všechno uložíme, použijeme, zavřeme. Můžeme se připojit k nové síti.
Linux
Otestoval jsem to na Ubuntu 18.04, 18.10, Fedora 29, 30.
Nejdříve si stáhneme certifikát. Nenašel jsem v Linuxu možnost použít systémové certifikáty a zda tam vůbec existuje takové úložiště.
Budeme se připojovat přes doménu. Proto je potřeba certifikát certifikační autority, u které byl náš certifikát zakoupen.
Celé připojení se uskutečňuje v jednom okně. Vybereme naši síť:
anonymous — client
domain — doména, na kterou byl certifikát vydán
Android
non-Samsung
Od verze 7 při připojování WiFi lze využít systémové certifikáty, pokud uvedete pouze doménu:
domain — doména, na kterou byl certifikát vydán
anonymous — client
Samsung
Jak jsem již psal výše, zařízení Samsung neumí používat systémové certifikáty při připojení WiFi a nemají možnost se připojit přes doménu. Proto je třeba ručně přidat kořenový certifikát certifikační autority (ca.pem, vezmeme na Radius serveru). Zde bude použit samopodepsaný.
Stáhneme certifikát na své zařízení a nainstalujeme ho.
Instalace certifikátu
Přitom bude třeba nastavit kresbu pro odemknutí obrazovky, PIN kód nebo heslo, pokud ještě není nastaveno:
Ukázal jsem složitou variantu instalace certifikátu. Na většině zařízení stačí jednoduše kliknout na stažený certifikát.
Jakmile je certifikát nainstalován, můžeme přejít k připojení:
certifikát — uvádíme ten, který jsme nainstalovali
anonymní uživatel — guest
macOS
Zařízení Apple z krabice se mohou připojit pouze k EAP-TLS, ale stále je potřeba jim nahrát certifikát. Abyste uvedli jinou metodu připojení, musíte použít Apple Configurator 2. Předtím je samozřejmě třeba si ho stáhnout na Mac, vytvořit nový profil a přidat všechny potřebné nastavení WiFi.
Apple Configurator
Zde uvádíme název své sítě
Typ zabezpečení — WPA2 Enterprise
Přijatelné EAP typy — TTLS
Uživatelské jméno a heslo — necháváme prázdné
Vnitřní ověřování — PAP
Vnější identita — client
Záložka Důvěra. Zde uvádíme naši doménu
Všechno. Profil lze uložit, podepsat a distribuovat na zařízení.
Jakmile je profil připraven, je třeba ho stáhnout na Mac a nainstalovat. V průběhu instalace bude třeba zadat username_ldap a password_ldap uživatele:
iOS
Proces je podobný jako na macOS. Je třeba použít profil (může být stejný jako pro macOS. Jak vytvořit profil v Apple Configurator, viz výše).
Stáhneme profil, nainstalujeme, zadáme přihlašovací údaje, připojíme se:
Tímto jsme vše dokončili. Nastavili jsme Radius server, synchronizovali ho s FreeIPA a určili přístupovým bodům Ubiquiti, aby používaly WPA2-EAP.
Možné dotazy
Otázka: jak předat profil/certifikát zaměstnanci?
Odpověď: Všechny certifikáty/profily uchovávám na FTP s přístupem přes web. Nastavil jsem hostitelskou síť s omezením rychlosti a přístupem pouze na internet, kromě FTP.
Autentizace trvá 2 dny, poté se resetuje a klient zůstává bez internetu. Tedy když se zaměstnanec chce připojit k WiFi, nejdříve se připojí k hostitelské síti, přihlásí se na FTP, stáhne si potřebný certifikát nebo profil, nainstaluje je a poté se může připojit k firemní síti.
Otázka: proč nepoužívat schéma s MSCHAPv2? je přece bezpečnější!
Odpověď: za prvé, toto schéma dobře funguje na NPS (Windows Network Policy System), v naší implementaci je nutné navíc konfigurovat LDAP (FreeIPA) a uchovávat hash hesel na serveru. Další nastavení není žádoucí, protože může vést k různým problémům se synchronizací uživatelských účtů. Za druhé, hash je MD4, takže to bezpečnost příliš nezvyšuje.
Otázka: je možné autorizovat zařízení podle MAC adres?
Odpověď: NE, to není bezpečné, útočník může falešně generovat MAC adresy, a navíc autorizace podle MAC adres není podporována na mnoha zařízeních.
Otázka: proč vůbec používat všechny tyto certifikáty? dá se přece i bez nich připojit.
Odpověď: Certifikáty se používají k autorizaci serveru. Tj. zařízení při připojení kontroluje, zda je to server, kterému lze důvěřovat, nebo ne. Pokud ano, autentizace pokračuje, pokud ne, připojení se uzavírá. Je možné se připojit i bez certifikátů, ale pokud útočník nebo soused spustí doma radius-server a přístupový bod se stejným názvem jako my, může snadno zachytit uživatelské údaje (nezapomeňme, že se přenášejí v otevřené podobě). A když se používá certifikát, nepřítel uvidí ve svých logách pouze naše smyšlené uživatelské jméno – guest nebo client a chybu typu – Unknown CA Certificate.
Ještě něco o macOS.Obvykle se na macOS reinstaluje systém přes internet. V režimu obnovení musí být Mac připojen k WiFi, a zde nefunguje ani naše firemní WiFi, ani hostitelská síť. Osobně jsem zřídil ještě jednu síť, běžnou podle WPA2-PSK, skrytou, pouze pro technické operace. Alternativně je možné předem vytvořit bootovací flash disk se systémem. Ale pokud je Mac po roce 2015, bude třeba sehnat adaptér pro tento flash disk).
Zdroj: habr.com
