Certain examples of corporate WiFi organization have already been described. Here, I will detail how I implemented a similar solution and the challenges I encountered while connecting different devices. We will use the existing LDAP with registered users, set up FreeRadius, and configure WPA2-Enterprise on the Ubnt controller. It seems simple enough. Let's see...
A bit about EAP methods
Before starting the task, it is essential to determine which authentication method we will use in our solution.
From Wikipedia:
EAP is an authentication framework often used in wireless networks and point-to-point connections. The format was first described in RFC 3748 and updated in RFC 5247.
EAP is used to select the authentication method, transfer keys, and manage these keys through modules called EAP methods. There are many EAP methods, both defined alongside EAP and released by various manufacturers separately. EAP does not define the channel level; it only specifies the message format. Each protocol using EAP has its encapsulation protocol for EAP messages.
The methods themselves:
- LEAP is a proprietary protocol developed by CISCO. Vulnerabilities have been found. It is currently not recommended for use.
- EAP-TLS is well-supported among vendors of wireless connections. It is a secure protocol, being a successor to SSL standards. Client configuration is quite complex. A client certificate is needed in addition to a password. It is supported in many systems.
- EAP-TTLS is widely supported in many systems, offering good security by using PKI certificates only on the authentication server.
- EAP-MD5 is another open standard. It offers minimal security. It is vulnerable and does not support mutual authentication or key generation.
- EAP-IKEv2 is based on the Internet Key Exchange Protocol version 2. It provides mutual authentication and session key establishment between the client and server.
- PEAP is a joint solution from CISCO, Microsoft, and RSA Security as an open standard. It is widely available in products and provides very good security. It is similar to EAP-TTLS, requiring only a certificate on the server side.
- PEAPv0/EAP-MSCHAPv2 â aprĂšs EAP-TLS, c'est la deuxiĂšme norme largement utilisĂ©e dans le monde. Il utilise une connexion client-serveur dans Microsoft, Cisco, Apple, Linux.
- PEAPv1/EAP-GTC â crĂ©Ă© par Cisco comme alternative Ă PEAPv0/EAP-MSCHAPv2. Ne protĂšge pas les donnĂ©es d'authentification dans tous les cas. Non supportĂ© dans Windows OS.
- EAP-FAST â mĂ©thode dĂ©veloppĂ©e par Cisco pour corriger les dĂ©fauts de LEAP. Utilise une Protected Access Credential (PAC). ComplĂštement non finalisĂ©e.
MalgrĂ© toute cette diversitĂ©, le choix reste limitĂ©. La mĂ©thode d'authentification devait rĂ©pondre Ă : une bonne sĂ©curitĂ©, un support sur tous les appareils (Windows 10, macOS, Linux, Android, iOS) et, en toute honnĂȘtetĂ©, plus c'est simple, mieux c'est. Par consĂ©quent, le choix s'est portĂ© sur EAP-TTLS en association avec le protocole PAP.
Une question peut se poser â Pourquoi utiliser PAP ? car il transmet des mots de passe en clair ?
Oui, c'est tout à fait vrai. La communication entre FreeRadius et FreeIPA se fera ainsi. En mode débogage, vous pouvez suivre comment le nom d'utilisateur et le mot de passe sont envoyés. Et peu importe s'ils sont envoyés, vous avez juste accÚs au serveur FreeRadius.
Pour en savoir plus sur le fonctionnement d'EAP-TTLS, vous pouvez lire.
FreeRADIUS
Nous allons installer FreeRadius sur CentOS 7.6. Rien de compliquer, nous l'installons de maniĂšre habituelle.
yum install freeradius freeradius-utils freeradius-ldap -yĂ partir des paquets, la version 3.0.13 est installĂ©e. La derniĂšre peut ĂȘtre obtenue sur.
AprÚs cela, FreeRadius fonctionne déjà . Vous pouvez décommenter la ligne dans /etc/raddb/users.
steve Cleartext-Password := "testing"Lancez le serveur en mode débogage.
freeradius -XEt nous faisons un test de connexion depuis localhost.
radtest steve testing 127.0.0.1 1812 testing123Nous avons reçu la réponse. Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, donc tout va bien. Continuons.
Connectons le module. ldap.
ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldapEt nous allons l modifier immédiatement. Nous devons faire en sorte que FreeRadius puisse accéder à 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}})"
}
...Redémarrons le serveur radius et vérifions la synchronisation des utilisateurs LDAP:
radtest user_ldap password_ldap localhost 1812 testing123 Modifions eap dans. mods-enabled/eap
Ici, nous ajouterons deux instances de eap. Elles ne différeront que par les certificats et les clés. Je vous expliquerai plus loin pourquoi de cette maniÚre.
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"
}
}Ensuite, nous modifions site-enabled/default. Nous nous intéressons aux sections authorize et 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
}Dans la section authorize, nous supprimons tous les modules dont nous n'avons pas besoin. Nous gardons uniquement ldap. Nous ajoutons une vérification du client par le nom d'utilisateur. C'est précisément pour cela que nous avons ajouté ci-dessus deux instances de eap.
Multi EAPLe fait est qu'en connectant certains appareils, nous allons utiliser des certificats systĂšme et indiquer un domaine. Nous avons un certificat et une clĂ© d'une autoritĂ© de certification de confiance. Ă mon avis, cette procĂ©dure de connexion est plus simple que de distribuer un certificat auto-signĂ© Ă chaque appareil. Mais nous ne pouvons tout de mĂȘme pas Ă©viter complĂštement les certificats auto-signĂ©s. Les appareils Samsung et Android < 6 ne savent pas utiliser les certificats systĂšme. Par consĂ©quent, pour eux, nous crĂ©ons une instance distincte de eap-guest avec des certificats auto-signĂ©s. Pour tous les autres appareils, nous utiliserons eap-client avec un certificat de confiance. Le nom d'utilisateur est dĂ©terminĂ© par le champ Anonyme lors de la connexion de l'appareil. Seules 3 valeurs sont autorisĂ©es : Guest, Client et champ vide. Tout le reste est rejetĂ©. Cela se configure dans les politiques. Je fournirai un exemple un peu plus tard.
Nous allons modifier les sections authorize et authenticate dans 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
}Ensuite, nous devons spĂ©cifier dans les politiques quels noms peuvent ĂȘtre utilisĂ©s pour l'entrĂ©e anonyme. Nous modifions policy.d/filter.
Nous devons trouver des lignes ressemblant Ă ceci :
if (&outer.request:User-Name !~ /^(anon|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Et en dessous, dans elsif, ajouter les valeurs nécessaires :
elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
update request {
Module-Failure-Message = "User-Name is not anonymized"
}
reject
}Nous devons maintenant nous déplacer dans le répertoire certs. Ici, nous devons placer la clé et le certificat de l'autorité de certification de confiance que nous avons déjà et générer des certificats auto-signés pour eap-guest.
Modifier les paramĂštres dans le fichier ca.cnf.
ca.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = Ătat
localityNmae = Ville
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "CA FreeRadius"Les mĂȘmes valeurs Ă inscrire dans le fichier server.cnf. Changer uniquement
commonName:
server.cnf
...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = Ătat
localityNmae = Ville
organizationName = NONAME
emailAddress = admin@admin.ru
commonName = "Certificat du Serveur FreeRadius"Créer :
makePrĂȘt. Les fichiers obtenus server.crt et server.key sont dĂ©jĂ mentionnĂ©s ci-dessus dans eap-guest.
Et enfin, ajoutons nos points d'accÚs dans le fichier client.conf. J'en ai 7. Pour ne pas ajouter chaque point séparément, nous allons seulement indiquer le réseau dans lequel ils se trouvent (mes points d'accÚs se trouvent dans un VLAN distinct).
client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}ContrĂŽleur Ubiquiti
Sur le contrÎleur, créons un réseau séparé. Prenons 192.168.2.0/24
Allons dans les paramÚtres -> profil. Créons un nouveau :
Indiquons l'adresse et le port du serveur radius et le mot de passe que nous avons inscrit dans le fichier clients.conf:
Créons un nouveau nom pour le réseau sans fil. Comme méthode d'authentification, choisissons WPA-EAP (Entreprise) et indiquons le profil radius créé :
Tout sauvegardons, appliquons et continuons.
Configuration des clients
Commençons par le plus compliqué !
Windows 10
La complexité réside dans le fait que Windows ne peut pas encore se connecter au WiFi d'entreprise via le domaine. Il est donc nécessaire de charger manuellement notre certificat dans le magasin de certificats de confiance. Nous pouvons utiliser soit un certificat auto-signé, soit un certificat d'une autorité de certification. Je vais utiliser ce dernier.
Ensuite, il faut créer une nouvelle connexion. Pour cela, allons dans les paramÚtres réseau et Internet -> Centre de contrÎle des réseaux et partage -> Créer et configurer une nouvelle connexion ou un réseau :
Saisissons manuellement le nom du rĂ©seau et changeons le type de sĂ©curitĂ©. Ensuite, cliquons sur modifier les paramĂštres de connexion et dans l'onglet SĂ©curitĂ©, sĂ©lectionnons l'authentification du rĂ©seau â EAP-TTLS.
AccĂ©dons aux paramĂštres, dĂ©finissons la confidentialitĂ© de l'authentification â client. En tant qu'autoritĂ© de certification de confiance, choisissons le certificat que nous avons ajoutĂ©, cochons la case « Ne pas demander Ă l'utilisateur de confirmer si l'autorisation du serveur Ă©choue » et sĂ©lectionnons la mĂ©thode d'authentification â mot de passe non chiffrĂ© (PAP).
Ensuite, nous allons dans les paramÚtres supplémentaires, nous activons l'option « Indiquez le mode d'authentification ». Nous sélectionnons l'option « Authentification de l'utilisateur » et cliquons sur enregistrer les informations d'identification. Ici, il faudra entrer username_ldap et password_ldap
Nous sauvegardons tout, appliquons et fermons. Nous pouvons nous connecter à un nouveau réseau.
Linux
J'ai testé sur Ubuntu 18.04, 18.10, Fedora 29, 30.
Pour commencer, téléchargeons notre certificat. Je n'ai pas trouvé sur Linux s'il y avait une possibilité d'utiliser des certificats systÚme et s'il y a vraiment un tel stockage.
Nous allons nous connecter par domaine. Donc, un certificat de l'autorité de certification qui a délivré notre certificat est nécessaire.
Tout le branchement se fait dans une seule fenĂȘtre. Nous choisissons notre rĂ©seau :
anonyme â client
domaine â le domaine pour lequel le certificat a Ă©tĂ© dĂ©livrĂ©
Android
non-Samsung
Ă partir de la version 7, lors de la connexion au WiFi, vous pouvez utiliser des certificats systĂšme en indiquant seulement le domaine :
domaine â le domaine pour lequel le certificat a Ă©tĂ© dĂ©livrĂ©
anonyme â client
Samsung
Comme mentionné ci-dessus, les appareils Samsung ne savent pas utiliser des certificats systÚme lors de la connexion au WiFi, et ils n'ont pas la possibilité de se connecter par domaine. Il faut donc ajouter manuellement le certificat racine de l'autorité de certification (ca.pem, que l'on prend sur le serveur Radius). Ici, nous utiliserons un certificat auto-signé.
Téléchargez le certificat sur votre appareil et installez-le.
Installation du certificat
Il faudra installer un motif de déverrouillage de l'écran, un code PIN ou un mot de passe, s'il n'est pas encore installé :
J'ai montré la version complexe de l'installation du certificat. Sur la plupart des appareils, il suffit d'appuyer sur le certificat téléchargé.
Une fois le certificat installé, vous pouvez passer à la connexion :
certificat â sĂ©lectionnez celui que vous avez installĂ©
utilisateur anonyme â invitĂ©
macOS
Les appareils Apple, dĂšs leur sortie de la boĂźte, ne peuvent se connecter qu'Ă EAP-TLS, mais il est quand mĂȘme nĂ©cessaire de leur fournir le certificat. Pour indiquer un autre mode de connexion, il faut utiliser Apple Configurator 2. Il faut donc d'abord le tĂ©lĂ©charger sur Mac, crĂ©er un nouveau profil et ajouter tous les paramĂštres de WiFi nĂ©cessaires.
Apple Configurator
Ici, nous indiquons le nom de notre réseau
Type de sĂ©curitĂ© â WPA2 Enterprise
Types EAP acceptĂ©s â TTLS
Nom d'utilisateur et mot de passe â laissons vides
Authentification interne â PAP
IdentitĂ© externe â client
Onglet Confiance. Ici, nous indiquons notre domaine
C'est tout. Le profil peut ĂȘtre enregistrĂ©, signĂ© et distribuĂ© sur les appareils
Une fois le profil prĂ©parĂ©, il doit ĂȘtre tĂ©lĂ©chargĂ© sur Mac et installĂ©. Pendant l'installation, il faudra indiquer le username_ldap et le password_ldap de l'utilisateur :
iOS
Le processus est similaire Ă celui de macOS. Il faut utiliser un profil (il peut ĂȘtre exactement le mĂȘme que pour macOS. Voir ci-dessus pour crĂ©er un profil dans Apple Configurator).
Téléchargeons le profil, installons-le, saisissons les informations d'identification et connectons-nous :
C'est tout. Nous avons configuré le serveur Radius, l'avons synchronisé avec FreeIPA et indiqué aux points d'accÚs Ubiquiti d'utiliser WPA2-EAP.
Questions possibles
Q : Comment transmettre le profil/certificat à l'employé ?
R : Tous les certificats/profils sont stockés sur un FTP accessible via le web. J'ai configuré un réseau invité avec une restriction de vitesse et un accÚs uniquement à Internet, excepté pour le FTP.
L'authentification dure 2 jours, aprÚs quoi elle est réinitialisée et le client se retrouve sans Internet. Ainsi, quand un employé veut se connecter au WiFi, il se connecte d'abord au réseau invité, se rend sur le FTP, télécharge le certificat ou le profil dont il a besoin, les installe et ensuite peut se connecter au réseau d'entreprise.
Q : Pourquoi ne pas utiliser le schéma avec MSCHAPv2 ? Il est plus sécurisé !
R : D'une part, ce schĂ©ma fonctionne bien sur NPS (Windows Network Policy System), dans notre mise en Ćuvre, il est nĂ©cessaire de configurer LDAP (FreeIpa) et de stocker les hachages de mots de passe sur le serveur. Il n'est pas souhaitable de faire des configurations supplĂ©mentaires, car cela peut entraĂźner divers problĂšmes de synchronisation des comptes. D'autre part, le hachage est en MD4, donc cela n'amĂ©liore pas beaucoup la sĂ©curitĂ©.
Q : Est-il possible d'autoriser les dispositifs par adresses MAC ?
R : NON, ce n'est pas sûr, un attaquant peut falsifier les adresses MAC, et de plus, l'authentification par adresses MAC n'est pas prise en charge sur de nombreux dispositifs.
Q : Pourquoi utiliser tous ces certificats ? On peut se connecter sans eux.
R : Les certificats sont utilisĂ©s pour authentifier le serveur. Cela signifie qu'un appareil vĂ©rifie, lors de la connexion, si le serveur est digne de confiance ou non. Si c'est le cas, l'authentification se poursuit ; sinon, la connexion est fermĂ©e. Il est possible de se connecter sans certificats, mais si un cybercriminel ou un voisin met en place un serveur RADIUS et un point d'accĂšs avec le mĂȘme nom que le nĂŽtre, il pourra facilement intercepter les identifiants de l'utilisateur (n'oublions pas qu'ils sont transmis en clair). En utilisant un certificat, l'ennemi ne verra dans ses journaux que nos faux noms d'utilisateur â invitĂ© ou client, ainsi qu'une erreur de type â Certificat CA Inconnu.
Encore un peu sur macOSHabituellement, la réinstallation de macOS se fait via internet. En mode de récupération, il faut connecter le Mac à un WiFi, et notre WiFi d'entreprise ainsi que le réseau invité ne fonctionneront pas ici. Personnellement, j'ai créé un autre réseau, classique avec WPA2-PSK, caché, uniquement pour des opérations techniques. Sinon, on peut aussi préparer à l'avance une clé USB bootable avec le systÚme. Mais si le Mac est post-2015, il faudra également trouver un adaptateur pour cette clé USB.)
Source : habr.com
